Tracing Proxy Failures in CRL and OCSP Certificate Checks
Trace CRL or OCSP retrieval under the verifier’s account when the application reaches its proxy but certificate validation cannot finish.
A website request can reach its proxy and still fail because certificate verification needs another network request. A CRL or OCSP fetch may run through a platform component with a different account and proxy policy from the application's HTTP client.
Start with the exact chain error. Revoked means something different from unable to obtain current revocation information. Expiry and an untrusted issuer are different problems again. Only the retrieval failure calls for tracing a missing route to a status URL.
For that failure, identify three things together: the URL being fetched, the component doing the fetch and its process identity. A browser opening the URL successfully under your interactive account does not prove a service can authenticate to the same proxy.
If the identified component uses WinHTTP, examine the policy applicable to it. Static proxy configuration and per-URL automatic proxy evaluation are separate mechanisms. Apply the supported configuration for the intended account; copying browser settings or changing an unrelated runtime may leave the actual fetch untouched.
In .NET, UrlRetrievalTimeout on the chain policy controls a wait for online verification or CRL retrieval. Extending the ordinary HTTP response timeout does not extend that same timer, and extending the retrieval timer does not supply proxy credentials or a route.
An HTTPS proxy can make this dependency visible even before destination TLS: trust in the proxy connection may itself require revocation retrieval. Restore the supported retrieval access and trust arrangement at that stage. Disabling revocation checking changes the certificate policy; it does not restore the failed fetch.