Revocation has been broken for 15 years. Someone finally tried to fix it.
If you've worked with TLS for any length of time, you've probably heard the joke: certificate revocation is the problem everyone agrees exists and nobody agrees on how to solve. CRLs are too big. OCSP is too slow and leaks privacy. OCSP Stapling depends on server operators actually configuring it, which, yeah. Good luck with that.
Mozilla decided to try something different.
In 2020, Firefox started shipping CRLite, a system that compresses the revocation status of every certificate on the public web into a filter small enough to bundle with browser updates. We're talking about covering hundreds of millions of certificates in roughly 10 MB of data, pushed to your browser a few times per day. No network requests during the TLS handshake. No privacy leak. No soft-fail problem.
How do you compress millions of revocation entries into megabytes?
Bloom filters. Or more precisely, a cascade of Bloom filters.
The basic idea: take every certificate currently known through Certificate Transparency logs. For each one, check its revocation status via CRL. Then encode the "revoked" set and the "not revoked" set into a layered filter structure that allows lookups with zero false negatives and a tunable false positive rate.
A single Bloom filter would give you false positives, which means some valid certificates would incorrectly appear revoked. Bad. So CRLite stacks multiple filters: the first layer encodes revoked certs, the second layer encodes the false positives from layer one (marking them as "actually fine"), the third corrects the second's errors, and so on. After about four layers the false positive rate drops to effectively zero.
// Conceptual lookup (not actual Firefox code, but close enough)
function checkCRLite(certHash, filters) {
for (let i = 0; i < filters.length; i++) {
if (!filters[i].contains(certHash)) {
// Fell out of the cascade
// Even layers = not revoked, odd layers = revoked
return i % 2 === 0 ? 'NOT_REVOKED' : 'REVOKED';
}
}
// Made it through all layers, check parity
return filters.length % 2 === 0 ? 'REVOKED' : 'NOT_REVOKED';
}The clever bit is the delta updates. Firefox doesn't re-download the full filter every time. It ships small diffs, typically a few hundred KB, that patch the existing filter. Your browser updates its revocation database in the background without you ever noticing.
What Chrome does instead (and why it's controversial)
Google's approach is CRLSets. These are curated subsets of revoked certificates that Google considers "important enough" to push to Chrome. The key word is curated. Google decides which revocations make the cut.
In practice, CRLSets cover a tiny fraction of all revoked certificates. We're talking maybe tens of thousands of entries versus the millions that CRLite handles. Google's argument is pragmatic: most revocations don't matter because the certificate was being replaced anyway, and the ones that do matter (compromised CA keys, high-profile breaches) get manually added fast.
But that leaves a gap. If your organization's wildcard cert gets compromised and you revoke it, Chrome users probably won't know. Firefox users with CRLite will. Safari does its own OCSP checking with Apple's aggregated responder. Only Chrome just shrugs for the vast majority of revocations.
Real numbers from the field
A team at TU Graz ran measurements on CRLite coverage in late 2024. Their findings were pretty telling.
CRLite covered 99.84% of all certificates visible in CT logs. CRLSets covered about 2.3%. That's not a typo. And the coverage gap means real revoked certificates serving real websites go undetected by the world's most popular browser.
I've seen this play out at a fintech company that revoked a certificate after a suspected key compromise. Their security team assumed revocation meant "browsers will reject this cert." They were right for Firefox and Safari. Chrome users connected happily for another 47 days until the cert expired naturally. Nobody on the team realized Chrome doesn't do real revocation checking. The incident report was uncomfortable reading.
The privacy angle nobody mentions
Traditional OCSP is a privacy nightmare. Every time your browser checks a certificate's status, it sends the certificate serial number to the CA's OCSP responder. The CA can then build a profile of which websites you visit, when, and how often. It's like asking your ISP for directions to every house you visit.
OCSP Stapling fixes this by having the server fetch and cache the OCSP response, then "staple" it to the TLS handshake. But stapling is opt-in on the server side. Nginx supports it. Apache supports it. Actually configuring it correctly, with proper error handling when the OCSP responder is down? Most operators don't bother. Or they set it up once, it breaks silently three months later when the stapled response expires, and nobody notices because browsers soft-fail.
# nginx OCSP stapling config that looks correct but has a subtle issue
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8;
# Missing: ssl_trusted_certificate with the full chain
# Without it, stapling silently fails on some setups
# and you'll never know unless you test with:
# openssl s_client -connect yoursite.com:443 -statusCRLite sidesteps all of this. No network request, no privacy leak, no server configuration needed. The browser already has the answer locally.
Why hasn't everyone adopted CRLite?
Good question. Short answer: politics and engineering tradeoffs.
Google has publicly stated they don't think comprehensive revocation checking is worth the complexity. Their position (simplified): focus on shorter certificate lifetimes instead. If certificates only live 90 days, the window where a revoked cert can cause damage shrinks dramatically. Push lifetimes down to 47 days, which the CA/Browser Forum voted to do starting in 2026, and revocation becomes even less critical.
There's logic there. But it ignores the cases where 47 days of a compromised certificate is still way too long. Financial services. Healthcare. Government systems. These environments can't just shrug off a seven-week window of potential MitM exposure.
Apple went a middle route with their own aggregated OCSP checking, where Safari queries Apple's servers rather than the CA directly. Better for privacy than raw OCSP, but still requires a network call. And Apple's responder has had its own availability issues.
What you should actually do about this
If you're running a web service and you care about revocation actually working when you need it:
Configure OCSP Stapling properly. Yes, even though it's imperfect. It helps Safari users and some enterprise environments. Test it regularly.
# Quick test script for OCSP stapling health
#!/bin/bash
DOMAIN=${1:-"example.com"}
RESULT=$(echo | openssl s_client -connect "$DOMAIN:443" -status 2>/dev/null | grep -i "OCSP Response Status")
if echo "$RESULT" | grep -q "successful"; then
echo "OCSP stapling is working for $DOMAIN"
else
echo "WARNING: No OCSP staple detected for $DOMAIN"
echo "Browsers using soft-fail OCSP may still connect to revoked certs"
fiMonitor CT logs for your domains. If someone issues a fraudulent certificate for your domain and it later gets revoked, you want to know about that independent of browser behavior. Tools like CertGuard do this automatically.
Don't rely solely on revocation for incident response. If a key is compromised, revoke the cert AND rotate everything, AND update your CAA records, AND consider deploying new certificates from a different CA if you suspect the CA's issuance pipeline was part of the problem. Revocation is one layer, not the whole defense.
Push for shorter certificate lifetimes in your infrastructure. If your certs already renew every 30 days via ACME, a revocation gap matters much less than if you're sitting on annual certificates from a traditional CA.
Where this is heading
The CA/Browser Forum's push toward 47-day certificate lifetimes (with 10-day revalidation by 2029) will reshape this debate entirely. When certificates live for barely over a month, the practical impact of a missed revocation drops. But we're not there yet. Most organizations are still running 90-day or even yearly certificates.
Meanwhile, CRLite keeps getting better. Mozilla's been iterating on the filter size and update frequency. The latest versions push updates every 6 hours, which means a newly revoked certificate shows up in Firefox within a quarter of a day. Compare that to CRLSets, where the turnaround depends on Google's curation process, or traditional CRLs that some CAs only update every 24 hours.
For now, the uncomfortable truth is that revocation checking depends almost entirely on which browser your users happen to be running. And that's a terrible security property for a system that's supposed to be the backbone of web trust.