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

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

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

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

SSL / X.509 Certificate Inspector

Paste a PEM certificate or load a DER file to read every field and extension locally. Internal hostnames in SAN entries stay on your machine.

Open Certificate Inspector →

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`

Field	Meaning	What to check
`version`	1, 2, or 3 (`v3` = value `2`)	Anything but v3 is obsolete
`serialNumber`	CA-unique identifier	Must be ≥ 64 bits of CSPRNG entropy per Baseline Requirements
`signature`	Algorithm the CA used	`sha256WithRSAEncryption` or `ecdsa-with-SHA256`; SHA-1 signatures are rejected
`issuer`	Distinguished Name of the CA	Must match the intermediate’s `subject` exactly
`validity`	`notBefore` / `notAfter`	Times are UTC; `UTCTime` before 2050, `GeneralizedTime` after
`subject`	Distinguished Name of the holder	Informational for TLS host matching
`subjectPublicKeyInfo`	Algorithm + public key	Same SPKI structure as a
`extensions`	v3 extension list	Where all the operational meaning lives

The v3 Extensions That Decide Everything

Extension	Critical?	Role
subjectAltName (SAN)	No	The list of names the certificate covers: `DNS`, `IP`, `email`, `URI`
basicConstraints	Yes	`CA:TRUE` marks a CA certificate; `pathLenConstraint` caps chain depth
keyUsage	Yes	`digitalSignature`, `keyEncipherment`, `keyCertSign` …
extendedKeyUsage (EKU)	Often	`serverAuth`, `clientAuth`, `codeSigning` — a `serverAuth`-only cert cannot authenticate a client
authorityInfoAccess (AIA)	No	URLs for the issuer certificate and the OCSP responder
cRLDistributionPoints	No	Where to fetch the CRL
subjectKeyIdentifier / authorityKeyIdentifier	No	Hints that let a verifier pick the right issuer quickly
signedCertificateTimestamp (SCT)	No	Certificate Transparency proofs; Chrome requires them for public trust

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):

Start at the leaf. Read its issuer DN.
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.
Verify the signature on the child using the candidate’s public key.
Check the candidate is allowed to be a CA: basicConstraints must say CA:TRUE, keyUsage must include keyCertSign, and pathLenConstraint must not be exceeded.
Repeat until reaching a certificate present in the trust store.
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:

Mechanism	How it works	Reality
CRL	Client downloads a signed list of revoked serials	Large files; poor latency; browsers largely stopped live checks
OCSP	Client queries the responder for one serial	Privacy leak (the CA learns browsing) and a soft-fail on timeout
OCSP stapling	The server fetches a signed OCSP response and attaches it in the handshake	The deployable answer; enable it
Pushed lists	Browser ships aggregated revocation data it compiled	What major browsers increasingly rely on in practice

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:

Effective date	Maximum validity
Before 15 March 2026	398 days
15 March 2026	200 days
15 March 2027	100 days
15 March 2029	47 days

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:

Automate with ACME. At 47 days, renewal must be a cron-grade process. Manual calendar reminders will fail.
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.
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.
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

Symptom	Root cause	Fix
`NET::ERR_CERT_COMMON_NAME_INVALID`	Hostname absent from SAN	Reissue with the name in SAN; CN alone is ignored
`unable to get local issuer certificate`	Intermediate not served	Append the intermediate to the chain file, leaf first
`NET::ERR_CERT_DATE_INVALID`	Expired, or server clock wrong	Renew; also verify NTP on the server
`NET::ERR_CERT_AUTHORITY_INVALID`	Self-signed or private CA not trusted	Install the root in the client trust store, or use a public CA

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

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.
Open the tool: visit the and paste the PEM block or load the DER file.
Read the SAN list first — this is what browsers match. Confirm every hostname you serve is present, including the apex if you serve it.
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.
Confirm key and signature strength: RSA ≥ 2048 bits or an approved curve, and a SHA-256-or-better signature algorithm.
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: · ·

FAQ

Frequently Asked Questions

Why do browsers ignore the Common Name in a certificate? ▼

RFC 6125 deprecated Common Name matching for host identity, and the CA/Browser Forum Baseline Requirements require every covered DNS name to appear in the Subject Alternative Name extension. Chrome, Firefox, and Safari match hostnames against SAN entries only, so a certificate carrying the hostname only in CN fails with a name mismatch.

What is the difference between a certificate chain and a certificate bundle? ▼

A chain is the ordered path from the leaf through intermediates to a root the client already trusts; a bundle is the file holding them. Servers must send the leaf plus all intermediates in order and should omit the root. Missing intermediates cause a site to work in one client and fail in another, because some clients can fetch the issuer via Authority Information Access while others cannot.

How long can a TLS certificate be valid in 2026? ▼

Under CA/Browser Forum ballot SC-081v3, the maximum validity for publicly trusted TLS certificates fell from 398 days to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and to 47 days on 15 March 2029. Many CAs issue at 199 days to avoid boundary rejections, which makes ACME automation mandatory rather than optional.

Can I inspect a certificate safely without uploading it anywhere? ▼

Yes. A server certificate holds only public data, but internal hostnames and staging names in SAN entries are useful reconnaissance for an attacker. A client-side inspector parses the ASN.1 DER structure in browser memory, so nothing is transmitted, logged, or retained elsewhere.

Pki | Toolbox Guides & Articles

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