简体繁体 English

客户端证书不是由.Net App使用TLS1.2发送的

[英]Client certificate is not sent by .Net App using TLS1.2

原文 2017-05-31 08:44:43 4 1 c#/ asp.net/ ssl/ encryption

I'm having a .NET C# application which connects to a remote soap web service using 2-way SSL (client certificate) to authenticate. 我有一个.NET C＃应用程序，该应用程序使用2-way SSL（客户端证书）进行身份验证，连接到远程soap Web服务。 The application is running on IIS 7.5 on a Windows Server 2008 R2 system. 该应用程序在Windows Server 2008 R2系统上的IIS 7.5上运行。 Internet Explorer 11 is installed. 已安装Internet Explorer 11。

Since the following registry key was set by our IT department the remote server returns an error stating that our client does not present a certificate. 由于以下注册表项是由我们的IT部门设置的，因此远程服务器会返回一条错误消息，指出我们的客户端未提供证书。 HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\.NETFramework\\v4.0.30319 "SchUseStrongCrypto"=dword:00000001 HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ .NETFramework \\ v4.0.30319“ SchUseStrongCrypto” = dword：00000001

IE has the same problem until I disable TLSv1.2 in the advances properties. 直到我在Advances属性中禁用TLSv1.2之前，IE都存在相同的问题。 Firefox and Chrome both work. Firefox和Chrome均可使用。

The remote server-preferred order of suites is configured as follows: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) 套件的远程服务器优选顺序配置如下：TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256（0xc027）TLS_RSA_WITH_AES_128_GCM_SHA256（为0x9c）TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384（0xc030）TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384（0xc028）TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA（0xc014）

I made a wireshark trace to see what cipher suites the browsers and the .NET app negotiate with the server. 我进行了wireshark跟踪，以查看浏览器和.NET应用程序与服务器进行协商的密码套件。 It looks like the .NET app and also IE with TLSv1.2 activated negotiate TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, while firefox and chrome negotiate TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. 看起来像.NET应用程序，还激活TLSv1.2的IE协商TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256，而Firefox和Chrome协商TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384。

Does anyone has an idea why the 2-way ssl handshake works with the suite firefox and chrome uses but not with the suite IE and the .Net app uses. 有谁知道为什么2向ssl握手可以与套件Firefox和chrome一起使用，却不能与套件IE和.Net应用程序一起使用。

Could this be an issue on the remote server configuration or is it more likely that its a Windows/.Net Framework issue? 这是远程服务器配置上的问题，还是Windows / .Net Framework问题？

Why does IE and .Net Framework not respect the server preferred order? 为什么IE和.Net Framework不遵守服务器的首选顺序？

Thank you very much in advance. 提前非常感谢您。

-Willey -威利

1 个解决方案

According to your description I would guess that there is a problem during the TLS 1.2 handshake. 根据您的描述，我猜想在TLS 1.2握手期间存在问题。 A possible reason could be that at least one of the certs in the cert chain uses Md5 as it's hash algorithm. 可能的原因可能是证书链中的至少一个证书使用Md5作为其哈希算法。

If this is the case, you need to exchange that certificate by another one using an accepted hash algorithm. 在这种情况下，您需要使用公认的哈希算法来交换另一个证书。

Check the following links for further explanation: 检查以下链接以获取更多说明：