我怀疑构建 CRL 缓存的过程可能会导致某些应用程序延迟。
我们有几个 .NET 应用程序偶尔会“运行缓慢”，没有 CPU 或磁盘访问。我怀疑它们在尝试验证证书时因身份验证而挂起，因为超时时间几乎为 20 秒。
按照这篇微软文章
大多数应用程序不会指定 CryptoAPI 使用累积超时。如果未启用累积超时选项，CryptoAPI 将使用 CryptoAPI 默认设置，即每个 URL 的超时时间为 15 秒。如果应用程序指定了累积超时选项，则 CryptoAPI 将使用默认设置 20 秒作为累积超时。第一个 URL 的最大超时时间为 10 秒。每个后续 URL 的超时时间都是累积超时值中剩余时间的一半。
由于这是一项服务，我如何检测和记录我拥有源代码的应用程序以及第三方的 CryptoAPI 挂起
答案1
获取更多信息的一种方法是启用 CAPI2 事件日志
- 打开 Eventvwr -> 应用程序和服务日志 ->
- Microsoft -> Windows -> CAPI2 -> 操作 ->
- 右键点击启用日志
事件日志中显示的信息将有助于确定证书验证过程在哪里花费了较长的时间。
启用日志记录
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
将日志保存到文件
wevtutil.exe epl Microsoft-Windows-CAPI2/Operational filename.elf
禁用日志记录
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false
清除日志
wevtutil.exe cl Microsoft-Windows-CAPI2/Operational
答案2
我为您提供了几种不同的选择，因为对潜在的 PKI 进行故障排除可能是一个复杂的问题。
CRL 是缓慢而笨重的怪物......
首先，我要告诉你，CRL 超时导致世界上最大的 PKI 不使用 CRL 来满足绝大多数 PKI 验证需求。当用户在发送加密电子邮件之前只需要简单的“是”或“否”时，下载 50MB 的文件是行不通的！
如何进行验证
1 - 您可以使用第三方验证客户端（例如 Tumbleweed 或其他客户端）测试替代的 Microsoft 本机验证客户端，然后监控第三方验证客户端（作为控制）。Tumbleweed/Axways 销售并提供流行的第三方验证客户端、OCSP 中继器和响应器的试用版。您还可以使用 OpenSSL、ejbca 或 OpenCA 作为验证响应器。此外，还有一个 OSS 框架 PKIF，其中包括特定的 CAPI 日志记录功能和位于的 OCSP 客户端http://pkif.sourceforge.net/
2 - 您可以控制验证数据源（CRL，OCSP，SCVP）。
3 - 另一个问题来源可能是 DNS 解析速度慢、缺少 DNS 缓存、PKI 配置错误、缺少信任或刷新 CRL 所需的时间（如果 PKI 较大则会导致暂时挂起）。
您能否分享有关应用程序配置、PKI 本身、x509 证书字段、带宽等的更多详细信息。特别是，我对与验证相关的字段感兴趣，例如权威信息访问 (AIA) 字段，以及任何对 CRL 或 OCSP 的硬编码引用。
请记住，响应类型中也存在众所周知的歧义。专门针对 OCSP 的 RFC 存在问题，因为对于验证不了解的证书，良好响应和未知响应同样有效。
关于替代方案的讨论：
进行证书验证主要有两种方法：白名单和黑名单。
黑名单协议包括 CRL、OCSP 和 SCVP，以及 OCSP 的变体。
可以使用 OCSP 与 CA DB、CTL* 和 SCVP 接口在 Windows 上执行白名单。
在大多数情况下，白名单方法被认为是比黑名单方法更优越、更安全、更快速、更实时和更好的替代方案。
答案3
值得一提的是，有一个修补程序可能无法解决特定问题，但包含更新的 cryptnet.dll 来解决 OCSP 问题。此特定文件在 SP1 中也没有更新。
您不能使用基于证书的登录方法对运行 Windows Server 2008 R2 的计算机上的请求进行身份验证