Certificates expire on a fixed date, but sometimes one has to be killed early — a private key leaks, a server is decommissioned with the key still on it, or a domain changes hands. Revocation is the mechanism for declaring a still-valid certificate dead before its expiry. The surprising part, once you look closely, is how poorly it has worked in practice — and how the entire industry spent 2025 and 2026 quietly rebuilding it. This guide explains the two classic methods, CRL and OCSP, why browsers learned to ignore both, and what's replacing them.
In short
A CRL is a downloadable signed list of revoked certificates; OCSP is a real-time per-certificate status query. Both have been undermined by soft-fail — browsers proceed when the check is unreachable — so neither reliably stops a stolen certificate. In 2025 Let's Encrypt shut down OCSP entirely over privacy, the CA/Browser Forum made OCSP optional and required CRLs, and browsers moved to pre-computed local lists (Chrome's CRLSets, Firefox's CRLite). The real long-term fix is shorter certificate lifetimes.
What revocation is — and why it's hard
A certificate is a signed statement from a Certificate Authority that says, in effect, "this public key belongs to this domain, and you can trust it until this date." Once signed, that statement is out in the world and the CA can't unsign it. So when the underlying assumption breaks — most urgently, when the matching private key is no longer a secret — the CA needs a way to publish a correction: ignore the one I signed earlier; it's no longer trustworthy. That correction is a revocation.
The hard part isn't recording the revocation; it's delivery. Every client that might encounter the certificate has to learn it was revoked, and learn it quickly, and learn it even though the certificate itself still looks perfectly valid — correct signature, unexpired date, matching hostname. The whole TLS handshake is designed to work offline from the CA; revocation asks the client to phone home anyway, at exactly the moment a user is waiting for a page to load. That tension — between checking thoroughly and not slowing every connection to a crawl — is the reason revocation has never quite worked, and it shapes everything below.
Revocation sits alongside the other safeguards that keep the trust system honest. If you haven't met them yet, the certificate chain explains how a browser decides a certificate is genuine in the first place, and CAA records control which CAs are even allowed to issue for your domain. Revocation is what happens after issuance, when a previously-good certificate has to be pulled.
Certificate Revocation Lists (CRL)
The original approach, defined in RFC 5280, is the simplest to picture. The CA maintains a single file — the Certificate Revocation List — containing the serial number of every certificate it has revoked but that hasn't yet expired, along with the date and a reason code. The CA signs the whole list and publishes it at a URL embedded in each certificate (the CRL Distribution Point). A client that wants to check a certificate downloads the list, verifies the CA's signature on it, and looks to see whether the certificate's serial number is present.
The appeal is that it's self-contained and cacheable: download once, check many certificates from that CA, no further network round trips until the list expires. The problem is scale. A busy CA can revoke hundreds of thousands of certificates, and a naïve client would have to download a multi-megabyte file before completing a handshake — far too slow to do on every connection. Historically that's exactly why CRLs fell out of favor for in-browser checking: the list got too big to fetch inline. The reason codes, though, are genuinely useful and still carried today — common ones include keyCompromise, superseded, cessationOfOperation, and the temporary certificateHold.
Why CRLs are back: the size objection assumed every client downloads the raw list inline. Modern browsers don't — they let an intermediary (Google, Mozilla) crawl all the CRLs, compress the result into a tiny structure, and push it out with browser updates. The client checks revocation locally, instantly, and never tells the CA which site it's visiting. That reframes the CRL from "too big to fetch" into "the ideal source data," which is exactly the bet the 2023 CA/Browser Forum vote made.
OCSP: real-time status checks
The Online Certificate Status Protocol, defined in RFC 6960, was designed to fix the CRL size problem by inverting it. Instead of downloading the entire list, the client sends the CA's OCSP responder a small request asking about one certificate, identified by its serial number, and gets back a small signed answer: good, revoked, or unknown. The response is signed by the CA, so it can't be forged, and it's tiny, so it's fast to transfer.
On paper this is strictly better than a CRL: no multi-megabyte download, and the answer is current rather than as-of-last-publication. In practice OCSP introduced two new problems that ultimately proved fatal. The first is performance: the browser now makes an extra network request, to a third party, in the middle of every handshake — and if that responder is slow, the whole page waits. The second is privacy, and it's the one that finally sank it: every OCSP request tells the certificate authority which site you're about to visit, when, and from roughly where. A CA serving billions of those requests a day is sitting on a real-time map of a large fraction of the web's browsing activity. That privacy cost is precisely what Let's Encrypt cited when it decided to walk away from OCSP entirely.
The soft-fail problem
Here's the flaw that makes both CRL and OCSP far weaker than they look. Suppose the browser tries to check a certificate's status and the check fails — the OCSP responder is down, the CRL is unreachable, a captive portal is blocking the request, the network is just slow. What should the browser do? Refusing to connect (hard-fail) means a CA outage takes a chunk of the web offline, and means anyone behind a firewall that blocks revocation traffic can't browse at all. So browsers overwhelmingly chose the other option: soft-fail — if the check can't be completed, assume the certificate is fine and proceed.
Why soft-fail breaks the whole point
An attacker who has stolen a private key and is using the revoked certificate to impersonate a site is, by definition, already in a position to control the victim's network path. So they simply block the revocation check too. The browser can't reach the responder, soft-fails, and connects to the attacker anyway — using the very certificate that was revoked to stop exactly this. Revocation only bites the honest case; the attack it was built to prevent walks straight through it.
This isn't a bug anyone overlooked — it's an acknowledged, structural compromise. It's also why "is revocation working?" has a genuinely uncomfortable answer, and why the fixes that follow don't try to make online checking reliable. They try to make online checking unnecessary.
OCSP stapling and Must-Staple
OCSP stapling was the cleverest patch on the OCSP era, and for years the recommended best practice. The idea: instead of every visitor's browser pestering the CA, the web server fetches its own OCSP response periodically, caches it, and "staples" that signed, time-stamped response directly into the TLS handshake. The browser gets the revocation proof for free, in the same exchange as the certificate — no extra request, no privacy leak to the CA, no latency penalty. It fixed OCSP's two practical problems in one move.
Stapling alone is still soft-fail, though: if the server doesn't staple a response, the browser falls back to assuming the certificate is good. OCSP Must-Staple (RFC 7633) was the answer — an extension baked into the certificate itself that tells browsers "this certificate must always arrive with a stapled response; if it doesn't, refuse the connection." That converts soft-fail into hard-fail for that one site, closing the gap. In practice Must-Staple never reached wide adoption — a single failed staple fetch could take your site down — and as OCSP itself winds down, it's being retired: Let's Encrypt stopped issuing Must-Staple certificates in 2025.
Is stapling still worth configuring?
Only if your certificate still has an OCSP URL to staple from. Certificates from CAs that have shut OCSP down (Let's Encrypt among them) have nothing to staple, so the setting is a no-op. Where OCSP is still offered, stapling remains a sensible performance and privacy win. Our OCSP stapling guide walks through enabling and verifying it on Nginx, Apache, and IIS.
What browsers actually do
Faced with soft-fail and OCSP's privacy cost, the major browsers stopped relying on live, per-connection checks and built their own pre-computed revocation data instead — downloaded in advance, checked locally, with no request to any CA at connection time.
Chrome — CRLSets
Chrome long ago disabled online OCSP and CRL checks for most certificates and instead ships CRLSets: a curated list of revoked certificates that Google compiles and pushes out through Chrome's component-update channel. It's fast and private, but it's deliberately not comprehensive — Google curates which revocations make the cut, so CRLSets function mainly as an emergency block-list for high-impact revocations rather than a complete record of everything every CA has revoked.
Firefox — CRLite
Mozilla took the more ambitious route. CRLite crawls the CRLs of all publicly-trusted CAs and compresses the entire set of revoked certificates into a compact filter — only a few megabytes — that ships to the browser and is queried locally. It aims for the comprehensiveness of CRLs with the speed and privacy of a local check. Mozilla enabled CRLite for all desktop Firefox users in 2025 and began turning off live OCSP for domain-validated certificates in favor of it.
The common thread: revocation moved from "ask the CA at connection time" to "download a compressed snapshot ahead of time and check it locally." That's faster, leaks nothing to the CA, and — crucially — can be made hard-fail, because a local lookup never has a network hiccup to soft-fail on. It also explains why the raw CRL, the oldest mechanism, turned out to be the right source data after all.
2025–2026: the move back to CRLs
The pieces came together in a clear sequence. In 2023 the CA/Browser Forum passed Ballot SC-063 — "Make OCSP Optional, Require CRLs, and Incentivize Automation." It reversed two decades of direction: running an OCSP responder became optional for CAs, while publishing CRLs became mandatory, with rules requiring revocation information to appear in the CRL within 24 hours of a certificate being revoked. The Forum was, in effect, blessing the browsers' move to CRL-derived local checking.
Let's Encrypt — the largest CA in the world by certificate volume — acted on it decisively, citing the privacy cost of its OCSP responders fielding billions of requests a day. Its timeline:
| Date | Change |
|---|---|
| Jan 30, 2025 | New OCSP Must-Staple issuance restricted (only accounts with prior Must-Staple certificates). |
| May 7, 2025 | OCSP URLs removed from newly issued certificates; CRL URLs added instead. Must-Staple issuance ends entirely. |
| Aug 6, 2025 | OCSP responder service shut down. Revocation is served exclusively via CRLs. |
Other CAs still operate OCSP, so it hasn't vanished from the web — but the largest issuer has left, the standards body has made it optional, and the biggest browsers prefer their own local data. The direction is unambiguous: OCSP is winding down, CRLs are the published source of truth, and clients consume them through compressed local snapshots rather than inline downloads. This is part of the same broad modernization as the 2026 domain-validation changes — the Web PKI tightening and automating its plumbing across the board.
Short-lived certificates: the real fix
Step back and the deepest answer to "revocation is broken" isn't a better revocation system at all — it's making certificates expire so fast that revocation rarely matters. A revoked certificate is only dangerous for as long as it would otherwise have stayed valid. Cut the maximum lifetime and you shrink the window a stolen certificate is useful, automatically, without depending on any client successfully fetching a status.
That's exactly the road the CA/Browser Forum is on. Maximum certificate validity has already dropped to 199 days, and the agreed schedule continues downward to 47 days by 2029. The stated rationale is precisely this: automation-driven short lifetimes are a more dependable safety net than revocation checking that soft-fails. If a key is compromised, a certificate that expires in days rather than a year limits the damage on its own. Revocation becomes the backstop, not the frontline — and the way you keep up with rapid expiry is automated ACME renewal, which is why SC-063's full title pairs "require CRLs" with "incentivize automation."
What this means for you
For most site owners, the practical takeaways are short:
- Don't lean on revocation as an emergency stop. Because of soft-fail, revoking a certificate doesn't reliably and instantly lock attackers out. If a private key is exposed, revoke it and rotate to a fresh key pair and reissue — treat the old key as permanently burned, not merely flagged.
- Check whether OCSP stapling is still doing anything. If your certificate no longer carries an OCSP URL (true for Let's Encrypt since May 2025), the stapling directives in your server config are inert. They won't hurt, but they're not protecting anyone either. Where your CA still publishes OCSP, leave stapling on.
- Automate renewal and shorten lifetimes. The single most effective thing you can do for the post-OCSP world is make renewal automatic, so you can run short-lived certificates without operational pain. That's the mechanism the whole ecosystem is betting on in place of reliable revocation.
- Know how to revoke when you genuinely need to. Through your provider's panel for a commercial certificate, or
certbot revokefor ACME. It's still the correct first move on a key compromise — just not the last one.
Revocation is a quietly fascinating corner of the Web PKI: a mechanism everyone agreed was essential, that never quite worked as designed, and that the industry is finally fixing not by perfecting it but by routing around it. If you want the layer underneath — how a browser decides to trust a certificate before revocation ever enters the picture — start with how SSL works and the certificate chain.