How to Configure OCSP Stapling on Apache and Nginx (with Verification and Troubleshooting)

Enable OCSP stapling in the server’s TLS configuration, then confirm it in a real handshake. Apache needs both SSLUseStapling On and a mandatory shared cache; Nginx needs ssl_stapling on;, a DNS resolver, and trusted issuer-chain certificates when verification is enabled. A syntactically valid configuration is not enough: the certificate must advertise an OCSP responder, the server must reach it, and the cache or fetched response must be available when clients connect.

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

What OCSP stapling does

Online Certificate Status Protocol (OCSP) lets a TLS server ask a certificate authority (CA) whether a certificate is revoked. Without stapling, a browser or other TLS client may have to contact the CA during the handshake. That adds another network dependency, can reveal which sites a client is visiting to the responder, and may delay connection setup.

#	Preview	Product	Price
1		Network Security: Private Communication in a Public World (Prentice Hall Series in Computer...	$63.20	Buy on Amazon
2		CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)	$41.83	Buy on Amazon
3		Cybersecurity For Dummies (For Dummies: Learning Made Easy)	$13.53	Buy on Amazon
4		Network Security, Firewalls, and VPNs	$66.62	Buy on Amazon
5		The Practice of Network Security Monitoring: Understanding Incident Detection and Response	$48.16	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

With stapling, the server periodically obtains a signed OCSP response from the responder named by the certificate’s Authority Information Access (AIA) extension. During the TLS handshake, it sends that response to the client as a stapled status message. The client can validate the response without making its own OCSP request. Stapling does not replace certificate-chain validation, private-key protection, or a complete revocation strategy; it is a way to deliver the CA’s status response efficiently.

Apache and Nginx perform the same protocol function but expose different controls. Apache’s cache is compulsory. Nginx relies on an explicit resolver for responder DNS lookups and, when stapling verification is enabled, an explicit trust store containing the issuer and chain.

#1 Best Overall

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

Buy on Amazon

Requirements before changing configuration

• A certificate whose AIA extension contains an OCSP responder URL. The responder address is certificate-specific; inspect the certificate you actually deployed rather than assuming a CA’s current endpoint.
• The server certificate and the intermediate certificates required by clients. A missing intermediate can prevent both ordinary chain building and OCSP validation.
• Outbound network access from the web server to the responder, normally over HTTP, plus working DNS resolution from the server.
• An Apache or Nginx build with the relevant TLS module and an OpenSSL installation capable of inspecting the handshake. Directive availability and defaults vary with installed server and OpenSSL versions.
• A maintenance window or reload procedure that preserves existing connections. Validate configuration before reloading so a syntax error does not take the service offline.

Certificate authorities can change responder URLs and operational behavior. Re-check the deployed certificate’s AIA extension and the documentation for the exact server version whenever you renew a certificate or upgrade the TLS stack.

Apache: enable stapling and its mandatory cache

Apache’s mod_ssl documentation is explicit: “Configuration of a cache is mandatory for OCSP stapling.” Turning on stapling without defining a cache is therefore incomplete and can leave the feature nonfunctional.

1. Put the directives in global SSL configuration

Define stapling and a shared-memory cache at the global SSL configuration scope used by your distribution. A representative configuration is:

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

SSLUseStapling On enables stapling for the virtual hosts that inherit it. SSLStaplingCache selects an shmcb shared-memory cache; the value in parentheses is the cache size in bytes. The example path is not universal. Apache’s guidance provides different locations for source builds, Debian/Ubuntu systems, Red Hat-family systems, and other layouts, so use the directory intended for global runtime state on your operating system. The Apache process must be able to create or access the cache resource.

Do not place the cache only inside one virtual host when several HTTPS hosts are expected to staple. The cache is intended to be shared by the SSL-enabled workers and virtual hosts that use the global setting.

Rank #2

Sale

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

Buy on Amazon

2. Keep virtual-host behavior intentional

A virtual host normally inherits the global setting. If one host must not staple, use an explicit override in that host:

<VirtualHost *:443>
    ServerName no-staple.example
    SSLUseStapling Off
    ...
</VirtualHost>

Use this exception deliberately. It does not remove the global cache, and it does not enable stapling for a host whose certificate or network path cannot support it.

3. Consider responder and cache controls

mod_ssl also documents controls for responder timeouts, standard and error-cache timeouts, response age, clock skew, and responder errors. Keep the defaults unless you have a measured operational reason to change them. If you do tune them, document the reason and test renewal, responder outage, and stale-response behavior; an aggressive timeout can create repeated responder traffic, while an overly permissive age or error policy can leave clients with outdated status information.

4. Validate and reload safely

1. Run the configuration test appropriate to your installation, commonly apachectl configtest or httpd -t. It must report a successful syntax check.
2. Confirm that the configured cache directory and shared-memory resource are usable by the account that starts Apache. A syntactically correct directive can still fail at startup or first use if the path is inaccessible.
3. Perform a graceful reload using the service manager for your distribution. A graceful operation lets existing connections finish while new workers use the updated settings.
4. Inspect the error log immediately after reload and after the first client handshake. Cache initialization, responder access, certificate-chain problems, and stapling failures are reported there rather than by the browser in a useful form.

Nginx: resolver, trusted chain, and stapling directives

Nginx’s model exposes the network and trust requirements directly. Enable stapling in the relevant http or server context, specify a resolver that can resolve the responder hostname, and provide trusted certificate material when verification is on.

1. Enable stapling and DNS resolution

ssl_stapling on;
resolver 1.1.1.1 1.0.0.1 valid=300s;

The Nginx module documentation says that a resolver directive should be specified to resolve the OCSP responder hostname. Choose resolvers reachable from the server and permitted by your network policy; the addresses above are only an example. valid=300s controls how long Nginx caches DNS answers in this example, not how long an OCSP response remains valid.

Rank #3

Sale

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

Buy on Amazon

Place the resolver where the affected virtual servers inherit it, or in each server context where policy requires a different resolver. A resolver configured in an unrelated block does not help a server block that cannot inherit it.

2. Provide the complete client certificate chain

The file named by ssl_certificate should contain the server certificate followed by the intermediate certificates needed by clients. Do not assume that a browser’s cached intermediates will hide an incomplete file; automated clients, monitoring tools, and first-time visitors may not have them.

ssl_certificate     /etc/nginx/tls/site-fullchain.pem;
ssl_certificate_key /etc/nginx/tls/site.key;

The private-key file is shown only to identify the related certificate pair; protect it with the permissions and ownership appropriate to your Nginx master process.

3. Configure trusted material for stapling verification

To ask Nginx to verify the responder’s OCSP response, enable verification and point ssl_trusted_certificate at a PEM bundle containing the server certificate’s issuer, the root certificate, and all required intermediate certificates:

ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/tls/ca-chain.pem;

Nginx’s module documentation specifically requires the issuer, root, and all intermediate certificates to be configured as trusted for verification to work. This trust bundle is separate from the certificate chain sent to clients: ssl_certificate serves the chain, whereas ssl_trusted_certificate supplies trust anchors and issuers used for verification. Keep the bundle current when a certificate is renewed, an intermediate changes, or a root is replaced.

Rank #4

Sale

Network Security, Firewalls, and VPNs

$66.62

Buy on Amazon

4. Use a pre-fetched response only when required

Nginx also supports ssl_stapling_file when you want to supply a response from a file instead of having Nginx fetch it from the responder. The module documentation expects DER output produced by the openssl ocsp command. A file-based response introduces an operational task: obtain a fresh response before its validity window expires, install it atomically, and reload or otherwise make Nginx use the new file according to your deployment process. For most installations, live fetching with a resolver is simpler.

5. Test and reload

1. Run nginx -t and correct every error before reloading.
2. Check file permissions and readability for the certificate, key, trust bundle, and any stapling file.
3. Reload Nginx gracefully with the service manager or nginx -s reload after a successful test.
4. Review the Nginx error log during the first handshake. Resolver failures, inability to reach the responder, untrusted issuer certificates, and malformed responses are typically visible there.

Apache and Nginx compared

Verify that a live handshake contains a stapled response

Configuration output alone cannot prove delivery. Test the public endpoint after the graceful reload. OpenSSL’s client can request and display the stapled status response:

openssl s_client -connect www.example.com:443 -servername www.example.com -status </dev/null

Use the real hostname in both places. -servername is important on servers hosting multiple certificates because it selects the intended virtual host through SNI. In the output, look for an OCSP response section. A populated response includes status and validity fields; “no response sent” or an empty OCSP section means the server did not staple a response on that handshake.

Run the test from a network that reaches the public service, not only from localhost. If a load balancer, reverse proxy, or TLS terminator sits in front of Apache or Nginx, test the component that actually terminates TLS. Different nodes can have different caches, DNS access, certificates, or configuration, so repeat the check against each production address when possible.

Troubleshoot “no stapled OCSP response”

1. Confirm that the certificate advertises OCSP

Inspect the deployed certificate and locate its Authority Information Access extension. If no OCSP URL is present, the server has nowhere to fetch a response. Renewing with a certificate that includes AIA is then a certificate-issuance decision, not an Apache or Nginx directive fix.

Best Value

Sale

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

• Used Book in Good Condition

$48.16

Buy on Amazon

2. Check DNS and outbound HTTP

Resolve the exact responder hostname from the server and verify that outbound HTTP access is allowed by firewalls, proxies, routing, and egress policy. Nginx commonly fails when the configured resolver cannot answer or is unreachable. Apache can fail for the same underlying network reasons even though DNS is not represented by a dedicated stapling directive.

3. Check the chain in both roles

• For clients, ensure the server certificate file includes every required intermediate.
• For Nginx verification, ensure ssl_trusted_certificate includes the issuer, root, and all intermediates.
• For Apache, confirm that the virtual host’s certificate and chain settings match the certificate being tested, especially when several hosts share an IP address.

Do not confuse a CA bundle used for trust with the chain sent to clients. They serve different purposes and may legitimately be different files.

4. Inspect Apache’s cache state

Apache requires the stapling cache even when all other directives are present. Verify that the cache directive is in the global SSL scope, that its path is valid for the operating system, and that Apache can initialize it. A cache that cannot be created, is too constrained for the deployment, or is lost on every restart can prevent a response from being available when the handshake occurs.

5. Inspect Nginx trust and resolver settings

For Nginx, verify spelling, context, and inheritance of ssl_stapling on;, resolver, ssl_stapling_verify on;, and ssl_trusted_certificate. A resolver in a server block that is not handling the tested hostname, or a trust bundle that omits an intermediate, can produce a handshake with no usable staple even though nginx -t succeeds.

6. Allow for cache warm-up and responder behavior

A newly reloaded service may not have a current response immediately. Watch logs and test again after the server has had an opportunity to contact the responder. Responder errors, timeouts, response-age limits, clock skew, and cached error responses can all affect whether a response is sent. Check the server clock as well; a materially incorrect time can make an otherwise valid response fail freshness checks.

7. Test every certificate and endpoint

Stapling is tied to a certificate and a TLS endpoint. Test each hostname, certificate type, listening address, and load-balancer node that clients use. A successful result for one virtual host does not prove that another inherited the same settings or has the same AIA responder and chain.

Operational checklist for deployment

• Record the certificate’s AIA OCSP URL and check it again after renewal.
• For Apache, deploy SSLUseStapling On together with a valid global SSLStaplingCache.
• For Nginx, deploy ssl_stapling on; and a reachable resolver.
• For Nginx verification, maintain a trust bundle with the issuer, root, and all intermediates, and reference it with ssl_trusted_certificate.
• Ensure the client-facing certificate file contains the server certificate and required intermediates.
• Permit DNS and outbound responder traffic from the TLS-terminating host.
• Run the server’s configuration test before every reload.
• Reload gracefully, then inspect error logs.
• Use an OpenSSL -status handshake against the public hostname and confirm an actual OCSP response is present.
• Repeat testing after certificate renewal, server upgrades, DNS changes, and topology changes such as adding a new TLS terminator.

What success looks like

A successful deployment has all of the following characteristics: the certificate contains an OCSP responder URL; the TLS terminator can resolve and reach it; Apache has an initialized stapling cache or Nginx can fetch and validate a response; the certificate chain is complete for clients; and a live OpenSSL handshake displays a stapled OCSP response for the requested hostname. If any one of those conditions is missing, the browser may still show a valid HTTPS connection while stapling is absent, so rely on the handshake and logs rather than the lock icon alone.

Quick Recap

Bestseller No. 1

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

SaleBestseller No. 2

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

SaleBestseller No. 3

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

SaleBestseller No. 4

Network Security, Firewalls, and VPNs

$66.62

SaleBestseller No. 5

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

Used Book in Good Condition

$48.16

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.