Alex Rivera | Logout

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

Asked 2012-05-23T16:17:59.213
8

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 CertGetCertificate

c# .net ssl system.net.httpwebrequest
Edit
Report

1 Answer

4

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

answered 2012-05-23T16:49:19.713

Your Answer