OCSP stapling errors after Let's Encrypt: what each means

Most OCSP stapling errors you see today are harmless warnings: Let's Encrypt certificates no longer contain an OCSP URL, so a server configured to staple has nothing to fetch and says so in its log. The site keeps working. Only one case in this post stops visitors from connecting, and it is not the one that fills your logs.

Let's Encrypt removed OCSP URLs from new certificates on 7 May 2025 and turned off its OCSP responders on 6 August 2025. Its certificates last at most 90 days, so every Let's Encrypt certificate that still had an OCSP URL has expired. The background is in OCSP stapling in 2026; this post is about the messages.

We reproduced each one with a small lab: a test CA, certificates with and without an OCSP URL, and stock nginx 1.29.8 and Apache 2.4.69 containers. The nginx, Apache and openssl output below is copied from that lab; the certbot and Firefox messages come from each project's own source code.

Every message, side by side

nginx: three different "ssl_stapling ignored" warnings

All three start the same way, so it is easy to read them as one problem. They are not. This is the output of nginx -t in the lab:

[warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/lab/noocsp.chain.pem"
[warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/lab/withocsp.pem"
[warn] "ssl_stapling" ignored, host not found in OCSP responder "r11.o.lencr.org" in the certificate "/lab/oldle.chain.pem"
nginx: configuration file /lab/nginx.conf test is successful

The config test passes and nginx serves traffic in every case. What each line tells you:

• [object Object]: the expected message for a Let's Encrypt certificate today. Nothing to fix except the log noise.
• [object Object]: the certificate names a responder hostname that does not resolve. When we checked, r3.o.lencr.org, r10.o.lencr.org, r11.o.lencr.org and e5.o.lencr.org all returned NXDOMAIN from both 1.1.1.1 and 8.8.8.8. You would only see this with a certificate issued before May 2025, which means an expired certificate is still configured somewhere.
• [object Object]: a different problem. The certificate has an OCSP URL (so it is not a current Let's Encrypt one), and nginx cannot find its issuer because the file holds only the leaf. Serve the full chain, for example fullchain.pem instead of cert.pem. Browsers often hide a missing chain; many API clients and Linux tools do not, which is why an SSL check should validate the chain itself.

To silence the first two, remove the stapling lines from the server block, or from /etc/letsencrypt/options-ssl-nginx.conf if certbot manages the config:

# ssl_stapling on;
# ssl_stapling_verify on;

Apache: logged as errors, still harmless

Apache 2.4.69 with SSLUseStapling On and a certificate without an OCSP URL logged this at startup:

[ssl:error] AH02218: ssl_stapling_init_cert: no OCSP URI in certificate and no SSLStaplingForceURL set [subject: CN=localhost / ...]
[ssl:error] AH02604: Unable to configure certificate localhost:9443:0 for stapling
[mpm_event:notice] AH00489: Apache/2.4.69 (Unix) OpenSSL/3.5.9 configured -- resuming normal operations

Both lines are at error level, which is why they set off log alerts, but the last line shows the server started normally. The fix is SSLUseStapling Off for those certificates. Do not reach for SSLStaplingForceURL to point at a Let's Encrypt responder: there is no responder left to answer.

openssl: "no responses sent"

If you test stapling with openssl s_client -status, the server-side changes above show up as:

echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null | grep -i ocsp
# OCSP responses: no responses sent

This is OpenSSL 3.6.3's wording. For a Let's Encrypt certificate it is the correct result now, not a failure. A script that treats it as an error will alert forever.

certbot: the message is harmless, the side effect is not

certbot logs Cannot extract OCSP URI from <path> at info level, so it lands in /var/log/letsencrypt/ rather than on screen. Renewals are unaffected.

The part that matters is what certbot does next. In certbot's own revocation check, a certificate without an OCSP URL is treated as not revoked: the function documents that it returns False "if valid or the check failed or cert is expired". certbot certificates uses that check to mark a certificate REVOKED. So for a current Let's Encrypt certificate, certbot certificates will not show REVOKED even if the certificate has been revoked. Revocation is still published, through CRLs, and browsers learn about it through their own lists; certbot's listing no longer sees it. If you need to know whether a certificate was revoked, check the CRL listed in the certificate, not certbot's output.

Firefox: the one that breaks the site

OCSP Must-Staple is a flag in the certificate that says "refuse me unless the server staples a fresh OCSP response". Firefox enforces it by default. When the staple is missing, Firefox's own error list gives the error as:

MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING=A required TLS feature is missing.

Let's Encrypt stopped issuing Must-Staple certificates on 7 May 2025, so you will not see this with a fresh Let's Encrypt certificate. You can still see it with a Must-Staple certificate from another CA whose server has stapling turned off or failing, or with an ACME client that still asks for the extension against a CA that allows it. Before you disable stapling on a server, check that none of its certificates carry the flag:

openssl x509 -in cert.pem -noout -text | grep -E -A1 "TLS Feature|1.3.6.1.5.5.7.1.24"
# OpenSSL 3 prints "TLS Feature: status_request"; macOS LibreSSL prints the OID
# no output = no Must-Staple, stapling can go

What to watch instead

None of these messages tells you whether a certificate is about to expire, chains correctly or serves the right name, which are the failures that take a site down. WebPixie's SSL monitoring checks those daily and lists the OCSP and CRL endpoints it finds on each certificate. It flags a certificate with no published OCSP endpoint as worth attention; for a Let's Encrypt certificate that flag is expected, and what to check is that a CRL endpoint is listed in its place.