What's happening
During the TLS handshake, your server tries to send a pre-fetched OCSP response to clients — that's what stapling is. The problem: the cached response has expired, or the OCSP responder returned an error when your server tried to fetch a fresh one. Clients either reject the connection outright or fall back to fetching the OCSP status themselves, adding latency.
The two log lines that bring you here:
ssl_stapling: OCSP response not successful (6: unauthorized)
OCSP response has expired
Error code 6: unauthorized means the OCSP responder rejected the request. This usually happens for one of three reasons: the request was malformed, your server queried the wrong CA endpoint, or the certificate's AIA (Authority Information Access) extension points to a responder your server can't reach.
Quick diagnosis
Run this from any machine with OpenSSL to see what clients actually receive:
# Test OCSP stapling from the client side
openssl s_client -connect yourdomain.com:443 -status 2>/dev/null | grep -A 10 'OCSP response'
A working staple looks like this:
OCSP Response Status: successful (0x0)
Cert Status: good
Broken stapling shows no response sent or unauthorized. Check your logs next:
# Nginx
tail -n 100 /var/log/nginx/error.log | grep -i ocsp
# Apache
tail -n 100 /var/log/apache2/error.log | grep -i ocsp
Fix 1: Flush the stale OCSP cache
Nginx caches OCSP responses in memory, not on disk. Once a cached response expires and the server fails to refresh it, every new TLS handshake hits this error. A reload clears that in-memory cache and forces a fresh fetch on the next request:
sudo nginx -t && sudo systemctl reload nginx
For Apache:
sudo apachectl configtest && sudo systemctl reload apache2
If the error disappears after reload but returns within 24–48 hours, the cache isn't the root cause — your server can't reach the OCSP responder to refresh it proactively. Move on to Fix 2.
Fix 2: Check OCSP responder connectivity
Pull the OCSP URL directly from your certificate:
openssl x509 -in /path/to/your/cert.pem -noout -text | grep -A 3 'Authority Information'
Example output for a Let's Encrypt cert:
Authority Information Access:
OCSP - URI:http://r10.o.lencr.org
CA Issuers - URI:http://r10.i.lencr.org/
Now test reachability from your server:
curl -v http://r10.o.lencr.org
A timeout means the OCSP responder is blocked at the network level. OCSP runs over plain HTTP on port 80 — many firewall rules forget to allow outbound HTTP from the web server itself. Open it:
# iptables
sudo iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
# ufw
sudo ufw allow out 80/tcp
Behind a corporate proxy? Set http_proxy in the environment before starting Nginx or Apache, or use a resolver that can reach the CA (see Fix 4).
Fix 3: Verify the certificate chain is complete
Nine times out of ten, ssl_stapling: OCSP response not successful (6: unauthorized) comes down to a missing intermediate certificate. OCSP stapling requires the full chain — the server needs it to verify the stapled response before passing it to clients.
For Nginx
Point ssl_certificate at the fullchain file, not just your domain cert. Then add ssl_trusted_certificate — without it, Nginx can't validate the OCSP response it gets back from the CA:
server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # includes intermediate
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/yourdomain.com/chain.pem; # required for stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
}
For Apache
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/yourdomain.com/chain.pem
SSLUseStapling on
</VirtualHost>
# Outside VirtualHost block, in main config or ssl.conf:
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
Reload after any config change:
sudo nginx -t && sudo systemctl reload nginx
# or
sudo apachectl configtest && sudo systemctl reload apache2
Fix 4: Add a DNS resolver for Nginx
Nginx can't staple OCSP responses if it can't resolve the responder's hostname. No resolver directive means silent failure — no error, no staple. Add it to the http block (not just server):
http {
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 10s;
# ... rest of config
}
Reload Nginx after adding it. A resolver_timeout of 10s is conservative — on a fast network, 5s is usually enough.
Fix 5: Pre-fetch the OCSP response with a cron job
The responder is reachable, but renewal timing leaves a gap? Pre-fetch the response on a schedule so Nginx always has a fresh staple waiting:
#!/bin/bash
# /usr/local/bin/refresh-ocsp.sh
CERT=/etc/letsencrypt/live/yourdomain.com/cert.pem
CHAIN=/etc/letsencrypt/live/yourdomain.com/chain.pem
OCSP_URL=$(openssl x509 -in $CERT -noout -ocsp_uri)
openssl ocsp \
-issuer $CHAIN \
-cert $CERT \
-url $OCSP_URL \
-respout /tmp/ocsp.der \
-no_nonce 2>&1
echo "OCSP refresh done at $(date)"
Schedule it every 12 hours — Let's Encrypt OCSP responses are valid for 7 days, but refreshing frequently keeps you well inside the window:
0 */12 * * * /usr/local/bin/refresh-ocsp.sh >> /var/log/ocsp-refresh.log 2>&1
Verify the fix
After reloading, re-run the OpenSSL check:
openssl s_client -connect yourdomain.com:443 -status 2>/dev/null | grep -A 10 'OCSP Response'
You want to see this:
OCSP Response Status: successful (0x0)
This Update: Mar 23 10:00:00 2026 GMT
Next Update: Mar 30 10:00:00 2026 GMT
Cert Status: good
SSL Labs also reports OCSP stapling status — submit your domain and look for OCSP Stapling: Yes in the results.
Still seeing errors in Nginx logs right after a reload? Wait 60–90 seconds. Nginx fetches the OCSP response asynchronously on the first post-reload request, so the initial handful of connections may arrive before the staple is ready.