Establishing SSL\TLS connection (X509Chain.Build()) takes too long

Question

I found that when I use HttpWebRequest to establish SSL\TLS connection, it takes near 30s when calling

  request.GetRequestStream()

when I've enabled tracing with stacktrace enabled, I found that 2s goes to find poxy, so I've disabled it in app.config:

<system.net>
 <defaultProxy enabled="false" useDefaultCredentials="false">
  <proxy/>
  <bypasslist/>
  <module/>
 </defaultProxy>
</system.net>

Next point that takes near 28s was in

   at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)

After examinig method body I found call to X509Chain.Build() and it took near 25s to build certificate chain.

Interesting thing that when you constructs new HttpWebReqest and tries again (without app restart), it took several ms to perform request.

Could anyone suggest what to do? Caching request is not an option, it should be fast from app run.

Update:

I found call that takes 30s in the X509Chain.BuildChain(), it is:

if (!CAPISafe.CertGetCertificateChain(hChainEngine, pCertContext, ref pTime, invalidHandle, ref cert_chain_para, dwFlags, IntPtr.Zero, ref ppChainContext))

The method declared in CAPISafe as:

[DllImport("crypt32.dll", CharSet = CharSet.Auto, SetLastError = true)]
internal static extern bool CertGetCertificateChain([In] IntPtr hChainEngine, [In] SafeCertContextHandle pCertContext, [In] ref System.Runtime.InteropServices.ComTypes.FILETIME pTime, [In] SafeCertStoreHandle hAdditionalStore, [In] ref CAPIBase.CERT_CHAIN_PARA pChainPara, [In] uint dwFlags, [In] IntPtr pvReserved, [In, Out] ref SafeCertChainHandle ppChainContext);

So, it is Crypto API function CertGetCertificateChain Still have no idea, what to do next...

Update:

I have tried to disable CRL and OCSP checks, still no effect:

1. Add to App.config

   <runtime>
     <generatePublisherEvidence enabled="false"/>
   </runtime>
   

2. Machine-wide: Control Panel -> Internet Options -> Advanced -> Under security, uncheck the Check for publisher's certificate revocation option

3. In registry:

   [HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing] "State"=dword:00023e00

Answer 1

Finally I found the roots of the issue. I enabled CAPI2 logging in Event Log and found NetworkTimeoutException when trying to download Certificate Trust List from:

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

So, that was Firewall issue. You can read blogpost about investigation process and techniques used.

Answer 2

Normally, path building implies building a valid path, and that requires a check to see whether any of the certificates have been revoked since they were issued.

In order to check the current revocation status, you need up-to-date information from a CRL or an OCSP responder. If the correct CRL isn't provided explicitly during the setup of the path validation request, many libraries will attempt to fetch it (usually over the Internet) if a URL for the CRL is listed in the "CRL Distribution Points" extension.

This can take some time if your network is slow, the path is long, or the CRLs are large. Perhaps this is what is taking so long in your case. Since it runs fast after the first time, I'm guessing that some large CRLs are downloaded during the first attempt and cached for subsequent use.

Alternatively, the library might automatically contact an OCSP responder if it is advertised in the "Authority Information Access" extension. However, some libraries require explicit configuration to use OCSP, or to prefer it over CRLs.

If you are validating a few certificates certificates from each of many different issuers, try to use OCSP where ever it is available. The protocol is fast, and the responses are small, often containing information about a single certificate instead of every certificate the issuer has ever revoked.

If you are validating many certificates from a single issuer, eagerly download that issuer's CRL in the background and keep it around until it expires. Then pass the CRL into the path-building process so that it doesn't have to be downloaded while the user waits.