How to Test TLS Certificate Revocation Through a Proxy

A valid signature and trusted certificate chain do not prove that a certificate remains acceptable. A certificate authority may revoke a certificate before its scheduled expiry. Clients can learn that status from a stapled OCSP response, a direct OCSP query, a certificate revocation list or a platform-specific service.

Proxy routes complicate the evidence. An HTTP CONNECT proxy usually transports the destination TLS handshake without terminating it, while an HTTPS proxy presents its own certificate on the client-to-proxy hop. An approved inspection gateway may create another trust boundary. Browsers, command-line tools and operating systems can also apply different revocation policies.

This guide creates a safe acceptance test. Use only certificates, endpoints and proxy infrastructure you own or are explicitly authorized to test. Do not generate traffic against third-party revocation services at high volume.

Draw every TLS boundary

Document the route before testing:

Never treat the proxy certificate and destination certificate as one chain. A successful TLS connection to an HTTPS proxy proves nothing about the certificate received after CONNECT.

Use the HTTPS proxy TLS audit to establish chain, hostname, SNI and trust boundaries before adding revocation cases.

Define the client policy

For every production client, record:

• runtime and version;
• trust store and certificate backend;
• whether revocation checking is enabled;
• whether OCSP stapling is required, optional or ignored;
• whether a failed responder lookup causes a soft or hard failure;
• CRL support and cache behavior;
• network path used for responder access;
• enterprise policy or browser management settings.

Do not assume that two clients using the same proxy behave identically. One may validate stapled status, another may fetch an OCSP responder, and another may apply only platform-level revocation data.

Build controlled certificate fixtures

Create authorized endpoints for these cases:

1. valid certificate with a current good status;
2. valid certificate with a valid stapled response;
3. valid certificate without stapling;
4. revoked test certificate;
5. expired or stale status response;
6. unreachable responder or CRL distribution point;
7. invalid certificate chain as a separate negative control.

Use a private test CA or a provider-supported test environment. Do not weaken verification on production clients. A test that passes only after disabling certificate or hostname checks is a failed test.

Establish a direct baseline

From the same machine and runtime, test every fixture without the proxy under an explicitly approved control path. Capture:

client_version
certificate_fingerprint_hash
issuer_alias
stapled_status_present
stapled_status_age
revocation_policy
validation_result
error_category
dns_ms
connect_ms
tls_ms
total_ms

Do not store private keys, proxy credentials or raw customer hostnames. If the direct baseline does not produce the expected result, fix the fixture or client policy before evaluating a proxy.

Test the proxy and destination separately

For an HTTPS proxy, first validate the gateway certificate and its revocation behavior. Then establish CONNECT and validate the destination certificate inside the tunnel. Record which hop failed.

Run one route at a time with the same client, fixture and policy. Compare:

• certificate fingerprint and chain;
• presence and freshness of a stapled response;
• responder or CRL reachability;
• validation outcome and error category;
• TLS and total duration;
• whether a direct fallback occurred.

If the destination certificate changes unexpectedly through a route that should be a transparent tunnel, stop and investigate. Do not add a new trust anchor merely to make the test pass.

Test responder reachability without leaking traffic

When a client performs direct OCSP or CRL retrieval, determine whether that request follows the required proxy policy. A revocation lookup can become an unintended direct connection, disclose the destination certificate to another network path, or fail because the responder is not in the outbound allowlist.

Use controlled responder hostnames and low request volume. Verify DNS ownership, route, status code, cache behavior and timeout. If policy requires all egress through a proxy, apply the proxy bypass audit to the revocation lookup as well as the application request.

Do not block third-party responders to “test” failure. Use a laboratory responder, controlled DNS or an isolated test network.

Distinguish soft failure from hard failure

An unreachable responder is not the same as an explicit revoked status. Record both outcomes.

• Good: status evidence is current and acceptable.
• Revoked: the certificate must be rejected.
• Unknown: policy determines whether to stop or escalate.
• Responder unavailable: a network failure; client soft-fail or hard-fail policy must be documented.
• Stale evidence: reject or refresh according to the defined freshness rule.

Do not silently convert an explicit revoked result into a retry through another exit. Rotation does not change certificate status and may hide the original evidence.

Check caching and time boundaries

Revocation responses and CRLs have validity intervals. Repeat controlled tests before and after cache expiry. Record this-update and next-update timestamps as age or bounded metadata, not as an excuse to retain complete sensitive handshakes.

Test system-clock skew separately. A client with a wrong clock can reject current evidence or accept stale data. Fix time synchronization rather than broadening validation windows.

Set acceptance gates

A proxy route passes only when:

• proxy and destination TLS boundaries are separately attributable;
• a revoked test certificate is rejected;
• good current evidence succeeds;
• stale, unknown and unreachable cases match documented client policy;
• responder and CRL lookups follow approved egress rules;
• no unapproved direct fallback occurs;
• certificate verification and hostname checks remain enabled;
• result caching refreshes within the defined window;
• logs contain hashes and categories, not credentials or private keys.

Troubleshooting map

The curl IPv6 scope and retry guide helps separate address-selection and retry failures from certificate-revocation behavior.

FAQ

Does OCSP stapling remove all responder traffic?

Not universally. Client policy, missing or stale staples, intermediate certificates and platform behavior can still cause other checks. Measure the actual client.

Does HTTP CONNECT hide revocation status from the client?

Normally the destination TLS handshake remains end to end through the tunnel, so the client can evaluate provided status evidence. Approved TLS inspection creates a different boundary that must be tested explicitly.

Should an unreachable OCSP responder always fail closed?

That is a risk and platform policy decision. Document the intended behavior and distinguish network unavailability from an explicit revoked result. High-risk systems may require stricter policy.

Can changing the proxy exit fix a revoked certificate?

No. An explicit revoked status concerns the certificate. Rotating exits may change reachability but must never override or erase the revocation decision.

Compliance note

Test only systems and certificates you control or are authorized to assess. Respect CA, proxy and network policies. Protect certificate evidence, minimize retention and do not disable verification, intercept unauthorized traffic or use alternate routes to bypass security controls.