Certificate Revocation List (CRL) Check and WinHttp Proxy settings

Starting with Windows XP SP2, the Crypto API CRL check uses WinHttp (see: http://support.microsoft.com/kb/887196).  This can cause some confusion with network administrators and developers since they might have set proxy information for WinInet or applications using CryptoAPIs but the certificate validation fails for the https calls inside certain networks.

To allow the CRL check out to the cloud, the CLR code using WinHttp needs to be able to make it through your proxy!  WinHttp can ONLY perform Automatic Proxy Detection using WPAD or use a static proxy.  If you network supports WPAD (which is recommended) then you should not have a problem.  If machines are using a static proxy, then you must set the same static proxy for WinHttp on that machine or the CRL check will fail.  If you have a static pac file configured, then this will fail since WinHttp cannot use a static Pac file (use WPAD to provide the PAC file instead).

Another option is to allow direct connection through your proxy or firewall by configuring a rule to allow the User-Agent header that the CRL check uses to pass through.  That header is currently: User-Agent: Microsoft-CryptoAPI/6.0

If you refuse to use WPAD then you can set a static proxy for WinHttp settings that will in turn be used by the Crypto API CRL check.  Depending on the version of the OS you are running you will use netsh or winhttpcfg.exe to set the static proxy.  You cannot set this value programmatically inside of your program for just that particular instance or process however.  The setting for the proxy in this case is a system wide setting and not per process.

More information:

How Certificate Revocation Works - http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx

Summary of CryptoAPI changes: http://support.microsoft.com/kb/887195 and http://support.microsoft.com/kb/887196


Please Drop me a note if you found this helpful!

Comments (4)

  1. Vijay R says:

    I have an app that validates certificates and it fails because authrootstl.cab cannot be downloaded from the Internet (I see CAPI errors for this in the event log). If i use netsh and set the proxy then it works.

    You have mentioned that this proxy cannot be set programatically, which is a shame because I'll now need to ask my customers to use netsh which is increased support costs for us.

    Is there really no way to set this proxy?

    Your article was very useful!

  2. Jeff Sanders says:

    Thanks Vijay,

    Most customers will never have to manually set the proxy this way.  By far the most common and maintenance free way to configure a network is using WPAD.  If this is set then autodetection of the proxy happens for all HTTP clients in their network.  I know that does not help you much however :-(.

    You certainly COULD set this programatically for the entire machine (shell out to set it) but I would be an angry customer if someone's software did this blindly to my machine.  Perhaps a prompt during installation to set this would be a good way for you to handle this.  For example, during setup, try and make a WinHttp call to a well know URL (Your company website).  If there is a problem, then have then use netsh or winhttpcfg to set the proxy and retest.  I hope this helps!

  3. Greg Mangino says:

    What is recommended when it is the machine account (SYSTEM) doing the CRL check?   How does it authenticate?   what is best practice there?

  4. Jeff Sanders says:

    Best practice for a system account it to use wpad (it just works).

    If your network team is hard headed you can use RunAs and run under system to set the WinHttp proxy as you would for the currently logged on user account.

Skip to main content