SslStream.AuthenticateAsClient() 对于未缓存的 CRL 非常慢
我连接的服务器最近更改了它的 SSL 证书。自更改以来，下载证书吊销列表时，SSL 身份验证需要超过十秒才能完成。
我使用 RemoteCertificateChainCallback 来验证证书，但是延迟发生在调用回调之前，因此不是证书链的构建或任何其他操作导致延迟。
该问题仅在 CRL 未缓存时发生，即我需要删除 CRL 缓存（Documents&settings/[user]AppData/Microsoft/CertificateUrlCache 或类似的）在一天内多次复制它。
如果我在 AuthenticateAsClient() 调用中禁用 CRL 检查，则身份验证会很快。
使用网络嗅探器，我可以看到当最终请求 CRL 时，它几乎立即下载，因此延迟不是网络延迟（至少不是 CRL 服务器的延迟）。
我在网络嗅探器中看到的一件奇怪的事情是，在从服务器检索初始 SSL 证书后，在下载 CRL 之前有五秒的延迟。**
有没有人对在此期间可能发生的情况有任何建议阶段，延迟可能是什么原因造成的？
谢谢！
更新：好的，我已经使用反射器和内存分析器进行了深入研究。作为客户端进行身份验证。看起来大部分时间都花在构建证书链上，即：
if (!CAPISafe.CertGetCertificateChain(hChainEngine, pCertContext, ref pTime, invalidHandle, ref cert_chain_para, dwFlags, IntPtr.Zero, ref ppChainContext))
如果我不请求 CRL 验证，那么在启用 CRL 检查的情况下，它几乎会立即返回，大约需要 4 秒。
我怀疑如果我手动尝试在 RemoteCertificateValidationCallback 中构建链，我会看到相同的延迟。
如果 CRL 已缓存，这实际上不会成为问题，但此缓存似乎不适用于 Windows7 客户。 为什么？好吧，我想这就是下一个任务......
谁能解释一下是什么导致了链条建设花费了这么长时间？
A server I connect to has recently changed it's SSL certificate. Since the change, SSL authentication is taking in excess of ten seconds to complete when the Certificate Revocation List is downloaded.
I'm using the RemoteCertificateChainCallback to validate the certificate, however the delay occurs BEFORE the callback is called, so it's not the building of the cert chain or any other action there that's causing the delay
The issue only occurs when the CRL is NOT CACHED, i.e. I need to delete the CRL cache (Documents&settings/[user]AppData/Microsoft/CertificateUrlCache or something similar) to repro it more than once on a single day.
If I disable CRL checking in the AuthenticateAsClient() call, the authentication is quick.
Using a network sniffer, I can see that when the CRL is eventually requested, it downloads almost instantaneously, so the delay is not a network latency one (at least not to the CRL server).
One odd thing that I see with the network sniffer is that after the initial SSL certificate retrieval from the server, there is a five second delay until the CRL is downloaded.**
Has anyone got any suggestions as to what may be going on during this stage, and what the delay may be caused by?
Thanks!
UPDATE: OK, I've used reflector and a memory profiler to delve into. AuthenticateAsClient. It looks like most of the time is spent building the certificate chain, i.e.:
if (!CAPISafe.CertGetCertificateChain(hChainEngine, pCertContext, ref pTime, invalidHandle, ref cert_chain_para, dwFlags, IntPtr.Zero, ref ppChainContext))
If I don't request CRL validation, then this returns almost instantaneously, with CRL-checking enabled, about 4 seconds.
I suspect I'll see the same delay if I manually attempt to build the chain in my RemoteCertificateValidationCallback.
This wouldn't really be a problem if the CRL was cached, however it seems like this caching is not working on a Windows7 customer. Why?? Well I guess that's the next task...
Could anyone explain what could be causing the chain-building to take so long?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
似乎这是这个问题的答案：
https://blogs.msdn.microsoft.com/alejacma/2011/09/27/big-delay-when-calling-sslstream-authenticateasclient/
It seems that here is an answer for this question:
https://blogs.msdn.microsoft.com/alejacma/2011/09/27/big-delay-when-calling-sslstream-authenticateasclient/