Why a revoked certificate still works
A revoked certificate is supposed to be dead. The private key leaked, the domain changed hands, the CA made a mistake, whatever the reason, revocation exists so that a certificate can be killed the moment it becomes dangerous. And yet, on a huge share of real connections, a browser or app will happily complete a TLS handshake with a certificate that’s been sitting on a revocation list for weeks. That’s not a bug anyone is quietly patching. It’s a design decision made over a decade ago, and it still shapes how trust actually works on the internet.
How a CA marks something dead
When a certificate authority revokes a certificate, it doesn’t reach into every browser on earth and delete it. It just updates its own records to say “this serial number is no longer valid” and publishes that fact through one of two channels: a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP). Both are just ways for a client to ask, or be told, “is this specific certificate still good.” Neither one actually stops the certificate from existing or from cryptographically verifying. The private key still works. The chain of trust up to the root still checks out. Revocation is a side channel, not a kill switch baked into the certificate itself.
CRLs: the original answer
A CRL is a signed list of every revoked serial number a CA has ever issued, bundled into one file the client downloads and checks locally. It scales badly. CAs that issue millions of certificates end up publishing CRLs that are enormous, and a client checking every connection against a multi-megabyte list is slow and wasteful. Most modern TLS stacks barely bother with CRLs anymore outside of enterprise and government PKI, where compliance rules force the issue. For the ordinary web, CRLs are largely a formality that gets published because the standards require it, not because anything is actively fetching and parsing it on every handshake.
OCSP: faster, but it phones home
OCSP replaced the “download the whole list” model with a single targeted question: client sends the certificate’s serial number to the CA’s OCSP responder, responder replies “good,” “revoked,” or “unknown.” That sounds like the fix. It’s real time, it’s lightweight, and it should mean a revoked certificate gets rejected the instant a client checks. The catch is that it depends on a live network round trip to a third party, on every handshake, for every site, for every user. That’s a lot of extra latency and a lot of extra load on CA infrastructure, and it introduces a new failure mode: what happens when the OCSP responder doesn’t answer.
The soft-fail decision that quietly broke the model
This is the part that actually explains why revoked certificates keep working. When an OCSP request times out, gets blocked, or the responder is simply down, browsers had two choices: refuse the connection (hard-fail) or proceed as if the certificate were fine (soft-fail). Almost every mainstream browser chose soft-fail, because CA infrastructure is not reliable enough to make hard-fail viable at internet scale. A hard-fail policy means one flaky OCSP server can take down every site that uses that CA. Soft-fail means the security check is only as strong as its weakest link, and the weakest link is “did the network let this request through.” Anything sitting between the client and the OCSP responder, a firewall, a captive portal, a proxy, a bad DNS resolver, can cause that check to fail silently, and the browser will trust the certificate anyway. Chrome’s own engineers documented this tradeoff publicly years ago: an active network attacker who can block one query can neutralize the entire revocation check, so treating it as a hard security boundary was misleading to begin with.
Why browsers stopped leaning on it
Because soft-fail OCSP provides such weak guarantees, the major browsers largely stopped relying on live, per-connection OCSP checks as their primary defense. Chrome built CRLSet, a compact, curated list of the revocations Google considers significant enough to push directly through browser updates. Firefox does something similar with OneCRL. These are not comprehensive; they cover major incidents, mass key compromises, CA mistakes that made news, not the routine day-to-day revocation of an individual site’s certificate. If a small business revokes its certificate because an employee accidentally exposed the private key, there’s a real chance most visiting browsers never learn about it in any way that changes their behavior. The live check most people assume is happening on every padlock icon, in practice, either doesn’t run, or runs and fails open.
What this looks like from inside real infrastructure
Anyone who operates TLS termination at scale, whether that’s a reverse proxy fleet, a corporate inspection box, or an anti-detect browser stack doing its own certificate handling, runs into this constantly. Revocation checks add a network hop and a point of failure to every single connection, and at volume that cost is real. Plenty of TLS libraries and HTTP clients used in scraping, proxying, and mobile app stacks simply ship with revocation checking off by default, not as a deliberate evasion move but because checking against a CA in real time doesn’t fit a system that’s already routing traffic through rotating IPs, unreliable upstream links, or sandboxed network paths where an OCSP request might not even resolve. The practical effect is the same either way: a certificate can be sitting on a revocation list and still sail through, because the layer that was supposed to check it either wasn’t built to, or quietly gave up and moved on.
The metadata problem nobody asked for
There’s a second reason browsers cooled on live OCSP, separate from reliability: it leaks information. Every OCSP query tells the CA exactly which certificate a specific client is trying to validate at a specific moment, which is a fairly precise signal of which site someone is visiting, sent in the clear to a third party that isn’t the site itself. A protocol built to protect users from bad certificates was also quietly handing a browsing history breadcrumb to every CA on the internet. OCSP stapling addresses this by having the web server itself fetch a signed OCSP response periodically and attach it to the TLS handshake, so the client never has to contact the CA directly. It helps privacy and cuts latency, but it only works if the server bothers to staple, and a site can still present a stale or missing staple without the connection failing, because soft-fail is still the default underneath it.
Where the industry is actually headed
Rather than trying to fix revocation checking, the CA/Browser Forum and major browser vendors have been pushing the industry in a different direction entirely: shrinking how long a certificate is allowed to live in the first place. Maximum certificate validity has already dropped from years to about a year, and the industry has agreed to keep compressing it further over the next several years, toward lifetimes measured in weeks. The logic is straightforward. If a certificate expires in a few weeks instead of over a year, a compromised or mis-issued certificate has a much smaller window to do damage even if revocation never catches it, which sidesteps the soft-fail problem instead of solving it. It’s a admission, in effect, that revocation as originally designed never worked reliably enough to be the actual safety net.
What “revoked” really means today
Revocation isn’t nothing. Certificate Transparency logs make it possible for researchers, CAs, and site operators to see every certificate that’s ever been issued for a domain, including the ones later revoked, which is how mis-issuance and key compromise usually get caught and cleaned up after the fact. CRLSet and OneCRL do stop the handful of incidents severe enough to warrant a forced push. But for the ordinary case, a certificate someone revoked on a Tuesday because a key leaked, there’s no guarantee any given client will ever notice before that certificate’s natural expiration date arrives on its own. Revocation behaves less like a lock and more like an incident report that most doors never bother reading.
Want more of the internet’s trust machinery taken apart like this? Head back to the Hidden Internet home page for the rest of the series.
Get new guides and videos first — join the Telegram channel.