In 1996, the X.509 v3 specification gave us Certificate Revocation Lists (CRLs). The idea was straightforward: when a certificate authority issues a certificate it can no longer trust — because the private key was stolen, the requesting entity was compromised, or the original validation turned out to be fraudulent — the CA adds that certificate to a published list. Clients download the list, check the certificates they see against it, and refuse to trust anything on the list.
It works on paper. In practice, it failed three different ways, and the web has spent the last decade engineering around the failure instead of fixing it.
Why CRLs Don't Scale
The first problem is size. Public CAs issue hundreds of millions of certificates. A non-trivial fraction get revoked. By 2020, the combined CRLs of major CAs ran to tens of megabytes — too large to fetch on every connection. Browsers stopped fetching them long before that.
The second problem is freshness. CRLs are published on a schedule, often daily or every few hours. If a private key leaks at 9:00 AM and the next CRL update is at 11:00 PM, anyone with that key has fourteen hours of valid-looking signatures before the world finds out. For a payment processor or a major SaaS, fourteen hours is a catastrophic window.
The third problem is privacy. To check a CRL meaningfully, your client has to fetch the CA's list — which means the CA learns which sites you're visiting at the moment you visit them. Privacy advocates noticed.
OCSP: Same Problem, New Privacy Hole
The Online Certificate Status Protocol (OCSP), standardized in 1999, was supposed to fix the freshness and bandwidth issues. Instead of downloading a full list, the client would query the CA in real time for the status of one specific certificate: "Is serial number 0xDEADBEEF still valid?"
OCSP fixed bandwidth. It made privacy dramatically worse.
Every time you visit a website over HTTPS, your browser asks the CA — a third party — whether that website's certificate is still valid. The CA now has a real-time log of which sites you visit, on which device, at which moment. CAs essentially became browsing-history collection services by accident.
Worse, OCSP introduced a latency penalty. Your browser had to make an extra network round-trip — sometimes to a slow or geographically distant CA server — before completing every new TLS handshake. On slow connections, this added hundreds of milliseconds to page loads.
Soft-Fail: Revocation as Suggestion
The catastrophic failure mode came when the CA's OCSP responder was unreachable. If the browser couldn't get an answer, what should it do?
The strict answer — refuse to load the page — was unacceptable. Every time a CA had a five-minute outage, half the internet would go dark. So browsers adopted soft-fail: if the OCSP server didn't respond, assume the certificate is fine and proceed.
This makes revocation functionally advisory. Any attacker with the network position to intercept your TLS connection also has the position to block your OCSP request. Block the request, and the browser soft-fails into trusting the stolen certificate anyway. A 2014 paper from Adam Langley at Google put it bluntly: "revocation doesn't work."
The Stopgaps: Stapling and Must-Staple
OCSP stapling tried to patch the privacy and latency holes. The web server itself queries the CA periodically, gets a signed OCSP response, and "staples" it to its TLS handshake. The client never has to talk to the CA — it just verifies the staple.
Stapling helped, but adoption was uneven, and soft-fail still applied. Servers that didn't staple just fell back to the old model. The OCSP Must-Staple extension let certificates demand stapling — but few CAs and few server operators bothered.
By 2022, Let's Encrypt — the largest CA on earth by issuance volume — announced they were ending OCSP support entirely. Their reasoning was direct: the privacy cost was real, the security benefit was near-zero, and the operational burden of running OCSP responders for hundreds of millions of certificates was massive.
What Replaced It: Short-Lived Certificates
The web's answer to broken revocation turned out to be: don't revoke, expire.
In 2016, public CAs issued certificates valid for up to three years. The CA/Browser Forum has steadily ratcheted that down. By 2020 the maximum was 398 days. As of 2025, browser vendors are pushing toward 90-day maximums — and Let's Encrypt has offered 90-day certs since launch. Some CAs now issue six-day certificates.
Short lifetimes change the calculus completely. If a certificate is only valid for a week, the worst-case exposure window for a stolen key is one week — even with no revocation infrastructure at all. The attacker's certificate naturally expires; the legitimate operator gets a fresh one. Revocation becomes irrelevant for everyone except the highest-stakes cases.
| Mechanism | Status in 2026 |
|---|---|
| CRLs | Still issued by most public CAs, mostly ignored by browsers |
| OCSP | Let's Encrypt ended issuance; other CAs winding down |
| OCSP Stapling | Still supported but increasingly irrelevant |
| CRLite | Firefox compressed-CRL system; promising but limited adoption |
| Short-lived certificates | The de facto answer — 90 days now, trending shorter |
The Operational Cost: Automation or Bust
Short-lived certificates only work if renewal is automated. If you're renewing certificates by hand every 90 days, you'll forget, miss a renewal, and your site will go down. The ACME protocol — created by Let's Encrypt and now an IETF standard — solved the automation problem. Tools like certbot, lego, acme.sh, and Caddy's built-in client made renewal a cron job.
The trade-off is clear: shorter certificates, more automation. Lose the dependency on revocation infrastructure, gain a dependency on continuous, working ACME machinery. For most operators, that's a good trade. For organizations still managing certificates manually, the shift to 90-day lifetimes is forcing a long-overdue infrastructure investment.
What About Certificate Transparency?
Certificate Transparency is sometimes confused with revocation. It's not the same thing — CT logs make CAs accountable by publishing every certificate they issue, so misissuances become public. CT helps you discover bad certificates after the fact; it doesn't stop your browser from trusting one mid-attack. The two systems are complementary: CT catches misissuance, short lifetimes limit the blast radius of any single bad certificate.
What This Means for Users
For end users, the practical effect is invisible. Your browser still shows the padlock. Sites still load. What's changed underneath is that the lock is no longer backstopped by a real revocation system — it's backstopped by short certificate lifetimes plus the assumption that any compromise will be noticed and rotated within days, not months.
That's a reasonable trade-off for most threats, and a brittle one for some. If you're protecting infrastructure where a one-week compromise is unacceptable, you need certificate pinning, mutual TLS, or other defenses that don't depend on public PKI alone.
The Quiet Lesson
Certificate revocation is one of cryptography's clearest examples of a clean theoretical design that doesn't survive contact with operational reality. The original requirements — scale, freshness, privacy, fail-safe behavior, server uptime — turned out to be in irreconcilable tension. After two decades of trying to make revocation work, the web reduced the problem instead of solving it.
That's worth remembering when evaluating any cryptographic system that assumes an active feedback channel. The mechanism that depends on calling home in real time tends to break the moment calling home is hard.