Every time I run an SSL Labs test on a server without OCSP stapling enabled, I see the same thing: a slightly slower handshake and a missed opportunity for an easy performance and privacy win. OCSP stapling is one of those features that takes ten minutes to configure but genuinely improves both speed and user privacy. Here’s exactly how I set it up in Apache.
What Is OCSP Stapling?
When a browser connects to your HTTPS site, it needs to check whether your SSL certificate has been revoked. Traditionally, it does this via the Online Certificate Status Protocol (OCSP), sending a request directly to the Certificate Authority’s OCSP responder to ask “is this certificate still valid?”
This has two downsides:
- Latency — the browser has to make an extra round-trip to a third-party server before finishing the page load.
- Privacy — the CA can see exactly which sites a given user is visiting, since it receives a real-time query for each certificate check.
OCSP stapling fixes both problems. Instead of the browser querying the CA directly, your web server periodically queries the CA itself, caches the signed OCSP response, and “staples” it directly to the TLS handshake. The browser gets the revocation status without ever contacting the CA itself.
Real-World Benefits
- Faster page loads, especially for first-time visitors, since there’s no extra OCSP round-trip.
- Improved privacy, since the CA no longer sees a live log of who’s visiting your site.
- Better resilience — if a CA’s OCSP responder is slow or temporarily down, stapling prevents that from stalling your visitors’ connections.
Prerequisites
- Apache 2.3.3+ (OCSP stapling support was introduced here; I recommend 2.4+ for full feature support).
mod_sslenabled.- A valid SSL certificate with a complete chain (OCSP stapling relies on being able to identify the issuing CA).
- Outbound internet access from your server so Apache can reach the CA’s OCSP responder.
Step 1: Confirm mod_ssl Is Enabled
sudo a2enmod ssl
sudo systemctl restart apache2
On CentOS/RHEL, confirm mod_ssl is installed:
sudo yum install mod_ssl
Step 2: Add OCSP Stapling Directives
I add these directives at the global level (outside any <VirtualHost> block), typically in the main SSL config file or httpd.conf:
SSLStaplingCache shmcb:/var/run/ocsp(128000)
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
What Each Directive Does
SSLStaplingCache— defines the shared memory cache used to store OCSP responses so they can be reused across requests and workers instead of being fetched every time.shmcbis the recommended cache type for multi-process Apache setups (like the defaultpreforkorworkerMPMs).SSLUseStapling on— the master switch enabling stapling.SSLStaplingResponderTimeout— how long Apache waits for a response from the CA’s OCSP responder before giving up.SSLStaplingReturnResponderErrors off— prevents Apache from passing along a broken/error OCSP response to clients; instead it simply omits the staple, which is safer than serving an invalid one.
Step 3: Enable Stapling Per Virtual Host
Inside each SSL-enabled <VirtualHost>, I add:
<VirtualHost *:443>
ServerName yourdomain.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/yourdomain-fullchain.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain.key
SSLUseStapling on
</VirtualHost>
Note that stapling depends on Apache being able to see the full certificate chain, so make sure your SSLCertificateFile includes the intermediate certificate(s) — I cover this in detail in my dedicated guide on SSL certificate chain files.
Step 4: Test the Configuration
sudo apachectl configtest
sudo systemctl reload apache2
Step 5: Verify OCSP Stapling Is Working
I use OpenSSL to directly inspect whether Apache is stapling a response:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -status < /dev/null 2>&1 | grep -A 20 "OCSP response"
A working staple shows something like:
OCSP Response Status: successful (0x0)
Cert Status: good
If instead you see OCSP response: no response sent, stapling isn’t active yet — usually meaning either the config isn’t loaded correctly, or Apache hasn’t fetched a response from the CA yet (the very first request after a restart can sometimes miss the staple while Apache populates its cache).
I also check with the SSL Labs Server Test, which explicitly reports whether OCSP stapling is active under its certificate details.
Understanding OCSP Must-Staple
Some certificates include an “OCSP Must-Staple” flag (via a certificate extension) that tells browsers to reject the connection if no valid staple is presented, rather than falling back gracefully to a live OCSP check. I only enable must-staple once I’ve thoroughly tested that stapling works reliably on my server, since a misconfiguration combined with a must-staple certificate can actually break access for visitors rather than just degrade performance.
If your CA issued a must-staple certificate, double-check your Apache configuration is airtight before deploying it to production — test on a staging subdomain first if at all possible.
How OCSP Stapling Interacts With Multiple Virtual Hosts
On a server hosting multiple SSL-enabled domains, each virtual host maintains its own staple, cached independently, even though they share the same global SSLStaplingCache. I’ve found this occasionally causes confusion when one domain’s stapling works and another’s doesn’t — the root cause is almost always an incomplete certificate chain on the domain that’s failing, not a global cache issue. I always troubleshoot per-domain rather than assuming a global stapling problem when only one site is affected.
Common Mistakes I See
- Placing stapling directives inside a
<VirtualHost>only —SSLStaplingCachemust be defined globally, not per-vhost, or Apache will throw a configuration error. - Blocking outbound traffic — if your server’s firewall blocks outbound connections to the CA’s OCSP responder, stapling silently fails. I always confirm outbound HTTP/HTTPS access is allowed.
- Missing intermediate certificates — Apache needs the issuer’s certificate to correctly query and staple an OCSP response; an incomplete chain breaks stapling even if the base certificate config looks fine.
- Assuming it’s instantly active — the first request after a reload might not have a cached staple yet since Apache fetches it lazily on first use in some configurations.
Security Best Practices
- Keep
SSLStaplingReturnResponderErrors offso clients never receive a malformed or error staple — Apache will just omit it rather than serve something incorrect. - Monitor your OCSP responder connectivity; if your server can’t reach the CA, stapling degrades gracefully but you lose the performance/privacy benefit silently.
- Combine OCSP stapling with a properly configured certificate chain and strong cipher suite for a complete, modern TLS setup.
- Consider
SSLStaplingErrorCacheTimeoutto control how long Apache waits before retrying a failed OCSP fetch:
SSLStaplingErrorCacheTimeout 60
Performance Optimization Tips
- Increase the
SSLStaplingCachesize (shmcb:/var/run/ocsp(128000)) if you’re running many domains/certificates on one server, since each cached response consumes cache space. - Pair stapling with HTTP/2 and session resumption for the fastest possible handshake times.
- Monitor
SSLStaplingResponderTimeout— a value too low might cause Apache to give up prematurely on slower CA responders, while too high could delay handshakes if a responder is unreachable.
OCSP Stapling and CDNs or Reverse Proxies
If your Apache server sits behind a CDN or a reverse proxy that terminates TLS itself (like Cloudflare in proxied mode, or a load balancer terminating SSL upstream), OCSP stapling needs to be configured at whichever layer is actually handling the TLS handshake with the end user’s browser. Configuring it on your origin Apache server in that scenario has no visible effect for visitors, since they never talk to Apache’s TLS layer directly. I always confirm exactly where TLS termination happens before spending time debugging stapling that “isn’t working” — often it’s working fine, just at a different layer than expected.
Troubleshooting
Problem: “OCSP response: no response sent” persists Check that your server can actually reach the CA’s OCSP responder:
curl -v http://ocsp.yourca.com
If this fails, check firewall rules for outbound HTTP traffic.
Problem: Apache fails to start with an “SSLStaplingCache” error Confirm the directive is in the global server config, not nested inside a <VirtualHost> block.
Problem: Stapling works for one domain but not another on the same server Each certificate needs a complete chain for stapling to work. Check that every virtual host’s SSLCertificateFile includes the correct intermediate.
FAQs
Does OCSP stapling replace the need for CRLs or standard OCSP checks entirely? No — it’s a delivery optimization. Revocation checking still ultimately relies on OCSP or CRL data; stapling just changes who fetches it and when.
Will OCSP stapling work with wildcard or multi-domain (SAN) certificates? Yes, as long as the chain is complete and the directives are correctly applied to each relevant virtual host.
Is OCSP stapling required for TLS 1.3? It’s not required, but it’s still supported and beneficial. TLS 1.3 changed some handshake mechanics, but OCSP stapling continues to function normally in Apache with TLS 1.3 connections.
Summary and Key Takeaways
OCSP stapling is a small configuration change with a real impact on handshake speed and visitor privacy. By having Apache proactively fetch and cache OCSP responses, you eliminate an extra round-trip for browsers and stop leaking visitor activity to the CA.
Key takeaways:
SSLStaplingCachemust be defined globally, andSSLUseStapling onper virtual host.- A complete certificate chain is required for stapling to function correctly.
- Verify with
openssl s_client -statusor SSL Labs, not just by assuming the config took effect. - Combine with strong ciphers, PFS, and a valid chain for a complete modern TLS configuration.