nginx "ssl_stapling" ignored, no OCSP responder URL: fix

"ssl_stapling" ignored means nginx turned OCSP stapling off for one certificate because it could not set it up, and carried on without it. Since Let's Encrypt shut down OCSP in August 2025, the usual form is "ssl_stapling" ignored, no OCSP responder URL in the certificate, which is harmless. Remove the stapling directives where they cannot work.

The exact messages

nginx prints the reason after the comma. From nginx -t or the error log:

nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/letsencrypt/live/example.com/fullchain.pem"

All are logged at warn level.

What OCSP stapling did, and why it is fading

Stapling is fading because it needs an OCSP responder, and Let's Encrypt no longer runs one. With OCSP, a browser could ask the CA whether a certificate had been revoked. Stapling, defined as the TLS Certificate Status Request extension in RFC 6066, let the server fetch that signed answer itself and attach it to the handshake, saving the client a lookup and keeping the CA from learning which sites users visit. Stapling only works when the certificate names an OCSP responder. Let's Encrypt cited privacy as its main reason for ending OCSP and now publishes revocation only in CRLs, whose URLs appear in the certificate's CRL Distribution Points. So for Let's Encrypt certificates there is nothing to staple, and the warning reports that fact.

Is anything broken?

Usually not. Check three things: the site loads over HTTPS, nginx -t reports syntax is ok and test is successful, and the warning names only certificates from Let's Encrypt or another CA that has dropped OCSP. If all three hold, the warning is cosmetic. It deserves attention when it names a certificate that does have an OCSP URL, because then stapling silently stopped working for a reason such as a missing intermediate or a DNS failure.

Common causes, most frequent first

1. The certificate has no OCSP URL (Let's Encrypt since 2025)

Let's Encrypt announced the end of OCSP on 2024-12-05, removed OCSP URLs from new certificates on 2025-05-07 and turned off its OCSP responders on 2025-08-06. A configuration written years ago with ssl_stapling on;, or generated by Certbot's --staple-ocsp option, now produces this warning at every reload. Confirm:

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -ocsp_uri
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -ext crlDistributionPoints

An empty first line and a CRL URL in the second confirm a CRL-only certificate. More background in Let's Encrypt ends OCSP.

2. The intermediate certificate is missing

nginx needs the issuer to build the OCSP request. The nginx documentation says the issuer must be in the ssl_certificate file or, failing that, in ssl_trusted_certificate. Using cert.pem instead of fullchain.pem causes issuer certificate not found, and also breaks some clients; see missing intermediate certificate.

3. DNS not available when nginx starts

With an OCSP URL present, nginx resolves the responder host while loading the configuration. If DNS is not ready at boot, you see host not found in OCSP responder. The nginx documentation also asks for a resolver directive so the responder can be resolved at run time.

4. A non-HTTP responder or an OpenSSL without OCSP

Rare: invalid URL prefix for responders that are not http://, and not supported for custom OpenSSL builds.

How to fix it

For certificates without an OCSP URL, delete the stapling directives from the affected server blocks and from shared snippets:

# remove these lines
ssl_stapling on;
ssl_stapling_verify on;

Also remove resolver if it was added only for stapling, and drop --staple-ocsp from any scripts that run Certbot so the directives are not added again.

For certificates that still have an OCSP URL, keep stapling and make it work:

ssl_certificate         /etc/ssl/example.com/fullchain.pem;
ssl_certificate_key     /etc/ssl/example.com/privkey.pem;
ssl_trusted_certificate /etc/ssl/example.com/chain.pem;
ssl_stapling            on;
ssl_stapling_verify     on;
resolver                1.1.1.1 8.8.8.8 valid=300s;

The TLS config generator produces a current block without obsolete stapling lines.

How to verify the fix

1. sudo nginx -t prints no [warn] "ssl_stapling" ignored lines, then sudo systemctl reload nginx.
2. For a certificate that should be stapled, check the handshake:

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

OCSP Response Status: successful means stapling works; for Let's Encrypt certificates no response sent is the expected result. 3. See OCSP and CRL for how revocation works without OCSP.