My SSL scanner says OCSP stapling is not enabled. Is that a problem I need to fix?

Usually not, and in 2026 it's often not fixable even if you wanted to. OCSP stapling only works if your certificate carries an OCSP responder URL, and the biggest CA on the web — Let's Encrypt — stopped including one. It removed OCSP URLs from newly issued certificates on May 7, 2025 and shut down its OCSP responders entirely on August 6, 2025, moving to CRLs. A Let's Encrypt certificate issued after that date has nothing to staple, so 'OCSP stapling not enabled' is a correct description of reality, not a misconfiguration. Browsers already soft-fail OCSP and don't depend on it, so a missing staple does not make your site insecure. First check which CA issued your cert and whether it even has an OCSP URL; only then is enabling stapling a real task.

I turned on ssl_stapling in nginx but the check still shows it's off. Why?

Three common reasons. First, your certificate may have no OCSP URL (see above) — nginx will log a warning that there is no OCSP responder URL in the certificate and simply serve nothing to staple. Second, nginx fetches the OCSP response lazily: the first handshakes right after a reload won't include a staple until nginx has fetched one in the background, so a test run a second after reload shows 'not enabled' even when the config is correct — wait a minute and test again. Third, nginx needs ssl_trusted_certificate pointing at the full chain (including the issuing intermediate) and a working resolver line so it can reach the responder; without both, verification fails silently and nothing gets stapled.

Should I enable OCSP Must-Staple to force it?

Almost certainly not, especially now. Must-Staple (RFC 7633) is a certificate flag that tells browsers to hard-fail the connection if no stapled OCSP response is present. It closes the soft-fail hole, but it turns your CA's responder into a hard dependency: if the staple is missing for any reason — a responder outage, an expired cached response, a broken fetch — your site goes down, not degraded, down. With major CAs actively retiring OCSP, pinning yourself to a response that may stop existing is a reliable way to take your own site offline. Leave Must-Staple off unless you have a specific, well-understood reason and automation you trust completely.

OCSP Stapling Not Enabled? Check If You Still Need It

Problem

A scanner, an audit checklist, or an SSL grading tool reports OCSP stapling: not enabled for your site, and you’re trying to decide whether that’s a real finding or noise — and if it’s real, how to turn it on and confirm it’s actually working.

Symptoms

An SSL/TLS report shows OCSP stapling as off, missing, or “not stapled.”
openssl s_client -connect yourdomain:443 -status returns OCSP response: no response sent.
You added ssl_stapling on; to nginx but the status is still reported as off.
A compliance check flags the missing staple even though the site works fine.

First, check whether there’s anything to staple

OCSP stapling is a TLS extension (the Certificate Status Request, RFC 6066) that lets your server fetch its own revocation proof from the CA and attach — “staple” — it to the handshake. Done right, the visitor gets freshness proof without a side trip to the CA, and the CA never sees the visitor’s IP. Good idea. But it only works if your certificate tells the server where the CA’s OCSP responder is, in the Authority Information Access field. No OCSP URL in the cert, nothing to staple.

And that’s where 2026 changes the answer. The industry is retiring OCSP. In August 2023 the CA/Browser Forum made OCSP support optional for certificate authorities and made CRLs mandatory instead. Then the largest CA on the web acted on it: Let’s Encrypt removed OCSP URLs from newly issued certificates on May 7, 2025, and shut down its OCSP responders entirely on August 6, 2025, relying on CRLs from then on. If your certificate comes from Let’s Encrypt and was issued after spring 2025, it has no OCSP responder URL — so “OCSP stapling not enabled” is simply true, and no amount of nginx configuration will change it. There is nothing to fetch.

So the first diagnostic step is not to edit a config file. It’s to look at who issued your certificate. If it’s Let’s Encrypt (or any CA that has dropped OCSP), stapling is gone by design, browsers already don’t rely on it, and you can close the finding as not applicable. If it’s a commercial CA that still runs an OCSP responder, then stapling is a real, if minor, improvement worth turning on correctly.

Top 3 Causes

The certificate has no OCSP URL. Most commonly a Let’s Encrypt cert issued after the May 2025 cutover. There is no responder to query, so stapling can’t happen. This is the expected state, not a fault.
Stapling isn’t configured, or is configured incompletely. The CA still runs OCSP, but the server either doesn’t have stapling turned on, or has it on without the full chain (ssl_trusted_certificate) and a working DNS resolver line, so verification fails and nothing is served.
The test ran too soon after a reload. nginx fetches the OCSP response lazily in the background. For the first handshakes after a restart or reload, there’s no cached response yet, so a quick test reports “not enabled” even though the config is right. It fills in within a minute or two of live traffic.

Diagnose with DechoNet

SSL Check shows the issuing CA and certificate chain, so you can see immediately whether your cert came from Let’s Encrypt (stapling retired) or a CA that still runs OCSP — which decides whether this is a config task at all.
HTTP Check confirms the site is serving over HTTPS on the host you think it is, so you’re testing the certificate that’s actually live rather than an old one behind a cache or a different vhost.

Resolution Checklist

Run SSL Check and read the issuer first. If it’s Let’s Encrypt (or another CA that has dropped OCSP), stop here — there is nothing to staple, and the finding is not applicable.
If the CA still runs OCSP and you want stapling, in nginx set ssl_stapling on; and ssl_stapling_verify on;, point ssl_trusted_certificate at the full chain file (your cert plus the intermediate), and add a resolver line (for example resolver 1.1.1.1 8.8.8.8 valid=300s;) so nginx can reach the responder. Reload.
In Apache, set SSLUseStapling on and define an SSLStaplingCache (for example SSLStaplingCache "shmcb:logs/ssl_stapling(32768)") at the server level. Reload.
Wait a minute for the server to fetch and cache its first OCSP response, then verify with openssl s_client -connect yourdomain:443 -status and look for OCSP Response Status: successful and Cert Status: good.
Leave Must-Staple off. Turning an optional check into a hard dependency on a responder the CA may retire is a self-inflicted outage waiting to happen.

When to Escalate (or Let It Go)

If your certificate is from a CA with no OCSP responder, this is finished: the finding is obsolete, and the right fix is to update the scanner’s expectations, not the server. Revocation for those certs is handled through CRLs that browsers fetch on their own.
If stapling is configured correctly against a live responder but openssl ... -status still returns nothing after a few minutes of traffic, check that the ssl_trusted_certificate chain is complete and the server can actually resolve and reach the responder’s hostname from its own network — an egress firewall blocking outbound HTTP to the CA is a common, silent cause.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.