Revocation — The Broken Part Of PKI

You've spent five chapters building up the trust system: CAs sign certificates, browsers verify the chain, every connection is authenticated. Now here's the awkward question:

What happens when a private key leaks before the certificate expires?

In theory: the CA revokes the certificate, browsers check a revocation list before trusting any cert, and the compromised cert stops working everywhere.

In practice: none of this really works, and the industry has quietly given up on fixing it the right way. Instead, they're working around the problem by making certificates so short-lived that revocation barely matters.

Approach 1 — CRLs (Certificate Revocation Lists)

The original design: the CA publishes a big file listing every certificate it has revoked. Before trusting any cert, the browser downloads the latest list and checks if the cert is in it.

Sound reasonable? The problem hit immediately. CRLs grew huge — tens of megabytes for big CAs. Downloading a 20 MB list before every TLS connection is unacceptable for performance. Browsers stopped doing this years ago.

Mozilla now ships a curated subset called CRLite — a Bloom-filter-style compressed snapshot updated daily and pushed via browser updates. It works, but it's a hack: it covers only revocations the CA actively reports to Mozilla's program, and updates lag by hours or days.

Approach 2 — OCSP (Online Certificate Status Protocol)

The next attempt: instead of downloading the whole list, the browser asks the CA in real time. "Is this specific certificate still valid?" The CA responds yes or no. Less data, more current.

In theory, brilliant. In practice, three serious problems:

Problem 1 — Latency. Every new HTTPS connection now requires an extra round trip to the CA's OCSP server before the page can load. On a slow connection or a far-away CA, this adds hundreds of milliseconds to every page.

Problem 2 — Privacy. The CA learns every site every user visits, in real time, complete with timestamps. Imagine telling DigiCert "Maria just opened her bank's website" every time she logs in. This is a massive privacy leak that browsers don't love.

Problem 3 — Soft-fail. What does the browser do if the OCSP server is down, slow, or blocked? Two options: fail the connection, or trust the cert anyway. Failing means a single outage of a CA's OCSP server would break millions of websites. So every browser chose "trust anyway" — known as soft-fail. The result: an attacker who can block OCSP requests (trivially, by just dropping them at a firewall) can prevent revocation checking from ever happening. The browser silently accepts the (potentially revoked) cert.

This means OCSP, as deployed, provides essentially zero security benefit against motivated attackers. It's been this way for over a decade.

OCSP Stapling — Sort Of A Fix

To plug the privacy hole and the round-trip cost, the protocol added OCSP Stapling. The server periodically asks the CA for an OCSP response for its own cert and caches it. When a client connects, the server "staples" the cached OCSP response into the TLS handshake. The client gets a fresh-enough revocation status without making any extra request.

This is a real improvement. It removes the latency and the privacy leak. But it still doesn't fix soft-fail — if the server fails to staple, the browser falls back to its old behavior, which is to either trust silently or ask the CA itself.

OCSP Must-Staple was proposed to fix soft-fail: a flag in the cert saying "if the OCSP response isn't stapled, refuse the connection." Adoption: vanishingly small. Most CAs don't issue Must-Staple certs by default, and most servers don't bother to staple correctly.

The 2026 Reality

In 2026, browser teams have basically conceded that revocation as designed doesn't work for the open web. Their approach instead:

• Apple and Firefox distribute curated revocation snapshots via browser updates (CRLite-style);
• Chrome does something similar with CRLSets — a hand-curated list of high-priority revocations Google pushes to all installs;
• Most revocations are silently ignored unless they make it onto these curated lists, which is rare.

So what do you actually rely on when a key leaks? Time. Wait for the certificate to expire. With 398-day certificates, that meant up to 13 months of exposure. Unacceptable.

The Fix — Just Make Certificates Short-Lived

Here's the elegant escape from this whole mess. If certificates only live for a few days or weeks, revocation barely matters. A leaked cert can only do damage for as long as it remains valid. Shrink the validity period, shrink the damage window.

This is exactly what the CA/Browser Forum decided. The maximum certificate lifetime is being phased down aggressively:

• March 2026 — max 200 days;
• March 2027 — max 100 days;
• March 2029 — max 47 days.

Let's Encrypt has already gone further:

• Default Let's Encrypt certs: 90 days since 2015;
• New shortlived profile since 2024: 6 days;
• Planned shift to 45 days as default by 2028, one year ahead of the industry mandate.

A 6-day certificate doesn't need revocation. If the key leaks today, the cert expires this weekend. The blast radius is tiny.

The Cost — Mandatory Automation

The trade-off: with 47-day certs, no human can keep up with renewals by hand. Full ACME automation becomes mandatory. Manual cert management is dying. We cover the practical side of automation in Section 3, but the high-level pattern is:

• Use Certbot, acme.sh, lego, or built-in support in your reverse proxy (Caddy, Traefik);
• Set up monitoring on certificate expiry — a missed renewal is now a 6-day-to-47-day production outage clock;
• Use ARI (ACME Renewal Information) — a 2024 extension that lets the CA tell the client when to renew;
• Track certs with Certificate Transparency logs to catch issuance problems.