When ssl_stapling_verify on is enabled in Nginx, the server performs rigorous validation of OCSP (Online Certificate Status Protocol) responses. This goes beyond just checking the response signature - it establishes a complete chain of trust verification similar to how browsers validate certificates.

server {
    listen 443 ssl;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /path/to/trusted_ca_cert.pem;
    # Other SSL configurations...
}

The verification process includes these crucial checks:

• Signature validation: The OCSP response must be properly signed by a trusted Certificate Authority
• Response freshness: The response must be recent (within its validity period)
• Chain of trust: The responder's certificate must chain back to a trusted root
• Certificate status: The response must not indicate the certificate is revoked

For proper verification, you must configure:

ssl_trusted_certificate /etc/nginx/ssl/trusted-ca-bundle.pem;
# This should contain:
# - Your root CA certificate
# - All intermediate CA certificates
# - The OCSP responder's certificate

Debug verification failures with:

openssl ocsp -issuer intermediate.pem -cert server.crt \
    -url http://ocsp.example.com -respout ocsp.resp

openssl ocsp -respin ocsp.resp -text -verify_other trusted.pem

Common problems include missing intermediate certificates in the trusted chain or OCSP responder certificates not being properly configured in the trusted store.

While enabling verification adds overhead, it's critical for security. For high-traffic sites, consider:

• Caching verified responses
• Using a local OCSP responder
• Monitoring verification latency

When ssl_stapling_verify on is configured in nginx, the server performs multiple cryptographic validations on received OCSP responses:

1. Digital Signature Verification: Validates the OCSP response was signed by a trusted CA (or designated OCSP responder) using the certificates specified in ssl_trusted_certificate
2. Response Freshness Check: Ensures the nextUpdate field hasn't expired (typically within 3-7 days window)
3. Certificate Status Verification: Confirms the response actually corresponds to the server's certificate

Here's a production-ready configuration demonstrating proper stapling verification:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/trusted-ca-bundle.pem;

# For Let's Encrypt specifically:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

When verification fails, check these common issues:

• Incomplete CA Chain: Your ssl_trusted_certificate file must contain the full chain including intermediate certificates
• Time Synchronization: OCSP responses have strict validity windows - ensure server time is accurate
• Network Restrictions: Some firewalls block OCSP requests on TCP port 80

Here's what happens during a TLS handshake with stapling:

1. Client connects and requests certificate status via OCSP stapling
2. nginx checks its cached OCSP response
3. The response is validated against the trusted CA bundle
4. Only after successful verification is the stapled response sent to the client

While verification adds minimal overhead (typically <5ms), consider:

• OCSP responses are cached for their validity period
• Verification occurs only when fetching new responses, not every connection
• Hardware-accelerated crypto (via OpenSSL engine) can optimize this further