建立 SSLTLS 连接 (X509Chain.Build()) 需要很长时间

本文关键字：长时间 Build SSLTLS 连接 X509Chain 建立 | 更新日期: 2023-09-27 18:35:03

我发现当我使用 HttpWebRequest 建立 SSL''TLS 连接时，调用时需要将近 30 秒

  request.GetRequestStream()

当我在启用堆栈跟踪的情况下启用跟踪时，我发现 2s 会查找 poxy，所以我在 app.config 中禁用了它：

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

下一个需要接近 28 秒的点是在

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

在检查方法主体后，我发现了对 X509Chain.Build(( 的调用，构建证书链花了将近 25 秒的时间。

有趣的是，当您构建新的 HttpWebReqest 并再次尝试(没有应用程序重启(时，执行请求需要几个小时。

谁能建议该怎么做？缓存请求不是一种选择，它应该在应用程序运行时很快。

更新：

我发现在 X509Chain.BuildChain(( 中需要 30 秒的调用是：

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

在 CAPISafe 中声明的方法为：

[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);

所以，它是加密API函数CertGetCertificateChain。仍然不知道，下一步该怎么办...

更新：

我尝试禁用 CRL 和 OCSP 检查，但仍然没有效果：

  1. 添加到应用配置

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

  2. 机器范围：控制面板 -> 互联网选项 ->高级 -> 在安全下，取消选中检查发布者的证书吊销选项

  3. 在注册表中：

    [HKEY_USERS''S-1-5-20''Software''Microsoft''Windows''CurrentVersion''WinTrust''Trust Providers''Software Publishing]"状态"=dword：00023e00

建立 SSLTLS 连接 (X509Chain.Build()) 需要很长时间

最后我找到了问题的根源。我在事件日志中启用了 CAPI2 日志记录，并在尝试从以下位置下载证书信任列表时发现 NetworkTimeoutException：

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

所以，这就是防火墙问题。您可以阅读有关调查过程和所用技术的博客文章。

通常，路径构建意味着构建有效的路径，这需要检查自颁发以来是否有任何证书被吊销。

为了检查当前的吊销状态，您需要来自 CRL 或 OCSP 响应程序的最新信息。如果在设置路径验证请求期间未显式提供正确的 CRL，则在"CRL 分发点"扩展中列出了 CRL 的 URL 时，许多库将尝试提取它(通常通过 Internet(。

如果网络速度较慢、路径较长或 CRL 较大，这可能需要一些时间。也许这就是你的情况下需要这么长时间的原因。由于它在第一次后运行速度很快，我猜在第一次尝试期间会下载一些大型 CRL 并缓存以供后续使用。

或者，如果图书馆在"权威信息访问"扩展中播发，则图书馆可能会自动联系 OCSP 响应程序。但是，某些库需要显式配置才能使用 OCSP，或者首选它而不是 CRL。

如果要验证来自许多不同颁发者中每个颁发者的几个证书证书，请尝试在可用的位置使用 OCSP。该协议速度快，响应很小，通常包含有关单个证书的信息，而不是颁发者曾经吊销的每个证书。

如果要验证来自单个颁发者的多个证书，请急切地在后台下载该颁发者的 CRL，并保留它直到过期。然后将 CRL 传递到路径构建过程中，以便在用户等待时不必下载它。

相关文章：