TL;DR: Without OCSP stapling, every visitor to your site asks your Certificate Authority “is this cert still valid?” before trusting it. With stapling, your server pre-fetches that answer every few hours and hands it out itself. Faster for users, more private (your CA stops seeing every visit), and one config line in most servers.

What is it?

When a browser sees your TLS certificate during the handshake, it doesn’t just check that the math is right. It also wants to know whether the certificate has been revoked — pulled back by your CA after issuance because the private key leaked, the domain changed hands, or some other incident.

The Online Certificate Status Protocol (OCSP, RFC 6960) is how this revocation check happens. Your CA runs an “OCSP responder” — a public endpoint that signs short-lived statements like “as of 6 hours ago, the cert with serial number X is still valid.” Without stapling, the browser fetches one of these statements from the CA itself before completing the TLS handshake.

OCSP stapling flips the work. Your server periodically fetches the fresh OCSP response (every few hours) and includes it — “staples” it — into the TLS handshake along with the certificate. The browser sees a fresh, signed revocation status without ever talking to the CA.

Why does it matter?

Two real wins:

Privacy. Without stapling, your CA sees a record of every visit to every site they’ve issued a cert for. That’s a lot of metadata about who’s reading what, sitting on a few CAs’ servers. With stapling, your CA only sees your server’s periodic refresh — not your visitors.

Performance. Without stapling, every first connection to your site includes a network round-trip to the CA’s OCSP responder before the browser will trust your cert. CA responders are usually fast but they can be slow, geographically distant from the user, or temporarily down. With stapling, the data is already in the handshake — no extra hop.

There’s also a security wrinkle: browsers historically default to “trust the cert anyway” if the OCSP responder is unreachable, because the alternative would break too much of the web during CA outages. That’s called “soft-fail,” and it weakens revocation in practice. Stapling sidesteps the issue — your server’s refresh is reliable because you control it, while the visitor’s path through the CA is exactly the path attackers can interfere with.

Real-world analogy

Picture a bouncer at a bar checking IDs. Without stapling, the bouncer texts the DMV every time someone shows up: “is this license still valid?” Slow. Privacy-leaky (the DMV now knows everyone going to your bar). And if the DMV’s network is flaky, the line piles up.

With stapling, the bouncer keeps a notarized statement that says “I called the DMV at 2pm and confirmed all current licenses are still valid.” Every guest just sees the bouncer’s statement. Fast. The DMV doesn’t see the guest list. And the bouncer can refresh the statement every couple hours without breaking the line.

How WQI measures this

We grade OCSP stapling as factor WEBQ-91 in the Security category. We see it directly in the TLS handshake itself: the server’s CertificateStatus message in TLS 1.2, or the status_request extension on the CertificateEntry in TLS 1.3.

ResultWhat it means
Pass (100)Server stapled an OCSP response.
Fail (0)Server did not staple.

A future version will add a “warn” tier for stapled-but-stale (where the OCSP response’s thisUpdate is more than 7 days old). Today we only check presence.

What good looks like

Pass on WEBQ-91, every audit, every domain. Stapling is essentially free to enable on every modern web server, has no downside in practice for ~99% of deployments, and unlocks both the privacy and perf wins above. There’s no good reason to leave it off in 2026.

How to fix it

Nginx — add to your server block:

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

The resolver directive is required so Nginx can look up your CA’s OCSP responder hostname. Without it, stapling silently fails to start.

Apache — in your VirtualHost or main config:

SSLUseStapling On
SSLStaplingCache shmcb:/var/run/ocsp(128000)

The SSLStaplingCache directive is required (Apache won’t start stapling without somewhere to cache the responses).

Caddy — enabled by default. No config needed.

Cloudflare — enabled automatically for all proxied domains. No action required if your site is behind Cloudflare’s orange cloud.

HAProxy — bind ... ssl crt cert.pem ca-file ... plus a separate periodic openssl ocsp cron job to refresh staple files. Less seamless than the dynamic-fetch approach in Nginx/Apache.

Verify after enabling:

openssl s_client -connect yourdomain.com:443 -status </dev/null 2>/dev/null \
  | grep -A 1 "OCSP Response Status"

You should see OCSP Response Status: successful and a Cert Status: good further down. If it says OCSP response: no response sent, stapling didn’t take effect — usually a missing resolver (Nginx) or cache (Apache) directive.

Common pitfalls

  • No resolver directive in Nginx. The most common deployment mistake. Nginx needs DNS to look up the OCSP responder hostname; if you don’t tell it which DNS server to use, it falls back to a path that doesn’t actually resolve. Stapling silently fails.
  • Firewalled outbound traffic. Your server needs to reach the CA’s OCSP responder to fetch the response. If your egress firewall blocks arbitrary HTTP outbound, stapling can’t work. Allow-list the CA’s OCSP host.
  • Cert without an OCSP URI. Some private/internal CAs don’t run an OCSP responder. Their certs have no OCSP URI to fetch from, so stapling is impossible. This is fine for internal-only certs but rules out the WEBQ-91 score by definition.

Going further: OCSP Must-Staple

OCSP stapling is voluntary by default. Even when you enable it on the server, a network attacker can suppress the staple and most browsers will fall back to the soft-fail behavior described above. OCSP Must-Staple (WEBQ-96) is a stronger commitment: a cert extension that tells browsers “refuse to connect if I’m not stapled.” It closes the soft-fail window — at the cost of breaking your site if your stapling ever hiccups. Most operators stop at WEBQ-91; only enable Must-Staple once you’ve proven stapling reliability across CA outages.

Further reading