# nginx "ssl_stapling" ignored, no OCSP responder URL: fix > nginx warns "ssl_stapling" ignored when it cannot staple OCSP. Let's Encrypt certificates have had no OCSP URL since 2025, so this is expected. Source: https://ssl.sh/errors/nginx-ssl-stapling-ignored/ Last updated: 2026-11-10 **`"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: ```text nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/letsencrypt/live/example.com/fullchain.pem" ``` | Variant | Meaning | |---|---| | `no OCSP responder URL in the certificate "..."` | The certificate's Authority Information Access has no OCSP address | | `issuer certificate not found for certificate "..."` | nginx cannot find the intermediate that issued the certificate | | `host not found in OCSP responder "..." in the certificate "..."` | The OCSP host could not be resolved when nginx loaded the configuration | | `invalid URL prefix in OCSP responder "..."` | The responder URL is not `http://`; nginx supports only HTTP responders | | `not supported` | nginx was built against an OpenSSL without OCSP support | 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: ```bash 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](https://ssl.sh/news/lets-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](https://ssl.sh/errors/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: ```nginx # 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: ```nginx 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](https://ssl.sh/tools/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 | 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](https://ssl.sh/learn/ocsp-and-crl/) for how revocation works without OCSP.