OCSP Stapling Explained: What It Is, How It Works, and How to Enable It

What is certificate revocation?

A CA certificate has two end-of-life conditions: expiry and revocation. Expiry is automatic — the certificate simply stops being trusted after the Not After date. Revocation is deliberate — the CA marks the certificate as invalid before expiry, typically because:

• The certificate's private key was compromised or stolen
• The certificate was mis-issued — wrong domain, wrong organization
• The organization ceased to operate or changed legal identity
• The subscriber requested revocation (early replacement, key rotation)

There are two traditional mechanisms for distributing revocation information to clients (our CRL vs OCSP revocation guide compares them in depth and covers the 2025–2026 shift back to CRLs):

Chrome takes a different approach entirely: it uses CRLSets — a curated, compressed list of high-priority revocations (compromised CA intermediates, high-profile incidents) distributed through Chrome's component update mechanism. CRLSets cover a small fraction of all revocations but do so without any per-connection network request.

Plain OCSP and its problems

Vanilla OCSP — where the browser queries the CA's OCSP responder directly — has three significant drawbacks in practice:

What is OCSP stapling?

OCSP stapling — formally the TLS Certificate Status Request extension, defined in RFC 6066 (Section 8) — shifts the OCSP query from the browser to the web server. Instead of the browser contacting the CA's OCSP responder on every new connection, your web server periodically fetches the OCSP response, caches it, and "staples" it to the TLS handshake it sends to the browser.

This resolves all three problems with plain OCSP simultaneously:

• No browser roundtrip — the revocation proof arrives in the same TLS handshake as the certificate itself.
• Privacy preserved — the CA never sees the browser's IP address; only the server contacts the OCSP responder.
• Cached server-side — if the CA's OCSP server is temporarily unavailable, the server continues serving its cached response until it expires, rather than leaving clients to soft-fail.

The stapled OCSP response is signed directly by the CA, so the browser can verify its authenticity without trusting the server. A compromised server cannot forge a valid OCSP response — it would need the CA's private signing key.

How OCSP stapling works step by step

Here is the sequence of events when OCSP stapling is enabled on a server:

OCSP Must-Staple (RFC 7633)

OCSP stapling is optional — a browser that supports it will use the stapled response if present, but will also accept a certificate without one (the soft-fail problem persists in the absence of stapling). OCSP Must-Staple was designed to close this gap.

Defined in RFC 7633, OCSP Must-Staple is an X.509v3 certificate extension (OID 1.3.6.1.5.5.7.1.24) that a CA can embed in a certificate at issuance. It instructs clients that a valid stapled OCSP response is mandatory — if the server fails to provide one, the client must reject the connection.

In theory, this hard-fails revocation checks rather than soft-failing. In practice, Must-Staple has not been widely adopted:

• Browser enforcement was inconsistent — some browsers ignored the extension
• Server misconfiguration (forgetting to enable stapling on a Must-Staple cert) immediately breaks all connections to the site, with no bypass option
• Let's Encrypt removed Must-Staple support in January 2025
• The industry is moving toward short-lived certificates as the replacement for revocation checking — see the 47-day certificate lifetime roadmap

What changed in 2025–2026

The OCSP ecosystem shifted significantly in 2023–2026. Understanding these changes helps you assess whether OCSP stapling is relevant for your setup.

When does OCSP stapling still matter?

Enable OCSP stapling on Nginx

Nginx has supported OCSP stapling since version 1.3.7 (released 2012). The feature requires OpenSSL 0.9.8h or later, which is standard on any current Linux distribution. Configuration is done in the server block for the HTTPS virtual host.

Add the following directives to your HTTPS server block:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;   # leaf + intermediates
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # OCSP stapling
    ssl_stapling        on;
    ssl_stapling_verify on;

    # Chain file for OCSP verification (intermediates + root, or full chain)
    ssl_trusted_certificate /etc/ssl/certs/chain.pem;

    # Resolver for the server to reach the CA's OCSP endpoint
    # Use a fast public resolver or your own caching resolver
    resolver        8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
}

After editing the configuration, test and reload:

nginx -t && systemctl reload nginx

Nginx fetches the OCSP response on the first TLS connection after reload, not at reload time. The response won't appear immediately — make one HTTPS request to the site first, then verify (see the verification section).

Enable OCSP stapling on Apache

Apache HTTP Server has supported OCSP stapling since version 2.3.3 via mod_ssl. The key difference from Nginx is that the stapling cache must be defined at the global server level (outside any VirtualHost block).

Step 1: Add the global stapling cache

In your main Apache configuration file (e.g., /etc/apache2/apache2.conf or /etc/httpd/conf/httpd.conf), outside any VirtualHost:

# Global OCSP stapling cache — place OUTSIDE any VirtualHost block
SSLUseStapling On
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

Step 2: Configure the VirtualHost

Inside your HTTPS VirtualHost block, add the optional tuning directives:

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile   /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/chain.pem

    # Optional: tune OCSP stapling behavior per-vhost
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    SSLStaplingFakeTryLater off
</VirtualHost>

Test the configuration and restart:

apachectl configtest && systemctl restart apache2
# or on RHEL/Rocky/AlmaLinux:
apachectl configtest && systemctl restart httpd

See our Apache SSL installation guide for more on assembling the certificate chain file correctly.

Enable OCSP stapling on IIS

Microsoft IIS has supported OCSP stapling since IIS 7 on Windows Server 2008, and it is enabled by default on IIS 8 and later. In most cases there is nothing to configure — Windows handles the OCSP response caching and stapling automatically through the Windows Certificate Services infrastructure (CryptoAPI).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
  EnableOcspStaplingForSni = 1  (DWORD)

net stop http /y && net start w3svc

IIS fetches and caches OCSP responses via the Windows HTTP Services (WinHTTP) stack. The cache is shared across all IIS sites. Unlike Nginx and Apache, there are no per-site OCSP stapling directives to configure — it's either on or off at the Windows platform level.

Verify OCSP stapling

1. OpenSSL command-line test

The most reliable way to verify stapling is with the OpenSSL client. Run:

echo QUIT | openssl s_client -connect example.com:443 -status 2>/dev/null   | grep -A 10 "OCSP response"

A successful stapling response includes:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
...
    Cert Status: Good

If you see OCSP response: no response sent, stapling is not working. On Nginx, make sure you've made at least one HTTPS request to the site since the last reload — Nginx fetches the OCSP response lazily on the first request, not at startup.

2. SSL Labs test

The Qualys SSL Labs server test (ssllabs.com/ssltest) reports OCSP stapling status in the "Certificate" section. Look for:

OCSP stapling   Yes

3. Browser DevTools

In Chrome, open DevTools → Security tab → click "View certificate" → look at the certificate details. The "OCSP" field shows whether a stapled response was included. Note that Chrome uses CRLSets rather than live OCSP checks, so it may not display this for all sites.

Common issues

Frequently asked questions