.NET 4是否更改了TLS中应答证书请求帧的方式(Did .NET 4 change how the Certificate Request frame is answered in TLS)

.NET 4是否更改了TLS中应答证书请求帧的方式(Did .NET 4 change how the Certificate Request frame is answered in TLS)

我正在连接到Win2008（IIS7）中托管的Web服务，该服务需要基于证书的相互身份验证。 当运行在.NET 2.0运行时的客户端调用该服务时，操作将失败，并显示403.如果我在wireshark中检查请求，我看到客户端正在响应带有证书框架的证书请求框架，但没有证书是在该框架中指定。 查看服务器在证书申请中提供的CA证书列表，不存在客户端证书使用的CA. 这似乎是有道理的，因为如果服务不信任它，发送证书的重点是什么。 但是，当我使用针对.NET 4.0运行时重新编译的工具进行相同的调用时，行为是不同的。 客户端的证书框架确实包含它配置使用的证书。 我在MSDN上看到对SslStream进行了更改，这就是我遇到的问题吗？ 令人不安的是，不同的运行时版本对同一服务端点的行为不同。

I am connecting to a web service that is hosted in Win2008 (IIS7) requiring certificate based mutual authentication. When the service is called by a client running on the .NET 2.0 runtime, the operation fails with a 403. If I examine the request in wireshark I see that the client is responding to the Certificate Request frame with a Certificate frame but no certificate is specified in that frame. Looking at the list of CA certificates provided by the server in Certificate Request the CA used by the client's certificate is not present. This seem to make sense as what is the point of sending a cert if the service will not trust it. However, when I make this same call using the tool recompiled against the .NET 4.0 runtime the behavior is different. The client's Certificate frame does contain the certificate it was configured to use. I saw on the MSDN that changes were made to SslStream so is this what I am running into? It is rather unsettling that different runtime versions act differently for the same service endpoint.

最满意答案

是的，运行时的两个版本之间的行为确实发生了变化。 细微变化是客户端如何处理证书请求框架。 我们遇到的问题是，由于根证书更新问题，服务器在其受信任的根存储中有太多CA. 这导致在证书请求帧的证书数组中返回可信CA的子集。 由于返回列表CA是适当的子集，因此它包括在某些请求中而不是在其他请求中签署客户端证书的根。 .NET 2.0客户端通过不包括服务器提供的受信任权限集之外的证书来正确地遵守TLS规范。 .NET 4.0客户端尊重它的配置方式，并提供通过WCF配置指定的客户端证书。

Yes the behavior did change between the two versions of the runtime. The nuanced change was in how the client processed the Certificate Request frame. The issue that we experienced was that the server had too many CAs in its trusted root store due to a bad root certificate update issue. This caused a subset of trusted CAs to be returned in the certificates array of the Certificate Request Frame. As the list of returns CAs was a proper subset, it included the root that signed the client certificate in some requests and not in others. The .NET 2.0 client properly honored the TLS spec by not including a certificate which was outside of the set of trusted authorities provided by the server. The .NET 4.0 client honored how it was configured and provided the client certificate that was specified via the WCF configuration.