The OCSP stapling line in your config now does nothing

Every TLS hardening guide written in the last decade contains a line telling you to turn on OCSP stapling. It is in the nginx snippet everyone copies, it is in the Apache one, and it is in the checklist your client's security auditor is working from.

On a large share of the certificates in use today it is now a no-op, because the thing it staples no longer exists.

What it was for

Revocation is the mechanism for saying a certificate should no longer be trusted before its expiry date, usually because a key was compromised. The question "has this been revoked" has to be answered by the issuer, which means somebody has to ask them.

Without stapling, the client asks. Your visitor's browser, mid-handshake, makes a request to the certificate authority's responder and waits for the answer. Three costs follow from that. Latency, on a connection that has not yet loaded anything. A dependency on the authority's infrastructure being up and fast. And a privacy leak, because the authority now knows that a particular address looked at a particular site at a particular moment.

Stapling moves the work to the server. Your server asks the responder periodically, caches the signed answer, and attaches it to the handshake. The response is signed by the authority so it cannot be forged, and it carries its own validity window so it cannot be replayed indefinitely. Same guarantee, no third-party round trip for the visitor.

It is a good design. It was also solving a problem that turned out to be mostly theatre.

The part the guides leave out

Browsers soft-fail. If the revocation check cannot be completed, because the responder is unreachable or slow or returns nothing useful, the connection proceeds as though the certificate were fine.

That has to be the behaviour, because the alternative is that an authority's outage takes down every site it has issued for. It also means revocation checking never accomplished the thing it was for: an attacker positioned to use a stolen certificate is also positioned to block the revocation query, and blocking it produces exactly the same outcome as a clean check.

The industry's response, over several years, was to stop relying on revocation and to shorten certificate lifetimes instead. A certificate that lives ninety days is one that revocation matters much less for, because the worst case is bounded by the expiry rather than by whether a check succeeded.

What changed, and when

Let's Encrypt announced the end of its OCSP service and set out the schedule: from 7 May 2025 its certificates stopped carrying OCSP URLs and requests for the Must-Staple extension began failing, and on 6 August 2025 the responders were shut off entirely (Let's Encrypt, "Ending OCSP Support in 2025", consulted 1 August 2026). Revocation for those certificates is published through certificate revocation lists instead.

The consequence for a server configuration is direct. Stapling requires a URL in the certificate to fetch the response from. No URL, nothing to fetch, nothing to staple. Your ssl_stapling on; line parses, starts, and quietly does nothing at all.

Finding out what your server is actually doing

Ask the certificate whether it names a responder:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -ocsp_uri

Empty output means there is nothing to staple and the configuration directive is decorative.

Then ask the handshake whether a response is being attached:

echo | openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null \
  | grep -A2 'OCSP response'

"No response sent" is expected on a certificate with no responder. On a certificate that does have one, it means stapling is configured and not working, which is the state worth knowing about.

And check for the extension that turns this from a nicety into a dependency:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'TLS Feature'

Must-Staple, and why it is a one-way door

Must-Staple is an extension baked into the certificate saying that a stapled response is mandatory. A client that receives the certificate without one must refuse the connection. It closes the soft-fail hole properly, and it was the only version of revocation checking that actually did what revocation checking claimed to do.

The price is that the failure mode inverts. Anything that stops your server obtaining and attaching a fresh response becomes a total outage: a responder outage, a network problem between your server and the authority, a configuration change that clears the cache, a reload at the wrong moment. Soft-fail was the escape hatch, and Must-Staple removes it deliberately.

It is the same shape of decision as a preload list or a long-lived header commitment: cheap to enable, and the consequences of it going wrong are not proportional to the effort of enabling it. If a certificate with this extension is still deployed somewhere in your estate on an authority that has ended OCSP, it needs replacing rather than monitoring.

If your authority still runs a responder

Commercial authorities have not all followed the same schedule, so plenty of certificates still carry an OCSP URL. Where they do, three things are worth watching, and none of them is the certificate's expiry date.

A stale stapled response. The cached answer has its own validity window, shorter than the certificate's. A server that fails to refresh it serves an expired response, which strict clients reject and lenient ones ignore, producing a fault that appears in some clients and not others.

An "unauthorized" answer after a chain change. When an intermediate is rotated, a server can end up querying the wrong responder for its new certificate. The response is well formed and negative, and the site starts failing for the strictest clients first, which in practice means payment integrations before browsers.

The cold-start request. On some configurations the first connection after a restart triggers the fetch synchronously, so exactly one visitor pays the full round trip to the authority. Rare, invisible in aggregate timings, and the reason a deploy occasionally produces a single inexplicable slow request.

All three are read from outside, from the handshake, per hostname, which is the same discipline the rest of certificate checking needs: six assertions, and the expiry date is one of them.

What replaces it, operationally

Short lifetimes are now the mechanism. That is a reasonable trade and it moves the risk somewhere specific: renewal. When a certificate lived a year, a renewal that failed silently gave you months of slack. At ninety days, and with the industry pushing shorter still, a renewal process that stops working is an outage within weeks.

Which makes the automation the thing under scrutiny rather than the revocation infrastructure. What actually breaks in it, and why success reported by the renewal client is a weaker signal than it looks, is in the failure modes of renewal in production.