Skip to main content
All fixes

SSL, TLS, security headers

Enable OCSP stapling to speed up TLS handshakes and improve privacy

Without OCSP stapling, browsers fetch revocation status from the CA themselves, slowing first connections and leaking visit data. Enable stapling on nginx, Apache, or your CDN.

What's happening

OCSP (Online Certificate Status Protocol) lets a client check whether a certificate has been revoked. Without stapling, the client makes a separate HTTP request to the CA's OCSP responder during the TLS handshake — adding latency, blocking the first connection, and leaking the visited hostname to the CA. With stapling, the server fetches the OCSP response itself, caches it, and presents a signed timestamped status alongside the certificate during the handshake.

Stapling improves performance (no extra round-trip), privacy (CA does not learn who visited you), and reliability (when the CA's OCSP service is slow or down, stapling continues to work from the cache). Modern browsers expect it on production-grade sites, and the OCSP-Must-Staple X.509 extension hardens the relationship by refusing connections without a staple.

The fix is one or two config lines in nginx or Apache, plus a trusted-CA file path that the server uses to verify intermediates while fetching responses. Most CAs and CDNs (Let's Encrypt, Cloudflare, AWS) support stapling out of the box.

Why it matters

First-byte latency drops by 100–500 ms when the client would otherwise hit the OCSP responder. For mobile users on flaky networks the win is much larger.

Without stapling, an attacker who blocks the OCSP responder can prevent the client from learning that a stolen certificate was revoked. Stapling does not fix this on its own but combined with OCSP-Must-Staple it does.

SSL Labs grades stapling as a small but visible plus. Mozilla and Google both recommend stapling on every TLS server.

Common causes

  • ssl_stapling directive missing in nginx, or SSLUseStapling off in Apache.
  • Stapling enabled but ssl_trusted_certificate not set, so the server cannot verify the intermediate's OCSP response.
  • OCSP responder is unreachable from the server (firewall blocks outbound 80/443).
  • Stapling is enabled but ssl_stapling_verify is off, accepting unverified responses.
  • Server clock is wrong, causing OCSP timestamps to fail validation.

Detect this on your site

Run a quick scan with the SSL Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open SSL Checker

How to fix it

  1. 1

    Check whether stapling is currently active

    Run openssl s_client -connect example.com:443 -servername example.com -status /dev/null | grep -A 17 'OCSP response'. If the response shows 'Cert Status: good' with a Produced At timestamp, stapling is working. If it shows 'OCSP response: no response sent', it is not.

  2. 2

    Enable stapling in nginx

    In the server block: ssl_stapling on;, ssl_stapling_verify on;, and ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;. Add a DNS resolver too: resolver 1.1.1.1 8.8.8.8 valid=300s;. Reload nginx.

  3. 3

    Enable stapling in Apache

    Outside the VirtualHost (server level): SSLUseStapling on and SSLStaplingCache shmcb:/var/run/ocsp(128000). Inside the HTTPS VirtualHost the certificate must include the issuer's chain so Apache can build the OCSP request. Reload Apache.

  4. 4

    Enable on Cloudflare or your CDN

    Cloudflare staples automatically when you use their edge certificate; no toggle needed. Fastly stapling is enabled by default. AWS CloudFront and ALB also handle stapling on the edge — origin config doesn't need it for CDN-fronted traffic.

  5. 5

    Pre-warm the OCSP cache

    After enabling, make a few HTTPS requests to the server to populate the cache before traffic ramps. Otherwise the first user might see a delayed handshake while the server fetches the OCSP response synchronously.

  6. 6

    Confirm via SSL Labs

    Run an ssllabs.com/ssltest report. The 'OCSP stapling' line should read Yes. Mozilla Observatory and the SSL Checker at /ssl will also confirm.

Example

server {
    listen 443 ssl http2;
    server_name example.com;

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

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

Nginx OCSP stapling configured for Let's Encrypt certificates

Frequently asked

Yes — every Let's Encrypt certificate is issued with the Authority Information Access extension pointing at their OCSP responder. Just enable stapling in your web server with the chain.pem path and resolver.

Must-Staple is an X.509 extension that tells clients to refuse the certificate if no OCSP staple is presented. It hardens revocation but breaks the site if your stapling pipeline fails. Enable only after stapling has been stable for months and you have monitoring on it.

Related fixes