The Trust Problem
A public key like 04:bf:e9:... has no identity attached. It is just a sequence of bytes. Anyone can generate a key pair and claim that the public half belongs to your bank. Without some external mechanism to bind the key to a real-world identity, asymmetric crypto solves confidentiality and authenticity in theory but trust nowhere.
Concretely: when you type https://chase.com into your browser, the server hands you a public key. How do you know it is Chase's key and not an attacker's? You have never met Chase. You have no out-of-band channel. The key itself proves nothing about its owner.
PKI answers this with a chain of signatures. Chase's public key comes wrapped in a certificate, signed by an entity your browser already trusts. The browser checks that signature, then checks the signer's certificate, and so on until it reaches a root certificate that came pre-installed in your operating system.
A Certificate Is A Public Key With A Signature
An X.509 certificate is a structured document that contains, at minimum:
- Subject: the identity the certificate is issued to (e.g.
chase.comorCN=ZZZ Consulting Issuing CA). - Subject Public Key: the actual public key being bound to that identity.
- Issuer: the identity of the entity that signed this certificate.
- Validity Period: a start date and an expiration date.
- Serial Number: a unique identifier within the issuer's name space.
- Extensions: what the cert can be used for (server auth, code signing, etc.), SAN list of additional domains, CRL/OCSP URLs.
- Signature: the issuer's signature over all the fields above, using the issuer's private key.
The signature is the load-bearing field. Anyone with the issuer's public key can verify that the issuer actually issued this certificate. Anyone without the issuer's private key cannot forge a valid signature.
The Chain Of Trust
Certificates form a chain because the issuer of a certificate has their own certificate, signed by their issuer, all the way up to a root. Standard chains are three deep:
- Leaf certificate: the actual server certificate, issued to a specific domain. Lives on the server.
- Intermediate certificate: issued by a root CA to a working-level CA. The intermediate signs the leaf. Servers send this in the handshake too.
- Root certificate: self-signed by a trusted CA. Ships pre-installed in operating systems and browsers. Never sent over the wire; the browser already has it.
The two-layer separation between root and intermediate exists so that root private keys can be kept offline in air-gapped HSMs. Day-to-day signing is done by the intermediate, whose key is online and rotated frequently.
Certificate Chain Explorer
Click each certificate in the chain to see its actual fields. Then click Verify chain to walk from leaf to root, checking each signature in order.
Inspect each certificate, then verify the full chain
This is a simulated chain for zzz-consulting.com. Click any card to expand its details. The verification step walks up the chain, confirming that each signature is valid under the next certificate's public key, until it reaches a root in your trust store.
When Things Go Wrong: Revocation, CRLs, OCSP, CT
What happens when a private key gets compromised, or a CA accidentally issues a certificate for the wrong domain? The certificate has to be revoked. Several mechanisms try to solve this, with varying degrees of success.
| Mechanism | How it works | Reality check |
|---|---|---|
| CRL (Certificate Revocation List) | CA publishes a list of revoked serial numbers. Clients download periodically. | Lists got huge. Most clients stopped checking them. |
| OCSP (Online Certificate Status Protocol) | Client queries CA in real-time about a specific cert. | Adds latency. Failures usually default to "trust anyway" (soft-fail). |
| OCSP Stapling | Server includes a fresh OCSP response in the TLS handshake. | Works well when servers are configured for it. Many are not. |
| CRLite / OneCRL | Mozilla's compact bloom-filter-based revocation set, pushed via browser updates. | Modern attempt to make revocation actually reliable. |
| Short certificate lifetimes | Just expire certificates fast (90 days now, dropping to 47 days in 2029). | The pragmatic winner. Let's Encrypt and Apple drove this. |
The DigiNotar CA was compromised in 2011. The attacker issued more than 500 fraudulent certificates, including one for *.google.com, and used them to perform man-in-the-middle attacks on Gmail users in Iran. The attack was only discovered because a curious user spotted a warning. After DigiNotar, the web community built Certificate Transparency (CT): every certificate issued by a publicly trusted CA must be logged to a public append-only log. Browsers refuse to trust certs without CT proofs. This makes silent misissuance impossible: every cert is publicly auditable.
Let's Encrypt and ACME
Until 2015, TLS certificates were a paid product. Domain Validation certs typically cost $50 to $200 per year. This pricing kept HTTPS adoption stuck below 50% of web traffic.
Let's Encrypt, launched in 2015 by ISRG with backing from Mozilla, EFF, Cisco, and Akamai, issues free DV certificates via the ACME protocol (RFC 8555). The certs are valid for 90 days and renewal is fully automated. The math:
- Your server contacts Let's Encrypt and requests a cert for
example.com. - Let's Encrypt issues a challenge: place a specific token at
http://example.com/.well-known/acme-challenge/...or in a DNS TXT record. - Your server (or DNS) places the token. Let's Encrypt verifies. Possession of the domain is proven.
- Let's Encrypt signs and returns the cert.
The whole flow takes seconds. Combined with renewal automation in Certbot, acme.sh, and Caddy, this drove HTTPS adoption past 95% of page loads by 2024. ACME is one of the most successful protocol designs of the last decade.
Alternative Trust Models
The CA model is not the only way to bind keys to identities. A few other patterns:
- Web of Trust (PGP): Users sign each other's keys directly. Trust is transitive: if I trust Alice and Alice signed Bob's key, I have some basis for trusting Bob's. Never reached critical mass outside small communities.
- Trust On First Use (TOFU): On the first connection, save the server's key fingerprint. On subsequent connections, alert if it changed. SSH uses TOFU by default. Signal uses it for identity keys.
- Certificate Pinning: The client hardcodes (or learns and caches) the expected certificate or public key. Defends against compromised CAs at the cost of operational fragility. HTTP Public Key Pinning was deprecated in 2017 after too many sites accidentally locked themselves out.
- DANE (DNS-based Authentication of Named Entities): Publishes certificate hashes in DNSSEC-signed TXT records. Removes the CA from the trust path. Used in some email and IoT deployments. Browser support never materialized.