Let’s Encrypt Ends OCSP: Fixing OCSP Stapling on NGINX

Let’s Encrypt announced on July 23, 2024 that it intends to end OCSP support in favour of certificate revocation lists. So OCSP stapling on NGINX with these certificates will, sooner or later, have nothing to staple. Will your site stop serving TLS? No. But the stapling directives in your config are slowly turning into dead weight. Here’s what was announced, what it does to an ssl_stapling setup, and what to check on your own box now.

What did Let’s Encrypt announce about OCSP?

Short version: the CA wants out of Online Certificate Status Protocol and into certificate revocation lists, as soon as possible. According to the Let’s Encrypt announcement on replacing OCSP, it has run an OCSP responder since its launch nearly ten years ago and added CRL support in 2022. Then in August of 2023 the CA/Browser Forum passed a ballot making OCSP services optional for publicly trusted CAs. One exception remains: the Microsoft Root Program.

Calendar dates? None yet. A specific schedule will follow once Microsoft also makes OCSP optional, and the CA is optimistic that happens within the next six to twelve months. It then hopes to serve its last response between three and six months after that shutdown timeline is published. Updates will land in the API Announcements category on the project’s Discourse forum. Subscribe there - it’s the one reliable way to hear about it.

CRL vs OCSP: why the CA is switching

OCSP is a per-certificate status query sent to the CA’s responder. A CRL is a published list of every certificate the CA has revoked. And the main reason for the switch is privacy. An OCSP lookup tells the CA which website is being visited from which IP address, and even a CA that deliberately keeps no such records could be legally compelled to collect them. Revocation lists don’t have that problem, because a client downloads the whole list instead of asking about one site.

The second reason is plain ops. The same announcement explains that keeping CA infrastructure as simple as possible matters for compliance, reliability and efficiency, that running OCSP has consumed considerable resources every year, and that the service has become unnecessary now that CRLs are supported. Fair enough.

How OCSP stapling works on NGINX today

With stapling, the web server fetches the OCSP response itself and attaches it to the TLS handshake. The visitor’s client never has to talk to the CA. In NGINX three directives run the show: ssl_stapling, ssl_stapling_verify and ssl_trusted_certificate, all described in the nginx ssl module documentation. That page sets one requirement (and it’s the one people trip over): the issuer’s certificate has to be known. So if the ssl_certificate file lacks intermediate certificates, the issuer certificate must be present in the ssl_trusted_certificate file.

A typical Let’s Encrypt server block with stapling turned on looks like this:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate         /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_stapling            on;
    ssl_stapling_verify     on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
}

What changes for an ssl_stapling nginx config

Stapling depends entirely on the CA’s responder. Once responses stop being served, there is nothing for NGINX to fetch and attach. The announcement notes that most OCSP implementations fail open, meaning an inability to fetch a response will not break the system. Your site keeps serving TLS. The handshake just goes out without a stapled status.

In practice the directives turn into dead configuration that may only produce log noise. A tidy cleanup job, not an emergency. One thing I’d check first, though: where is TLS actually terminated in your stack? With HTTPS behind a reverse proxy the stapling settings may live on a different machine than the one you first think of.

Non-browser use is a different story and deserves more care. If you secure something like a VPN with these certificates, the CA advises making sure your software operates correctly when a certificate contains no OCSP URL.

Checklist: preparing your server for the end of OCSP

Basically, you find every place that relies on OCSP and plan how to get rid of it. Work through these steps on your own host:

1. Find the directives. Search every server block for ssl_stapling and ssl_stapling_verify, shared snippets and includes too: grep -rn "ssl_stapling" /etc/nginx/.
2. Inspect the certificate. Does it still carry an OCSP URL? Check with openssl x509 -in fullchain.pem -noout -ocsp_uri.
3. Test the handshake. Run openssl s_client -connect example.com:443 -servername example.com -status and look for the OCSP response section to see whether a stapled reply comes back.
4. Review monitoring and deploy scripts. Any check that treats a missing stapled response as a failure will start raising false alarms.
5. Identify hard dependencies. Anything that requires an OCSP response to function needs a plan to end that reliance, in line with the CA’s recommendation to start as soon as possible.
6. Plan the removal. Once the shutdown schedule is published, delete the stapling directives, run nginx -t and reload.
7. Subscribe to API Announcements. That’s where the specific timeline will be posted.

Which TLS certificate checks still matter after the change

Revocation checking moves to the client and browser side through CRLs. Nothing to configure for it on the web server. What stays in your hands is the rest of the certificate lifecycle:

• the full chain served from the ssl_certificate file,
• renewal automation that runs and reloads NGINX afterwards,
• expiry monitoring that warns you before a certificate lapses,
• a handshake test after each config change.

All of this is visible from outside. Anyone can inspect what TLS setups reveal about a server, so a consistent configuration is worth the effort. And a clean setup serves crawlers as well as visitors, which matters with Googlebot crawling over HTTP/2 on connections negotiated through the same handshake.

Until the responder is switched off, OCSP stapling keeps working exactly as it does today. So what’s the sensible move in July 2024? Audit your config, note every dependency on a stapled response, and remove them calmly when the schedule arrives. No rush.

FAQ