X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

What a Certificate Actually Asserts

A TLS certificate makes one claim: this public key belongs to these names, and a certificate authority is willing to sign that statement until this date. Everything else — the fields, the extensions, the chain — exists to make that claim verifiable by a client that has never seen your server before.

X.509 is defined by RFC 5280 for the internet PKI profile, with additional rules imposed by the CA/Browser Forum Baseline Requirements, which browsers enforce. When the RFC and the Baseline Requirements disagree, browsers follow the Baseline Requirements — which is precisely why Common Name matching is dead in practice while still present in the RFC’s data model.

What you get from this guide: the ability to read a certificate dump line by line, diagnose the four errors that account for most TLS incidents, and plan renewal automation against the shortening lifetime schedule.

The Three-Part Structure

Certificate ::= SEQUENCE {
  tbsCertificate       TBSCertificate,   -- everything that is signed
  signatureAlgorithm   AlgorithmIdentifier,
  signatureValue       BIT STRING        -- the CA's signature over tbsCertificate
}

The CA signs the DER encoding of tbsCertificate. Change one byte of a name, a date, or an extension and the signature no longer verifies — which is why certificates cannot be edited, only reissued.

Inside tbsCertificate

The v3 Extensions That Decide Everything

Common Name is not identity

CN=example.com inside the subject DN is a legacy artefact. RFC 6125 deprecated CN-based host matching, and the Baseline Requirements require every covered DNS name to be present in SAN. Modern browsers validate against SAN entries only.

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com, DNS:*.api.example.com

Wildcard rules that surprise people:

• *.example.com matches api.example.com but not example.com itself, and not a.b.example.com. One label, one level.
• The wildcard must be the leftmost label. api.*.example.com is invalid.
• A certificate for both apex and subdomains needs both example.com and *.example.com in SAN.

How Chain Validation Works

A client performs path construction followed by path validation (RFC 5280 § 6):

1. Start at the leaf. Read its issuer DN.
2. Find a candidate issuer whose subject DN matches, from the certificates the server sent or from the local trust store; authorityKeyIdentifier disambiguates when several match.
3. Verify the signature on the child using the candidate’s public key.
4. Check the candidate is allowed to be a CA: basicConstraints must say CA:TRUE, keyUsage must include keyCertSign, and pathLenConstraint must not be exceeded.
5. Repeat until reaching a certificate present in the trust store.
6. Then validate the leaf’s own properties: current time inside the validity window, hostname against SAN, EKU includes serverAuth, and revocation status.

[ leaf: example.com ]  --issued by-->  [ intermediate CA ]  --issued by-->  [ root CA ]
   sent by server              sent by server                  in OS/browser trust store

The server’s job: send the leaf and every intermediate, leaf first. Do not send the root. A client that already trusts the root ignores your copy; a client that does not trust it will not start trusting it because you attached it.

# Show the chain a server actually presents
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Verify a local chain offline
openssl verify -untrusted intermediate.pem leaf.pem

Revocation: OCSP, CRL, and What Browsers Really Do

Revocation is the weakest link in web PKI. Three mechanisms coexist:

The structural weakness is soft-fail: if a client cannot reach the responder, it proceeds rather than break the site — so an attacker who can block the OCSP query can also suppress a revocation. This is a large part of why the industry chose to shrink certificate lifetimes instead: a 47-day certificate limits the damage window without depending on revocation working at all.

The Shrinking Lifetime Schedule

CA/Browser Forum ballot SC-081v3, approved in April 2025, sets a phased reduction in the maximum validity of publicly trusted TLS certificates:

Many CAs issue at 199 days to stay clear of the boundary. Domain validation data reuse periods shrink on a parallel schedule.

Operational consequences to plan for now:

1. Automate with ACME. At 47 days, renewal must be a cron-grade process. Manual calendar reminders will fail.
2. Instrument expiry, don’t trust it. Alert at 30 days and 7 days remaining, measured from the live certificate the server presents — not from your issuance records.
3. Audit the non-web endpoints. Load balancers, mail gateways, API gateways, mutual-TLS clients, and appliances with hand-uploaded certificates are where 47-day renewal breaks first.
4. Keep intermediates fresh. A stale pinned intermediate bundle survives a 398-day cadence and fails under a 47-day one.

The Four Errors Worth Recognising Instantly

A fast triage rule: if openssl verify -untrusted succeeds locally but browsers fail, the certificate is fine and the server chain configuration is wrong.

Step-by-Step: Auditing a Certificate with Toolbox

1. Obtain the certificate: export it from your CA dashboard, or capture it live with openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509.
2. Open the tool: visit the Toolbox SSL Certificate Inspector and paste the PEM block or load the DER file.
3. Read the SAN list first — this is what browsers match. Confirm every hostname you serve is present, including the apex if you serve it.
4. Check notAfter against the current lifetime cap. Under the 200-day regime, a certificate issued with a longer window is a red flag about the issuance path.
5. Confirm key and signature strength: RSA ≥ 2048 bits or an approved curve, and a SHA-256-or-better signature algorithm.
6. Verify the chain separately, since a single certificate cannot prove its own path: openssl verify -untrusted intermediate.pem leaf.pem.

Outcome: you can tell within a minute whether an incident is a naming problem, a chain problem, an expiry problem, or a trust-store problem — and you inspect internal hostnames without publishing them to a third-party service.

Related guides: RSA vs ECC keypairs · HMAC signature verification · AES-256-GCM encryption