When your browser ran the TLS handshake, the server proved it owned a private key by signing the transcript. But that only proves the server holds some key — it says nothing about whose key it is. An attacker who intercepts your connection can generate a perfectly good key of their own and sign with it just as convincingly. The hard problem is not the maths of signing; it is binding a public key to an identity — to the actual bank.com — in a way you can verify while talking to a stranger you have never met, across a network run by strangers.

The answer the Internet settled on is Public Key Infrastructure (PKI): a global system of certificates, Certificate Authorities, and a chain of trust that reduces the impossible task of "trust a billion servers" to the manageable one of "trust a few dozen roots your browser already ships with." This page is about how that machinery works — the X.509 certificate, how a chain is validated, how a compromised key is revoked, and the modern additions (Certificate Transparency and Let's Encrypt) that patched its worst flaws.

The certificate: a signed statement of identity

A certificate is a small structured document, formatted as X.509, that says in effect: "the public key K belongs to the entity named bank.com, and I, the issuer, vouch for it — here is my signature." The signature is what makes it trustworthy: it is computed over all the other fields, so a single altered byte invalidates it.

Two subtleties bite people. First, modern browsers ignore the old Common Name for host matching and check only the SAN list, so a cert without a matching SAN entry is rejected even if its CN looks right. Second, Basic Constraints CA: FALSE is what stops a leaf certificate from being abused to sign further certificates — a check whose absence caused real breaches before browsers enforced it.

The chain of trust

No single CA signs every website directly — that would be far too much risk concentrated in one key. Instead trust flows down a chain. Your browser and OS ship a root store: a curated list of a few dozen to a couple hundred root CA certificates, self-signed and implicitly trusted. Everything else earns trust by tracing back to one of those roots.

Why the extra intermediate layer? Because the root's private key is the crown jewels: if it leaked, every certificate under it would be forgeable, and you cannot easily replace a key baked into billions of devices. So the root is kept offline in a vault and used rarely, only to sign intermediates. If an intermediate is compromised, it can be revoked and replaced without touching the precious root. Follow the chain being verified:

Revocation: taking a certificate back

Certificates have an expiry date, but sometimes you must kill one early — a server's private key was stolen, or a cert was mis-issued. Since the certificate is a signed document already copied all over the world, you cannot un-sign it; you need a way to tell the world it is no longer valid. PKI offers two mechanisms, both flawed:

• CRL — Certificate Revocation List. Each CA publishes a signed list of the serial numbers it has revoked. The problem: these lists grew to megabytes, are slow to download, and are only as fresh as their last publish.
• OCSP — Online Certificate Status Protocol. The browser asks the CA in real time, "is serial number 12345 still good?" Fresher, but it adds latency to every connection and leaks to the CA which sites you visit — a privacy hole. Worse, if the OCSP server is unreachable, browsers historically soft-fail (assume "good"), which an attacker blocking OCSP can exploit.
• OCSP stapling fixes both: the server fetches a recent, CA-signed OCSP response and "staples" it into the TLS handshake, so the browser gets the status without a separate request and without leaking anything.

Because revocation is so unreliable, the industry has quietly shifted strategy toward short lifetimes: if a certificate is only valid for 90 days (or, increasingly, weeks), a stolen one becomes worthless soon anyway, and revocation matters less. "Rotate often" is beating "revoke reliably."

Patching PKI's holes: Transparency and ACME

Classic PKI has a terrifying weakness: any trusted CA can issue a certificate for any domain. There are hundreds of CAs (and their intermediates) in the world's trust stores; a single one that is compromised or coerced can mint a valid google.com certificate, and Google would never know. This is not hypothetical — in 2011 the Dutch CA DigiNotar was hacked and issued fraudulent certificates for Google and others, used to spy on Iranian users; DigiNotar was removed from every trust store and went bankrupt. Two modern additions harden the system:

The other revolution was Let's Encrypt and its ACME protocol (2015). Before it, certificates cost money and were fiddly to install, so most of the web ran plain HTTP. ACME automates the whole dance: your server proves it controls a domain by answering an automated challenge (place this token at a URL, or in a DNS record), and receives a free, short-lived certificate — renewed automatically by a background agent. The result was historic: HTTPS went from a minority of web traffic to the overwhelming majority in a few years. Free, automatic, short-lived certificates are why the padlock is now the default rather than the exception.