Certificate revocation has always been the weakest link in the public-key system. We can issue certificates and we can expire them, but telling the world that a still-valid certificate should no longer be trusted has never worked cleanly. On August 6, 2025, Let's Encrypt turned off its OCSP responders for good, retiring a service that was answering roughly 340 billion requests a month at its peak. Most other CAs still run theirs, and no rule says they ever have to stop.
Why Revocation Never Worked
A certificate has an expiry date, but sometimes you need to kill one before then: the private key leaks, a server is compromised, or a certificate was issued in error. The hard part is telling every client, in near real time, without the mechanism becoming a privacy leak or a performance tax.
The first attempt was the Certificate Revocation List, a signed file listing every revoked serial number. A busy CA's CRL can be enormous, so clients cache it, and a cache means stale data.
The Online Certificate Status Protocol, standardized in 1999, replaced the download with a question: is this one serial still good? That fixed the size problem and created two others. It added a network round trip to a CA server during the handshake, and it handed the CA a log of which sites every user visited. Worse, most clients failed open. If the responder was unreachable, they treated it as a pass, which made the check trivial to bypass. OCSP stapling patched the round trip and the privacy hole by having the server fetch its own status and staple it to the handshake, but deployment was inconsistent and it never became universal.
Who Has Actually Turned It Off
The retreat is uneven. One large CA is fully out, one is partway, and the commercial tier is still running responders that answer on demand.
| CA | OCSP status | What happened | Where revocation lives now |
|---|---|---|---|
| Let's Encrypt | Off | Dropped OCSP URLs from certs in May 2025; shut responders down August 6, 2025 | CRL only |
| Google Trust Services | Mostly off | Stopped embedding OCSP in most chains during H2 2025 | CRL for most certs |
| Commercial CAs (DigiCert, Sectigo, GoDaddy) | Running | No change; OCSP stays optional | OCSP responders plus CRL |
A certificate with no OCSP URL cannot be OCSP-checked, so a client sees the same result whether the responder is up or gone. GoDaddy shows how little the brand on a site tells you. Its CA is still running, and a certificate from certs.godaddy.com carries http://ocsp.godaddy.com/ today. Yet godaddy.com itself is served by a Google Trust Services certificate with no OCSP pointer at all, because GoDaddy buys that one like any other customer. OCSP has been optional since the CA/Browser Forum made CRLs mandatory, so nobody buying a certificate today can assume it carries a responder.
Check What Your Own Certificates Carry
You do not have to take any of this on faith. One command reads the OCSP pointer straight off a live certificate. A commercial CA still hands you a responder URL; a current Let's Encrypt certificate hands you nothing.
# a commercial CA cert still carries an OCSP responder URL
$ echo | openssl s_client -connect digicert.com:443 -servername digicert.com 2>/dev/null \
| openssl x509 -noout -ocsp_uri
http://ocsp.digicert.com
# a current Let's Encrypt cert carries none (empty output)
$ echo | openssl s_client -connect generatorlabs.com:443 -servername generatorlabs.com 2>/dev/null \
| openssl x509 -noout -ocsp_uri
$
The pointer lives in the Authority Information Access extension. Dump the certificate text and the difference is plain: the DigiCert leaf lists an OCSP URI, the Let's Encrypt leaf lists only CA Issuers.
$ openssl x509 -in digicert.pem -noout -text | grep -A2 "Authority Information Access"
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertEVRSACAG2.crt
$ openssl x509 -in generatorlabs.pem -noout -text | grep -A1 "Authority Information Access"
Authority Information Access:
CA Issuers - URI:http://ye2.i.lencr.org/
Where a responder does answer, you can query it yourself. Point openssl ocsp at the URL with the leaf and its issuer, and a working responder reports the serial's status. This ran live against ocsp.digicert.com on 2026-07-14:
$ openssl ocsp -issuer chain.pem -cert digicert-leaf.pem \
-url http://ocsp.digicert.com -no_nonce
Response verify OK
digicert-leaf.pem: good
This Update: Jul 14 19:27:00 2026 GMT
Next Update: Jul 21 18:27:00 2026 GMT
Stapling is the other thing to check, because it is what most of your clients actually rely on. Ask for a stapled response in the handshake with -status. DigiCert staples one; the Let's Encrypt endpoint has nothing to staple.
# digicert staples a response
$ echo | openssl s_client -connect digicert.com:443 -servername digicert.com -status 2>/dev/null \
| grep "OCSP Response Status"
OCSP Response Status: successful (0x0)
# a Let's Encrypt endpoint sends none
$ echo | openssl s_client -connect generatorlabs.com:443 -servername generatorlabs.com -status 2>/dev/null \
| grep "OCSP response"
OCSP response: no response sent
How Long Before Everyone Else?
Nobody has committed to a date and no ballot forces one. What exists is a set of pressures pointing the same way.
Cost is one. Generating OCSP responses consumes the same signing capacity a CA needs to issue certificates, and the load scales with traffic to subscribers' sites, so it climbs as the web grows even while certificate sales stay flat. Google cited exactly that. Let's Encrypt cited privacy, which is not getting less important.
Certificate lifetime is the stronger force. Validity dropped to 200 days in March 2026, falls to 100 in March 2027, and reaches 47 in March 2029, the trend covered in why certificate lifetimes are getting shorter. As the window shrinks, expiry starts doing revocation's job on its own. The Baseline Requirements already take that to its conclusion: a certificate valid for 7 days or less needs no CRL and no OCSP at all.
The Forum has been blunt about the premise. The ballot that set the new lifetime schedule says certificate status services like CRLs and OCSP "do not adequately protect relying parties at the current scale of the internet." When the standards body says the mechanism doesn't work and running it costs real money, the remaining CAs will leave as their customers move to short-lived, automated certificates. Don't expect a flag day.
What Browsers Do Instead
Browsers gave up on OCSP years ago on their own. Firefox uses CRLite, which aggregates the CRLs published across the CA ecosystem, compresses them hard, and pushes the result to the browser out of band, so the client checks a local structure instead of phoning a CA mid-handshake. Chrome uses CRLSets, delivered the same way but carrying far less: a curated list covering revocations Google considers important, such as key compromise and CA-level events. A routine revocation of your leaf certificate will most likely never appear in one.
That gap is worth being honest about. A CRLSet is a partial list by design, and Chrome accepts the partial coverage to get something concrete in return: no round trip, no privacy leak, and no responder to fail open. The industry made that trade deliberately, having concluded that fail-open OCSP bought little security to begin with.
Here is the whole landscape this post has walked through, side by side:
| Mechanism | Where the check happens | Round trip in handshake | Privacy exposure | Carries a routine leaf revocation? | Status |
|---|---|---|---|---|---|
| CRL | Client downloads and caches the signed list | No (cached) | Low | Yes, full list | Mandatory since March 2024 |
| OCSP | Client queries the CA responder per certificate | Yes | Leaks browsing to the CA | Yes, per-serial | Optional, disappearing |
| OCSP stapling | Server pre-fetches and staples into the handshake | No | None | Yes | Optional, uneven deployment |
| CRLite (Firefox) | Local structure pushed out of band | No | None | Yes, aggregates ecosystem CRLs | Shipping in Firefox |
| CRLSets (Chrome) | Local list pushed with the browser | No | None | No, key-compromise and CA events only | Shipping in Chrome |
What This Changes for You
Run the OCSP URI check above against every CA you issue from. If it comes back empty, anything in your stack that queries OCSP for that certificate is already dead code: monitoring probes, custom health checks, a stapling config that now has nothing to staple. Let's Encrypt users are there today; everyone else gets there on a schedule the CA controls, with no warning you set.
The signal that protects you now is freshness. A certificate that rotates on a short cycle limits exposure better than a fail-open revocation check ever did, so the work that pays off is automating renewal and watching that the automation actually holds. For a quick manual look at what a host serves, the SSL certificate checker shows the live certificate and chain. To catch a renewal that silently stopped firing, point Generator Labs certificate monitoring at your endpoints and set an expiry alert with enough runway to act before the certificate goes cold.