Certificate revocation is the part of PKI that always sounds solved when someone is explaining it at a whiteboard and always sounds broken when someone is explaining what actually happens in browsers.
The theory is simple. If a certificate is compromised or misissued, revoke it. The world should stop trusting it.
The practice is a parade of half-measures, stale data, soft-fail logic, and backup plans for the backup plans.
CRL: The Big List Nobody Downloads
Certificate Revocation Lists were the original answer. The CA publishes a list of revoked certificate serial numbers. Clients download the list and check whether the certificate they’re looking at is on it.
The problems are obvious at scale. CRLs grow large — some CAs have lists with hundreds of thousands of entries. Downloading megabytes of revocation data before you can verify a single certificate adds latency that nobody will tolerate. Caching helps but means you’re checking against stale data — a certificate revoked an hour ago might not appear on your cached list for days.
Browsers gave up on CRLs years ago. Chrome stopped checking CRLs in 2012. Firefox largely stopped too. The lists still exist — CAs still publish them — but almost nothing consults them in real time anymore.
OCSP: The Real-Time Check That Isn’t
Online Certificate Status Protocol was the improvement. Instead of downloading the entire list, ask the CA in real time: “Is this specific certificate revoked?”
The CA runs an OCSP responder — an HTTP endpoint that returns signed “good,” “revoked,” or “unknown” for a given serial number.
Better in theory. Terrible in practice.
Latency. Every new TLS connection now requires an additional HTTP request to the CA’s OCSP responder before the handshake can complete. That’s 50-200ms of added delay, depending on where the responder is. Users won’t tolerate it.
Privacy. The OCSP request tells the CA exactly which site you’re visiting and when. The CA now has a log of your browsing habits. Not great for a system that’s supposed to improve security.
Availability. The OCSP responder becomes a single point of failure. If it’s down, what happens? The right answer is “reject the certificate” — fail closed. The actual answer in every browser is “accept the certificate anyway” — fail open. Because failing closed means every site behind that CA goes down whenever the responder hiccups.
This soft-fail behavior defeats the entire point. If an attacker compromises a certificate and also blocks your OCSP requests (trivial for a network-level attacker), your browser shrugs and accepts the compromised cert. The revocation check existed on paper only.
OCSP Stapling: Better, But Optional
Stapling fixes two of OCSP’s problems. Instead of the browser asking the CA, the server fetches its own OCSP response periodically and “staples” it to the TLS handshake. The browser gets the freshness proof without a separate round-trip, and the CA never sees the client’s request.
No latency hit. No privacy leak. Elegant.
The catch: stapling is optional. If the server doesn’t staple a response, the browser falls back to either direct OCSP (with all its problems) or no check at all. And many servers don’t staple. Some web servers don’t enable it by default. Some administrators don’t know it exists. Some stapling implementations are buggy and intermittently fail.
The result: stapling works perfectly when it works, and is invisible when it doesn’t. The sites that bother to configure it are usually the sites that need it least — the well-maintained ones. The sites that need it most — the neglected ones with forgotten certificates — don’t have it.
OCSP Must-Staple: The Fix Nobody Adopted
There’s a certificate extension called Must-Staple (RFC 7633). A certificate with Must-Staple tells browsers: “If this certificate doesn’t come with a stapled OCSP response, reject it.”
This closes the fallback hole. No staple? Hard fail. The browser won’t accept the certificate without proof that it hasn’t been revoked.
Adoption is minimal. Must-Staple is terrifying to server operators because a stapling failure — the OCSP responder is slow, the cached response expired, the renewal script broke — means your site goes down. Not degraded. Down. You’ve turned an optional check into a hard dependency on your CA’s infrastructure.
The failure mode is too harsh for most operators to accept. So they don’t enable it, and the soft-fail problem continues.
CRLite: Mozilla’s Clever Approach
Mozilla built CRLite — a compressed representation of all revoked certificates, pushed to Firefox as a filter. It’s a cascade of bloom filters that can represent the entire set of revoked certificates in a few megabytes, updated daily.
The browser doesn’t need to contact the CA at all. The revocation data is already local. No latency, no privacy leak, no availability dependency.
CRLite is a genuinely good idea. It’s also Firefox-only. Chrome doesn’t use it. Safari doesn’t use it. The revocation problem is “solved” differently in every browser, which means it’s not really solved.
Short-Lived Certificates: Implicit Revocation
This might be the real answer. If certificates last 24-48 hours, revocation becomes nearly irrelevant. A compromised certificate expires before traditional revocation mechanisms would have caught up anyway.
Let’s Encrypt pioneered 90-day certificates. The industry is pushing toward shorter. Let’s Encrypt is moving to 64 days, then 45. Google has proposed even shorter lifetimes.
At 24-hour certificate lifetimes, the revocation problem effectively disappears. The certificate is its own revocation mechanism — it simply stops being valid. No CRLs, no OCSP, no stapling needed. The tradeoff is total dependence on automation. If your renewal pipeline breaks, your site goes down within hours.
The Unsolved Problem
Twenty-five years of trying, and certificate revocation still doesn’t work reliably. CRLs are too big. OCSP is too slow, too fragile, and soft-fails. Stapling is optional. Must-Staple is too scary. CRLite is browser-specific. Short-lived certificates are promising but not yet the default.
The honest state: if a certificate is compromised today, most browsers will continue trusting it until it expires. The revocation mechanisms exist. They just don’t work well enough to rely on.
That’s why the push for shorter certificate lifetimes matters more than any revocation protocol improvement. If you can’t reliably tell the world a certificate is bad, at least make sure it stops being valid quickly.