X.509 Certificates

An X.509 certificate binds a subject public key to an asserted subject identity through an issuer signature. Certificate validation determines whether that binding is acceptable for a specific protocol and connection. Parsing a certificate or verifying its signature alone is not sufficient.

Encoding and Certificate Structure #

Certificates are ASN.1 values conventionally encoded with DER. PEM is the base64 text form of a DER object:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

The signed tbsCertificate contains a version, issuer-unique serial number, issuer distinguished name, validity interval, subject distinguished name, SubjectPublicKeyInfo (SPKI), and extensions. The outer certificate also contains the issuer’s signature algorithm identifier and signature over tbsCertificate. The issuer public key is not embedded as a separate certificate field; it is found by constructing a path to an issuer certificate or trust anchor.

Extensions Used by TLS #

RFC 5280 extensions constrain how a certificate is used:

• basicConstraints identifies CA certificates and path-length restrictions.
• keyUsage restricts operations such as keyCertSign or digitalSignature.
• extendedKeyUsage can restrict use to server or client authentication.
• subjectAltName carries DNS names and IP addresses for TLS identity checks.
• Subject and authority key identifiers assist path construction but do not replace signature verification.

TLS clients verify the requested DNS name against subjectAltName. The common name is not a general fallback for correctly issued modern certificates. Validity time, critical extensions, signature-algorithm policy, basic constraints, and key usage all participate in validation.

Paths, Revocation, and Pinning #

Path building selects an issuer sequence from the leaf certificate to a locally configured trust anchor. Path validation then verifies signatures, time, basicConstraints, path-length and name constraints, key usage, critical extensions, and the relying party’s algorithm and policy requirements. A policy tree can restrict acceptable certificate policies when the application uses them. The server transmits intermediate certificates needed for this process, but the trust anchor is normally supplied by the client trust store.

CRLs and OCSP provide revocation information, but client behavior varies by platform and protocol. A deployment must not claim immediate revocation enforcement without testing its actual client population. Certificate pinning adds a public-key or certificate constraint; it has operational recovery costs and should be used only with a defined rotation procedure.

Use openssl x509 -in cert.pem -noout -text to inspect fields. A displayed SHA-256 fingerprint is a digest of certificate bytes for out-of-band comparison; it is not an identity proof or a replacement for path validation.

For the TLS 1.3 handshake that authenticates a certificate, see TLS 1.3.