Article ID: 2623724 - View products that this article applies to.
Consider the following scenario. Your application uses the WinINet API, WinHTTP API or the System.Net.HttpWebRequest class of the .NET framework to send a HTTP request over SSL/ TLS. During SSL/TLS secure channel negotiation, the server sends back a Server Hello message to the Client with its Server Certificate to prove its identity to the client. When doing so, the server certificate information can also contain a list of Certificate Revocation List (CRL) distribution points. These CRL distribution points list contains a URL from where the client can download the CRL and can verify whether the server certificate has been revoked by the publisher of the certificate.
The purpose of this article is to explain how the Crypto API tries to find a route by which it can successfully download a HTTP based CRL distribution point URL. This article is meant to help in troubleshooting scenarios related to network retrieval of CRLs. For additional details, please reference the white paper: “Troubleshooting PKI Problems on Windows Vista” in the More Information section below.
The Crypto API internally uses the WinHTTP API to download the HTTP based URL for the CRL distribution point. Before downloading the URL, WinHTTP needs to know a route to reach the CRL URL. In situations where the environment has a proxy server, WinHTTP can either automatically detect the Proxy server or it can be asked by the application consuming the WinHTTP API to use a specific proxy to download the CRL.
The Crypto API internally tries to find a Proxy server first using the below logic, and if it finds any proxy server address it asks WinHTTP to use that specific proxy instance.
If the proxy instance is not reachable or is incorrect, WinHTTP will not be able to download the CRL, the certificate revocation check will fail, and your application will receive an error from the Crypto API indicating the revocation failure. It can report the same error to the user, and depending on the implementation the secure channel establishment can fail.
When trying to discover the proxy, the Crypto API uses the following logic:
1.) It checks if there are any static proxy settings configured on the machine from where the CRL check is being done. Typically this configuration is done using the netsh utility to set the proxy manually on Windows Vista, Windows 2008, Windows 7 or Windows 2008 R2. If a static proxy is found, then the Crypto API uses the statically discovered proxy to download the CRL through WinHttp. For additional details on netsh, please reference the article "Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)" in the More Information section below.
NOTE: This check is only performed on Windows Vista, Windows 2008, Windows 7 and Windows 2008 R2. On Windows 2003, Crypto API does not check static proxy settings.
2.) If a statically configured proxy is not found, the Crypto API tries to retrieve the Internet Explorer proxy settings for the user context under which the Crypto API is executing.
Depending on what your process is running as, this can be either the identity of the currently logged on user, or it can by any specific user or it can be any of the system provided accounts - LOCAL SYSTEM, NETWORK SERVICE, LOCAL SERVICE. The following registry locations are queried based on the executing identity:
Depending on the registry information, the proxy settings for that user will be returned. If the proxy settings are absent, no information will be returned. If the proxy settings are returned it can contain a combination of the below options:
i.) Automatically detect settings
ii.) Use automatic configuration script
iii.) Proxy server
Note: In situations where the process is running as a different identity than the currently logged-on user, there may be an inconsistency in the proxy settings depending on how the proxy settings were configured for that user. In such cases, you may observe that browsing to the CRL location using Internet Explorer as the current user successfully downloads the CRL, but the same process fails when used from the Crypto API which is executing as another user. In such situations it is highly recommend that you check the Internet Settings of all users and make sure that they are consistent.
The Internet Settings should ideally not be present for any non-interactive users such as NETWORK SERVICE, LOCAL SYSTEM or LOCAL SERVICE, since there will never be a need to open up Internet Explorer with those identities. In such cases, you need to ensure that these non-interactive users do not have any proxy settings configured for Internet Explorer, or make sure that they are consistent with the proxy settings for the user with which the CRL download succeeds using Internet Explorer.
3.) If the Internet Explorer proxy settings are not present for the executing user or if the Internet Explorer settings for the process identity indicate "Automatically detect settings" or "Use automatic configuration script", the Crypto API will try to automatically discover a proxy for the CRL in question. This will either return specific proxy information or return 'no proxy' if the automatic proxy discovery fails or if the URL does not require a proxy.
The Crypto API will attempt to use the WinHTTP API to download the CRL URL using the discovered proxy (or no proxy if the proxy could not be discovered or if the URL does not require a proxy).
If the proxy is unreachable or if the proxy information is wrong, the fetch of the CRL URL will fail. The Crypto API will then report this error to the calling API, and depending on the implementation, the caller of the Crypto API can then decide whether to abort the request or let it through.
Note: In cases where the application itself is consuming the WinHTTP API and has set the proxy information either in the WinHttpOpen call or WinHttpSetOption call, the Crypto API does not have access to the Proxy information that the application has set and will still try to discover the proxy information as above. The usage of the WinHttp API from the Crypto API and from your own application are independent and do not share any information with each other.
For more information, please see the following resources:
Troubleshooting PKI Problems on Windows Vista
Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)
Windows HTTP Services
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.