nginx OCSP stapling is mostly obsolete

The fix

# If your certificate is from Let's Encrypt: delete these lines.
# They have had no effect since August 2025.
#
# ssl_stapling on;
# ssl_stapling_verify on;

If your CA still operates an OCSP responder, stapling is still worth enabling — the config for that is at the bottom of this page.

What changed

OCSP stapling was standard advice for a decade: the server fetches a signed “this certificate is still valid” response from the CA and staples it to the handshake, so the browser doesn’t have to ask the CA itself — which is slow and leaks the user’s browsing to the CA.

That privacy problem is what ended it. Let’s Encrypt turned off its OCSP service on 6 August 2025, having announced it in December 2024, and it now publishes revocation information exclusively via Certificate Revocation Lists. It also stopped including OCSP URLs in certificates more than 90 days before the shutdown, so by now every Let’s Encrypt certificate carrying one has expired.

The consequence for your config is direct: ssl_stapling on tells nginx to fetch an OCSP response using the URL in the certificate. There is no URL. There is nothing to fetch, nothing to staple, and nothing happens.

It fails quietly, which is the annoying part

nginx does not treat this as an error. The handshake works, the site is fine, and the only trace is a warning in the error log:

[warn] no OCSP responder URL in the certificate

So a config that has been “hardened with OCSP stapling” since 2019 has been doing nothing for the past year, and the only way to know is to look for a warning nobody greps for. This is why the page exists at low severity: it closes no exposure. It stops you believing in something that isn’t happening, and it removes a line that will confuse the next person who reads the config.

Revocation still works. Browsers use CRL-based mechanisms — Firefox’s CRLite and Chrome’s CRLSets — which ship revocation data to the browser out of band. That was already how revocation mostly worked in practice, because browsers had largely stopped doing live OCSP lookups years ago. Nothing regressed; a mechanism that had already been quietly bypassed got switched off.

If your CA still does OCSP

Not every CA has followed. If yours still publishes a responder URL, stapling is still a small performance and privacy win:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
resolver 127.0.0.53 valid=300s;
resolver_timeout 5s;

ssl_stapling_verify on requires ssl_trusted_certificate pointing at the issuer chain, and stapling needs a working resolver because nginx must resolve the OCSP hostname itself. Both are omitted often enough that plenty of configs claiming to staple never did — even before Let’s Encrypt made the point moot.

Verify it worked

First, find out whether your certificate even has an OCSP URL:

openssl s_client -connect your.site:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -ocsp_uri

Empty output means there is no responder URL and stapling cannot do anything. For a Let’s Encrypt certificate, that is now the expected result.

Check whether a response is actually being stapled:

openssl s_client -connect your.site:443 -status </dev/null 2>&1 | grep -A2 'OCSP response'

OCSP response: no response sent confirms nothing is stapled — which is correct and harmless if the URL is absent.

Look for the warning that has been in your log all along:

sudo grep -c 'no OCSP responder URL' /var/log/nginx/error.log

And confirm the directives are still lurking:

sudo nginx -T 2>/dev/null | grep -E 'ssl_stapling|ssl_trusted_certificate'

Before you apply this

Removing ssl_stapling from a Let’s Encrypt config is about as safe as a change gets — you are deleting something with no effect. Nothing in the handshake changes, because nothing was being stapled.

Check your CA before you delete, not after. If you use a CA that still runs a responder, removing these lines gives up a real (if modest) benefit: without stapling, a browser that does check revocation has to contact the CA directly, which is slower and tells the CA which site the user is visiting. The -ocsp_uri check above answers this in one command.

One thing not to do in response to this change: do not conclude revocation doesn’t matter. It still does — it just isn’t your web server’s job any more. Keep certificates short-lived and automate renewal, which is the control that actually limits the damage of a key compromise.

Related

• Configure TLS — the settings that do still matter.
• Enable HSTS — where certificate expiry becomes an outage.