How to enable OCSP stapling on Apache, Nginx, and IIS

The ocsp_not_stapled advisory fires when your server completes a TLS handshake without including a stapled OCSP response. Stapling is a server-side optimization that lets the server fetch and cache the CA's "this cert is still valid" response and hand it to clients during the handshake, instead of forcing every client to round-trip to the CA on their own.

What triggers the advisory

CertTracker inspects the TLS handshake for an OCSP response embedded via the status_request extension. If the cert specifies an OCSP responder in its AIA (Authority Information Access) extension but the handshake doesn't include a stapled response, the advisory fires.

Why it matters

Without stapling, every client connecting to your endpoint may make a separate OCSP request to your CA's responder. This produces three problems:

1. Privacy leak — your CA sees a request from every visitor, telling them which sites the visitor is reading.
2. Latency — each connection waits on a third-party round-trip. On slow connections or distant CAs, this can add hundreds of milliseconds to the first page load.
3. Availability dependency — your site's availability depends on your CA's OCSP responder being up. CA outages have taken down websites.

Stapling eliminates all three by having the server pre-fetch and cache the OCSP response on a schedule and serve it directly in the handshake.

Fix on Apache (2.4+)

Edit your ssl.conf or vhost:

SSLUseStapling          on
SSLStaplingCache        shmcb:/var/run/ocsp(128000)
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

The cache directive must be at the server scope (outside any vhost block) on Apache 2.4 — Apache will refuse to start otherwise. Put it in httpd.conf or ssl.conf, not inside a <VirtualHost>.

Reload:

sudo apachectl configtest && sudo systemctl reload apache2   # Debian/Ubuntu
sudo apachectl configtest && sudo systemctl reload httpd     # RHEL/CentOS

Fix on Nginx (1.3.7+)

ssl_stapling             on;
ssl_stapling_verify      on;
ssl_trusted_certificate  /etc/nginx/ssl/ca-chain.pem;
resolver                 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout         5s;

The ssl_trusted_certificate is a chain file containing the intermediate(s) and root, so Nginx can verify the OCSP response signature. Many people use the same file as ssl_certificate (if it's a fullchain.pem); pointing at the chain explicitly is more robust.

resolver is required — Nginx needs to do its own DNS lookups to reach the OCSP responder, and it doesn't use the system resolver. Pick any DNS resolver your server can reach.

Reload:

sudo nginx -t && sudo systemctl reload nginx

Fix on IIS

IIS enables OCSP stapling by default since IIS 7. If you're seeing this advisory on a Windows host, stapling is likely disabled at a lower level. Two things to check:

1. Verify SCHANNEL has stapling enabled. In an admin PowerShell:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" -Name "EnableOcspStaplingForSni" -ErrorAction SilentlyContinue

If the value is 0, set it to 1:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" -Name "EnableOcspStaplingForSni" -Value 1

A reboot is required for the change to take effect.

2. Confirm outbound access — your IIS host needs to reach the OCSP responder URL listed in the AIA extension of your cert. If outbound HTTP is firewalled, stapling silently fails and the server falls back to non-stapled handshakes.

Fix on HAProxy

HAProxy supports stapling but does NOT fetch the OCSP response automatically — you have to provide it via a .ocsp file alongside your cert:

openssl ocsp   -issuer /etc/haproxy/certs/intermediate.pem   -cert   /etc/haproxy/certs/server.pem   -url "$(openssl x509 -in /etc/haproxy/certs/server.pem -noout -ocsp_uri)"   -respout /etc/haproxy/certs/server.pem.ocsp   -noverify

Then either restart HAProxy or use the runtime API to push the new OCSP response without dropping connections.

Schedule this fetch via cron every few hours; OCSP responses typically have a 7-day validity but you want to refresh well before they expire.

Cloud and managed-service notes

• AWS ALB / ELB / CloudFront — stapling is enabled by default. If this advisory fires on an AWS load balancer, something else is going on; open a support ticket.
• Azure App Service — stapling is enabled by default since 2017.
• Cloudflare — stapling on by default. No configuration needed.
• F5 BIG-IP — enable in the Client SSL profile under OCSP Stapling Parameters. You'll need to attach an OCSP profile pointing at your CA.

Verify the fix

1. Confirm with openssl:

openssl s_client -connect your-host.example.com:443 -servername your-host.example.com -status < /dev/null 2>&1   | grep -A 1 "OCSP response:"

If stapling is working, you'll see OCSP Response Status: successful (0x0). If not, you'll see OCSP response: no response sent.

2. Re-scan in CertTracker. Trigger a re-scan from the CertTracker UI. The fastest path: open the monitor's detail modal (click the monitor row on the Monitors page), scroll to the Active Advisories section, and click the orange ⟳ Re-scan button on the right side of the section header. The status line below the header will confirm the cert re-poll and TLS audit are queued; the next 5-minute poller tick (within ~5 minutes) runs both, and the advisory clears if your fix took. See Where to find these buttons in the UI for visual landmarks.

Common pitfalls

• Server can't reach the OCSP responder — firewall blocks outbound HTTP, or the OCSP URL embedded in the cert is unreachable. Check with openssl x509 -in cert.pem -noout -ocsp_uri to find the URL, then curl -v to confirm reachability.
• Wrong chain file — if the trusted chain doesn't include the CA that signed the OCSP responder cert, verification fails and the server falls back. Use openssl verify to sanity-check your chain file.
• First-request behavior — on Apache and Nginx, the very first TLS handshake after a server restart can come in without a stapled response (the server hasn't fetched one yet). Subsequent handshakes have it. CertTracker's advisory won't fire just because of a single first-request miss; if it persists, the fetch isn't completing.

Related advisories

None directly. OCSP stapling is independent of cipher/protocol issues, certificate algorithm, and the HSTS family.

Back to the TLS hardening hub.