How Revocation Checking Actually Works
A certificate can be revoked before it expires — a leaked private key, a domain changing hands, or a mis-issuance are all reasons. Which raises a simple-sounding question: how does the validating party know the certificate in front of it has been revoked? That question has had several different answers over twenty years.
OCSP was the dominant one: on connecting, the client asks the CA's server whether this certificate is still valid. It carries a structural problem, though — the CA thereby learns which IP address is visiting which website, inserting a third-party observer into every connection.
| Mechanism | How it works | Status |
|---|---|---|
| Direct OCSP query | Client asks the CA in real time on connection | Clear privacy problem; largely abandoned by browsers |
| OCSP stapling | Server queries on the client's behalf and attaches the result | Let's Encrypt shut the service down in Aug 2025 |
| CRL revocation lists | CA publishes a list that validators fetch themselves | Required by CA/B Forum since March 2024 |
| Chrome CRLSets | Google curates a subset and ships it with the browser | What Chrome has always actually used |
The table sets out four mechanisms and where each stands. The second row is the one most guides still teach and which no longer functions.
The Three Dates in Let's Encrypt's Shutdown
It wasn't switched off at once. Three stages, all now in the past:
- 30 January 2025: new Must-Staple requests stopped Must-Staple is a flag in the certificate requiring the client to see a valid stapled response before accepting the connection. It was meant to close the "stapling failed, carry on anyway" gap, at the cost that any stapling failure takes the site down outright. From this point most accounts could no longer request certificates carrying the flag.
-
7 May 2025: OCSP URLs dropped from certificates
The most widely felt step. With no OCSP URL in the certificate, the server has nothing to query, and directives like
ssl_stapling on;stop having any effect — no error, just silence. Plenty of configuration files still carry those lines today. - 6 August 2025: the OCSP responders were turned off The response servers went offline, so even older certificates still carrying an OCSP URL began failing their lookups. At current certificate lifetimes, those have long since expired and been replaced.
Why Retire a Security Mechanism
The first stated reason is privacy. Let's Encrypt puts it plainly: when a visitor accesses a website, the CA operating the OCSP responder immediately learns which site is being visited from that visitor's particular IP address. For an authority that has issued hundreds of millions of certificates, that amounts to an extraordinarily large browsing record.
The second is operational cost — running a real-time lookup service at global scale consumes considerable resources that could be spent elsewhere.
The direction was set earlier. In 2023 the CA/Browser Forum voted to make OCSP optional and CRLs mandatory, effective March 2024. Let's Encrypt's decision follows that, rather than standing alone.
What to Check Now
Start with leftovers in your configuration. Nginx's ssl_stapling on; and ssl_stapling_verify on;, Apache's SSLUseStapling on — with no OCSP URL in the certificate these cause no error, but they no longer do anything either. Leaving them does no harm; they're simply meaningless now.
Also confirm that commercial certificates behave differently. This was Let's Encrypt's decision, and some commercial CAs still run OCSP services. If you manage both free and commercial certificates, the two will behave differently — check whether a given certificate actually carries an OCSP URL before concluding anything.
Three Levels of Response
Handle each case on its own terms:
1. Establish whether the certificate has an OCSP URL
This determines everything else. No URL means stapling configuration is moot; a URL present (usually commercial certificates) means stapling still works and can stay. Don't assume it still functions because it was configured once.
2. Clear out dead configuration, without urgency
Leftover stapling directives cause no failures, so nothing needs fixing today. But remove them next time you touch the file — leaving them makes whoever inherits the system believe stapling is active, and debugging from a false premise wastes a great deal of time.
3. Understand what revocation actually covers
Don't assume revocation takes effect immediately. CRLs and CRLSets both have update cycles, and Chrome's CRLSets are a curated subset rather than a complete list. This is part of the backdrop to shrinking certificate lifetimes — the shorter the lifetime, the less revocation has to carry.
Three Things to Establish First
When something revocation- or stapling-related goes wrong, settle these before anything else:
- Which CA issued this certificate Let's Encrypt and commercial CAs now behave entirely differently here. Getting the issuer wrong sends the whole investigation off course.
- Whether stapling is actually functioning Configured isn't the same as working. Nginx logs a warning rather than refusing to start when it can't obtain an OCSP response, so the service looks perfectly healthy. Read the logs, not the config file.
- Whether the problem involves revocation at all Incomplete chains, expiry and hostname mismatches produce similar-looking errors and are far more common. Rule those out before pursuing revocation.
In Summary
"Remember to enable OCSP stapling" was once correct advice and no longer applies to Let's Encrypt certificates — there is no OCSP URL in the certificate, so the directive raises no error and silently does nothing. Outdated guidance like this circulates widely, and its harm isn't broken services; it's leaving people convinced a protection is running when it isn't.
Revocation is converging on CRLs and shorter certificate lifetimes. If you'd rather not track ecosystem shifts like this one, our SSL automation platform handles issuance and deployment so certificate management follows the standards without your watching each change.