What Is OCSP Stapling and How to Enable It (Nginx, Apache, Cloudflare)
Every time a browser opens a TLS connection it wants to know that the certificate has not been revoked. The old way: the browser calls the certificate authority's OCSP server itself, on every fresh handshake. That is slow, leaks which sites you visit to the CA, and falls apart when the CA has an outage. OCSP stapling solves all three: your server fetches the OCSP response once, caches it, and attaches it to the TLS handshake so the client does not have to call anyone. This guide shows what it does, how to enable it in Nginx and Apache, and how to verify it works.
Key takeaways
- OCSP stapling saves one round-trip per first handshake and removes a third-party dependency at page load.
- It also stops your CA from learning the IP address of every visitor to your site.
- Nginx and Apache need three to five lines of config, plus a trusted chain file. Cloudflare and most managed platforms already do it.
- The fix breaks silently if your server cannot reach the CA's OCSP responder during the first request after restart - preload it.
- Run our SSL certificate checker to confirm stapling is actually working on the live socket.
The problem OCSP stapling solves
When a browser receives your certificate during the TLS handshake, it needs to confirm the cert has not been revoked since issuance. There are two mechanisms in use today: CRLs (Certificate Revocation Lists, downloaded periodically) and OCSP (Online Certificate Status Protocol, queried in real time). OCSP is the more common one in browsers.
Without stapling, every fresh connection triggers a separate HTTP request from the browser to ocsp.<your CA>.com. That has three problems. Latency: an extra DNS lookup plus a TCP/TLS connection plus an HTTP round-trip on the critical path, on a server you do not control. Privacy: the CA sees the visitor's IP address and the certificate serial number, which is enough to reconstruct browsing history per site. Reliability: if the CA's OCSP responder is slow or down, browsers either hang or quietly skip the check ("soft-fail"), which means revocation effectively does not work.
How stapling fixes all three
With stapling, your server pre-fetches a signed OCSP response from the CA on a background timer (typically every few hours; the response is valid for days). On every TLS handshake, the server "staples" that signed response onto its ServerHello. The browser verifies the CA's signature on the stapled response and trusts the result the same way it would trust a live OCSP query - no extra round-trip, no CA contact from the client, no privacy leak.
This is the same trick Cloudflare, AWS CloudFront, Fastly, and every modern CDN do by default. For self-hosted servers you usually have to turn it on yourself.
Enable on Nginx
Add these inside the server block that terminates TLS (Nginx 1.4+; modern Let's Encrypt + certbot installs have it):
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;The resolver line is required: Nginx needs DNS to look up the CA's OCSP responder URL on its own (otherwise stapling silently does nothing on first start). ssl_trusted_certificate must point to the issuer chain (intermediate + root), not the leaf - Nginx uses it to verify the OCSP response signature.
Reload with nginx -t && nginx -s reload. Note: the very first request after a cold restart will not be stapled because Nginx fetches the OCSP response lazily on the first incoming connection. For sites where the cold-start first-byte matters, see the "preload" tip below.
Enable on Apache
Apache 2.4+ ships with stapling support behind the mod_ssl module:
# httpd.conf (server scope, not VirtualHost)
SSLUseStapling on
SSLStaplingCache "shmcb:/var/run/ocsp(128000)"
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors offSSLStaplingCache is mandatory and must be set at the server scope, not inside a VirtualHost - without it Apache refuses to staple at all. SSLStaplingReturnResponderErrors off tells Apache to fall back to a normal (non-stapled) handshake if the OCSP responder is slow, instead of returning an error to the client. Restart with apachectl configtest && apachectl graceful.
Cloudflare, AWS, and other managed platforms
Cloudflare staples by default on every plan - there is no toggle, you don't have to do anything. AWS CloudFront and ALB / NLB also staple automatically. Fastly, Netlify, Vercel, Render, Railway, Fly.io - same story. If you are on any of these, you can skip the config above and just verify with the steps below.
Verify it actually works
The cheap test is from the command line:
echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null \
| grep -i "OCSP response"If you see OCSP Response Status: successful with a recent This Update timestamp, stapling is working. If you see OCSP response: no response sent, the server is not stapling - recheck the config, DNS resolver, and that the trusted chain file is readable by the web server user.
You can also drop the hostname into our SSL certificate checker - it talks to your server the same way a browser would and reports the OCSP status field, along with chain completeness and issuer details.
Must-Staple: opting in to hard-fail
By default browsers treat a missing OCSP response as "skip the check" (soft-fail), which means a misconfigured stapling deployment is invisible to your visitors. The TLS Feature Must-Staple extension flips that: a certificate marked as Must-Staple instructs browsers to reject any handshake without a stapled OCSP response. If you opt in, you have to be sure your stapling pipeline is rock-solid - otherwise visitors see a hard error instead of a degraded handshake.
Most public CAs (including Let's Encrypt) support issuing Must-Staple certs on request. It is great for high-assurance sites (banking, single sign-on endpoints) and overkill for blogs.
A note on the future of OCSP
In 2025 Let's Encrypt and several major CAs announced plans to phase OCSP out in favour of CRLite (a delta-CRL system compiled into the browser). The transition is gradual - OCSP responders will keep working for years, and stapling continues to deliver privacy + latency wins regardless. Even if your CA eventually stops publishing OCSP, the config above causes no harm: Nginx and Apache simply degrade to a non-stapled handshake. Until the dust settles, leave stapling on.
Verify your site
Once you've enabled stapling, run the full check below to confirm everything else is consistent: the cert chain is complete, the right intermediates are served, and there are no other slow-paths in the TLS handshake.