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.

OCSP vs CRL in One Paragraph

A CRL is a list: the CA publishes every revoked serial number it has issued, and the client downloads the whole thing and looks itself up. OCSP is a question: the client asks the CA about one certificate and gets back a signed “good,” “revoked,” or “unknown.” On performance, the tradeoff is where you pay. A CRL costs bandwidth up front but can then be checked offline for as long as you’re willing to trust a stale copy. OCSP costs a network round trip, and a privacy leak, on every connection whose answer isn’t cached, and it fails whenever the responder is slow or unreachable. Stapling moves that OCSP round trip from the browser to the server. None of the three, used the way they were designed, worked well in browsers. What finally works is a fourth thing built out of the first one.

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; a big CA’s list can run to hundreds of thousands of entries. Downloading megabytes of revocation data before you can verify a single certificate adds latency nobody will tolerate. Caching helps, but then you’re checking against stale data: a certificate revoked an hour ago won’t show up until your cached copy is replaced.

Browsers gave up on fetching CRLs live long ago. In 2012 Chrome turned off online revocation checks by default and replaced them with CRLSets, a small list Google compiles from CA revocation data and pushes through Chrome’s updater. Firefox stuck with OCSP. The lists themselves never went away, and that turns out to matter.

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 a signed status for a given serial number.

Better in theory. Terrible in practice.

Latency. A connection to a site whose status isn’t already cached needs an extra HTTP request to the CA’s responder before the browser can trust the certificate. That’s a full extra round trip to someone else’s server, on top of the TLS handshake.

Privacy. The OCSP request tells the CA exactly which site you’re visiting and when. It usually travels over plain HTTP, so everyone on the path learns it too. Not great for a system that’s supposed to improve security.

Availability. The 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 browsers was “accept the certificate anyway”: fail open. Failing closed would mean 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 direct OCSP (with all its problems) or to no check at all. 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 neglected sites with forgotten certificates don’t have it.

OCSP Must-Staple: The Fix Nobody Adopted

There’s a certificate extension, the TLS Feature extension from RFC 7633, better known as Must-Staple. A certificate carrying it tells browsers: “If this certificate doesn’t come with a stapled OCSP response, reject it.”

This closes the fallback hole. No staple? Hard fail. At least in Firefox, which enforced it; Chrome never did.

Adoption stayed minimal. Must-Staple terrifies server operators because a stapling failure (the 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. In 2025 Let’s Encrypt stopped issuing Must-Staple certificates altogether, which settles the question for most of the web.

CRLite: Mozilla’s Clever Approach

Mozilla built CRLite: a compressed encoding of every revoked certificate in the Web PKI, pushed to Firefox ahead of time. It shipped on by default in desktop Firefox 137 in April 2025. Mozilla puts the full package at about 6.7 MB, with delta updates every few hours that are tiny by comparison. Since Firefox 142, desktop Firefox no longer sends OCSP queries for domain-validated certificates at all.

The browser doesn’t need to contact the CA. The revocation data is already local. No latency, no privacy leak, no availability dependency, and no soft-fail hole for an attacker to exploit.

CRLite is a genuinely good idea. It’s also Firefox-only. Chrome still relies on CRLSets, a curated subset rather than the full set. Safari doesn’t use CRLite either. Revocation is now “solved” differently in every browser, which means it’s solved in one of them.

Where Things Stand in 2026: OCSP Lost

Here is the twist. In 2023 the CA/Browser Forum passed Ballot SC-063, which made OCSP optional for public CAs and CRLs mandatory. Let’s Encrypt, which issues a huge share of the web’s certificates, then shut its OCSP service down in stages: Must-Staple requests began failing on January 30, 2025, new certificates stopped carrying an OCSP URL on May 7, 2025, and the responders went dark on August 6, 2025. Its stated reasons were privacy and the cost of answering billions of OCSP queries.

So the big list nobody downloads won. Browsers still don’t fetch CRLs one by one. Mozilla and Google fetch them, condense them, and ship the result to browsers. The CRL became raw material.

For operators this has a practical consequence. If your certificate comes from Let’s Encrypt, there is nothing to staple; nginx will log that ssl_stapling was ignored because the certificate has no OCSP responder URL. That’s expected, not a misconfiguration. Stapling still does its job for CAs that keep running OCSP responders, but it’s no longer the direction the web is moving.

Short-Lived Certificates: Implicit Revocation

This is the other real answer. If a certificate lasts a few days, revocation barely matters: a compromised certificate expires before any revocation mechanism would have reached most clients anyway.

Let’s Encrypt launched in 2015 with 90-day certificates and made them normal. Since January 2026 it offers opt-in six-day certificates. Its default is scheduled to drop to 64 days in February 2027 and 45 days in February 2028. The CA/Browser Forum’s Ballot SC-081 forces the whole industry the same way: maximum validity fell from 398 to 200 days on March 15, 2026, drops to 100 days in March 2027, and to 47 days in March 2029.

At lifetimes of a few days, the certificate is its own revocation mechanism. It simply stops being valid. The tradeoff is total dependence on automation. If your renewal pipeline breaks, your site goes down within days.

The Unsolved Problem

Decades of trying, and revocation still doesn’t work the same way everywhere. Live CRL downloads were too slow. OCSP was too slow, too leaky, and soft-failed. Stapling was optional. Must-Staple was too scary, and it’s gone. CRLite works, but in one browser.

The honest state: if a certificate is compromised today, Firefox will learn about the revocation within hours. Chrome will learn about it if it makes CRLSets. Elsewhere, the certificate may simply be trusted until it expires.

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.