I spent a while ignoring OCSP stapling because it felt like an advanced optimization that wasn’t worth the effort. Then I actually measured the TLS handshake times on a server without it and realized visitors were waiting for an extra round-trip to a CA’s OCSP server on every new connection. That changes the calculus.
What OCSP Stapling Actually Solves
When a browser connects to your HTTPS site, it might want to verify that your certificate hasn’t been revoked. The traditional way to do this is OCSP (Online Certificate Status Protocol): the browser contacts the CA’s OCSP responder, asks “is certificate X still valid?”, and waits for a response.
The problems with this:
- Latency: The browser has to make a separate HTTP request to the CA’s server before or during the TLS handshake. This adds time.
- Privacy: The CA now knows which websites that IP address is visiting.
- Availability: If the CA’s OCSP server is slow or down, the browser may have to decide whether to proceed anyway or fail the connection.
OCSP stapling shifts the responsibility. Instead of the browser fetching the OCSP response, your web server fetches it proactively (every few hours), caches it, and “staples” it to the TLS handshake response. The browser gets the OCSP status directly from your server — no extra round-trip, no privacy leak to the CA, no CA availability dependency.
Enabling OCSP Stapling in Nginx
The core configuration is short:
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;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# ... rest of your config
}A few things here that matter:
ssl_stapling on — enables OCSP stapling. Nginx will contact the OCSP responder in the background and cache the response.
ssl_stapling_verify on — tells Nginx to verify the OCSP response’s signature against the trusted certificate chain. You should always enable this.
ssl_trusted_certificate — points to the CA certificate chain (not your certificate, but the intermediates and root). For Let’s Encrypt, this is chain.pem (the intermediate). Nginx needs this to verify the OCSP response.
resolver — Nginx needs a DNS resolver to look up the OCSP responder’s IP address. Without this, OCSP stapling will silently fail. I typically use 8.8.8.8 and 8.8.4.4 (Google’s DNS) or your server’s local resolver if it exists and is reliable.
Let’s Encrypt vs Commercial CAs
For Let’s Encrypt certificates, the fullchain.pem file contains both your certificate and the intermediate. The chain.pem file contains just the intermediate. Use chain.pem for ssl_trusted_certificate.
For commercial CAs, you’ll typically have separate files. The certificate file for your domain, and a separate “chain” or “ca-bundle” file for the intermediates. Use the chain/ca-bundle file for ssl_trusted_certificate. For more on how certificate chains are structured, see Understanding SSL Certificate Chains.
Don’t point ssl_trusted_certificate at your full chain file (the one that includes your domain’s certificate). Nginx only wants the CA certs here, not the end-entity cert.
Verifying OCSP Stapling Is Working
After reloading Nginx, you can test with OpenSSL:
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A 17 "OCSP response"If stapling is working, you’ll see something like:
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: ...
Produced At: Jul 8 10:00:00 2024 GMT
Responses:
Certificate ID:
...
Cert Status: good
This Update: Jul 8 10:00:00 2024 GMT
Next Update: Jul 15 10:00:00 2024 GMTIf you see OCSP response: no response sent or the OCSP block is absent, stapling isn’t working.
Common Reasons OCSP Stapling Fails
Missing or misconfigured resolver. This is the most common issue I’ve seen. Without a resolver directive, Nginx can’t resolve the OCSP responder’s hostname. The error won’t show up clearly in logs — stapling will just silently not work. Add a resolver and reload.
Wrong ssl_trusted_certificate — if you point it at the wrong file (like a self-signed cert or the wrong CA), Nginx can’t verify the OCSP response and will fall back to no stapling.
Nginx worker processes can’t reach the OCSP server. If your server has a firewall that blocks outbound HTTP, Nginx can’t fetch the OCSP response. Test with curl from the server: curl -v http://ocsp.pki.goog/ or whatever your CA’s OCSP URL is. You can find the OCSP URL in your certificate: openssl x509 -in cert.pem -noout -text | grep OCSP.
First request after a reload. OCSP stapling isn’t instantaneous. After a Nginx reload, it may take a few seconds or the first connection before Nginx fetches and caches the OCSP response. Test again after a moment.
OCSP Stapling in Nginx Error Logs
Enable more verbose logging while debugging:
error_log /var/log/nginx/error.log info;Or with debug level (very verbose, don’t use in production):
error_log /var/log/nginx/error.log debug;OCSP-related entries typically look like:
[info] 1234#0: *1 ssl stapling: staple "example.com" OCSP request sent
[info] 1234#0: *1 ssl stapling: staple "example.com" OCSP response validIf the response fails validation, you’ll see a warning instead.
Is OCSP Stapling Required?
No. Many sites run without it and function perfectly. Browsers handle the fallback gracefully — if there’s no stapled response and the browser doesn’t fetch a fresh OCSP response, it typically proceeds with the connection (soft-fail).
But I enable it on every production server now because:
- It reduces TLS handshake latency, especially for users far from the CA’s OCSP servers
- It’s a concrete improvement to user privacy
- It eliminates a potential point of failure (CA OCSP server downtime)
The configuration cost is about 4 lines of Nginx config once you understand what each does.
A Note on OCSP Must-Staple
There’s a certificate extension called “OCSP Must-Staple” (RFC 7633) that tells browsers to require a valid OCSP stapled response and reject the connection if it’s missing. It’s a stronger security posture — but it means if your Nginx OCSP stapling ever fails (misconfiguration, CA OCSP outage), your site becomes unreachable.
I don’t use OCSP Must-Staple in production for that reason. The operational risk isn’t worth it for most sites. But if you’re running a high-security application and can tolerate that operational constraint, it’s worth looking into.
OCSP stapling is one of those TLS improvements that’s invisible when it’s working — which is exactly how it should be. Set it up, verify it, and it runs silently in the background making your site slightly faster and more private for every visitor. After you’ve got it configured, you can verify it alongside your other certificate details using the SSL Checker.