WinHTTP over an HTTPS forward proxy - CRL problem

Thanks you for the reply @Taki Ly (WICLOUD CORPORATION)

We did try bypassing "*.lencr.org" but the WinHttp still produced the same error/behavior.

We also tried the following:

Prerequisites (must already be set in HKCU)

The proxy must be configured and enabled for the current user, i.e. these keys

under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings are expected:

• ProxyEnable = 1 (REG_DWORD)
• ProxyServer = https://mysecureproxy.duckdns.org:3129 (REG_SZ)

1. Download the leaf cert from the proxy

$c=New-Object Net.Sockets.TcpClient('mysecureproxy.duckdns.org',3129);$s=New-Object Net.Security.SslStream($c.GetStream(),$false,{$true});$s.AuthenticateAsClient('mysecureproxy.duckdns.org');[IO.File]::WriteAllBytes("$PWD\proxyleaf.cer",$s.RemoteCertificate.Export('Cert'));$s.Close();$c.Close()

2. Clear the cryptnet URL cache

certutil -urlcache * delete

3. Validate WITHOUT the bypass → expected to FAIL

certutil -verify -urlfetch proxyleaf.cer

Fails:

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

------------------------------------

Revocation check skipped -- server offline

Cert is an End Entity certificate

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

4. Add the bypass to HKCU, clear cache, re-run → expected to PASS

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyOverride /t REG_SZ /d "*.lencr.org" /f

certutil -urlcache * delete

certutil -verify -urlfetch proxyleaf.cer

Now the CRL is fetched direct (bypassing the proxy):

Leaf certificate revocation check passed

CertUtil: -verify command completed successfully.

Hi @Izaf ,

Thank you for the detailed follow-up and the certutil steps, they are very helpful.

That result is consistent with something I was able to observe when reproducing this. The certutil -verify -urlfetch path uses the WinINET proxy configuration, so a ProxyOverride entry in HKCU lets it fetch the CRL directly and the check passes. WinHTTP, on the other hand, appears to perform the proxy certificate's revocation retrieval through the proxy configured on the WinHTTP session itself, rather than through the WinINET/HKCU settings, so the HKCU ProxyOverride does not influence it.

To reproduce the distinction I pointed the proxy certificate's CDP at a directly reachable host that is separate from the proxy, served a valid CRL there, and kept the proxy as CONNECT-only so a proxy-routed CRL fetch would fail while a direct one would succeed. With the WinHTTP session using a named proxy and no bypass, the request failed with 12188 and the CRL host received no request at all, which indicates the CRL retrieval went to the session proxy rather than direct. Setting a WinHTTP session bypass (lpszProxyBypass) for the CRL host did not change that outcome in my test either.

What did work reliably was pre-seeding the CRL into the CryptoAPI URL cache. Once the proxy certificate's CRL was present in the cache (for example after fetching it directly with certutil), the same WinHTTP request succeeded with HTTP 200, because the revocation check was satisfied from cache and no network retrieval was attempted. Clearing the cache returned the behavior to 12188. So the deciding factor is whether the proxy certificate's CRL is already available locally when WinHTTP validates the proxy certificate.

Given that, the most dependable approach is to make sure the CRL is present without depending on a fetch through the proxy. Pre-seeding or periodically refreshing the CRL into the machine CRL cache (or distributing it via Group Policy) avoids the loop, since no live retrieval is needed. Using a proxy certificate whose revocation endpoint can be reached without the proxy, or relaxing the revocation policy for that certificate path at the Schannel level, are alternatives depending on your constraints.

Thanks again — this matches exactly what we found. We confirmed the pre-seeding approach: once the proxy certificate's CRL is present in the CryptoAPI URL cache (e.g. fetched directly with certutil -verify -urlfetch while the CRL host is reachable off-proxy), the revocation check is satisfied from cache, no live retrieval is attempted, and both certutil and our WinHTTP client succeed (HTTP 200). Clearing the cache brings the failure back to 12188, so the cached CRL is indeed the deciding factor.

Hi @Izaf ,

Thanks for confirming, glad the pre-seeding approach lines up on your side as well, for both certutil and the WinHTTP client.

One practical note to keep in mind going forward: a CRL has a validity window (thisUpdate / nextUpdate), and once the cached copy passes its nextUpdate, CryptoAPI will try to refresh it, which would route back through the proxy and reintroduce the same loop. To avoid that, it helps to refresh the CRL in the cache on a schedule, off-proxy, before it expires, for example a periodic certutil -verify -urlfetch (or a direct fetch of the CRL URL) run while the CRL host is reachable without the proxy. Aligning that refresh interval with the CRL's nextUpdate cadence keeps the cache continuously warm.

If the proxy certificate is later reissued with a different CRL distribution point, you would just want the refresh job to pick up the new URL as well.

Glad this is working now, and thanks for sharing your findings back, they make the thread a useful reference for the same scenario.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Thanks for looking into it again @Taki Ly (WICLOUD CORPORATION) !