Anatomy of a certificate
An X.509 certificate is a structured, digitally signed document binding a public key to an identity (a domain name, an organization, a person). Its key fields include the subject (who the certificate identifies, including Subject Alternative Names for the domains it covers), the issuer (which Certificate Authority signed it), the public key itself, a validity period, and the issuer's signature over all of it.
Core fields of an X.509 certificate
Subject
The identity this certificate is issued to — e.g. CN=example.com, plus Subject Alternative Names.
Issuer
The Certificate Authority that signed this certificate.
Public key
The subject's public key (RSA or ECDSA) — the whole point of the certificate.
Validity period
notBefore / notAfter timestamps — outside this window, the certificate is expired.
Signature
The issuer's signature over every field above, binding them together.
The chain of trust
Certificates form a chain: a leaf certificate (a website's) is signed by an intermediate CA, whose own certificate is signed by a root CA. Root CA certificates are the trust anchors — pre-installed in operating systems and browsers — and everything else is trusted only because it traces back, signature by signature, to one of them. This is the same hash-then-sign mechanism covered in the hashing and signatures module, applied recursively.
Chain of trust
- 1
Root CA
Self-signed, pre-installed as a trust anchor in your OS or browser.
- 2
Intermediate CA
Its certificate is signed by the root CA — kept offline and rarely used directly, to protect the root key.
- 3
Leaf certificate
example.com's certificate, signed by the intermediate CA.
- 4
Your browser verifies
It walks the chain leaf → intermediate → root, checking each signature until it reaches an already-trusted anchor.
The chain, drawn out
Drawn as a straight line, issuance and verification run in opposite directions: each certificate is signed by the one to its right, and a browser checks the chain by walking back the other way, from the leaf toward an already-trusted root.
Signing runs leaf ← intermediate ← root; verification walks the same chain in reverse, leaf → intermediate → root, stopping the moment it reaches a trust anchor already installed in your browser or OS.
Subject Alternative Names and wildcard certificates
A single certificate can cover far more than one hostname. Subject Alternative Names (SANs) let one certificate list many exact domains (example.com, www.example.com, api.example.com), while a wildcard certificate (CN=*.example.com) covers any single-level subdomain at once. Modern browsers ignore the legacy Subject/CN field for hostname matching entirely and check only the SAN list — a certificate without the right SAN entry fails validation even if the CN field looks correct.
Revocation: harder than it sounds
A certificate's validity period isn't the only way it can stop being trusted — it can be revoked early, for example if its private key is compromised. Certificate Revocation Lists (CRLs) are downloadable lists of revoked certificate serial numbers; OCSP (Online Certificate Status Protocol) lets a client ask a CA in real time whether a specific certificate is still valid.
CRL
- •Client downloads a full list of revoked serial numbers from the CA
- •Lists grow large over time and go stale between updates
- •No per-check metadata leak — the whole list is downloaded once
OCSP
- •Client asks the CA in real time: is this exact certificate still valid?
- •Small, fast response — but a live query per connection is slow at scale
- •Leaks which sites a client is visiting to the CA, and can fail open if the CA is unreachable
OCSP stapling: fixing both problems at once
OCSP stapling moves the OCSP query off the client entirely: the web server itself periodically fetches a signed, timestamped OCSP response from the CA and "staples" it to the TLS handshake, so the client gets revocation proof without ever contacting the CA directly. This eliminates the metadata leak, removes a round trip from every client connection, and is now the default approach for high-traffic HTTPS deployments.
OCSP stapling
- 1
Server fetches proof periodically
Independently of any client connection, the server asks the CA's OCSP responder for a signed "still valid" statement, refreshed on a schedule (often hourly).
- 2
Server caches the response
The signed OCSP response is stored and reused for every incoming connection until it needs refreshing.
- 3
Client connects
During the TLS handshake, the server attaches ("staples") the cached OCSP response alongside its certificate.
- 4
Client verifies locally
The client checks the OCSP response's signature and timestamp — no separate network call to the CA needed.
Certificate Transparency: policing the CAs themselves
PKI's trust model has a structural weak point: any trusted CA can issue a valid certificate for any domain, and browsers have no way to know a certificate is fraudulent just by looking at it — this is exactly what happened in the 2011 DigiNotar breach, where attackers issued a valid, browser-trusted certificate for google.com without Google's involvement. Certificate Transparency (CT) addresses this by requiring newly issued certificates to be logged in public, append-only, cryptographically verifiable logs, so domain owners (and researchers) can monitor for certificates fraudulently issued in their name. Modern browsers now refuse to trust certificates that aren't backed by CT log entries.
Mutual TLS: certificates in both directions
Everything so far describes the server proving its identity to the client. Mutual TLS (mTLS) adds the reverse: the client also presents a certificate, and the server verifies it the same way the client verifies the server's — walking a chain of trust back to a CA the server trusts. This is common for service-to-service authentication inside a backend (rather than for regular websites, where issuing and managing a certificate for every visitor isn't practical), and it's the backbone of many zero-trust network architectures.
The shift to short-lived certificates
Let's Encrypt and the ACME protocol popularized free, automated certificate issuance with much shorter validity periods (90 days, versus the multi-year certificates common before). Shorter lifetimes shrink the exposure window if a key is compromised and reduce reliance on revocation infrastructure altogether — the certificate simply expires soon regardless.