我们在Windows Server 2008 R2服务器上的注册表中启用了SchUseStrongCrypto。在更改之后，我们注意到使用.NET HttpClient创建的另一个第三方服务器的HTTP请求不再起作用。注册表更改将使用的协议从TLS 1.0更改为TLS 1.2。 Schannel将以下错误记录到系统事件日志中：“生成以下致命警报：40。内部错误状态为252.”
使用Wireshark的一些研究揭示了一种与this blog post中概述的情况非常类似的情况：我们的服务器在收到远程服务器证书后发送了一个TCP RST，大概是因为远程服务器发送的根证书使用MD5作为我们的ClientHello中列出了其哈希算法和使用MD5的签名算法。通过在注册表中禁用TLS 1.2（signature_algorithms扩展特定于TLS 1.2），我们能够强制通过TLS 1.1进行连接，并且eveything工作愉快。
但是，有几个方面的情况我不明白。在启用了SchUseStrongCrypto的Windows Server 2016 Technical Preview 2服务器上运行相同的应用程序时，尽管在ClientHello中发送了相同的签名算法，但是使用TLS 1.2进行连接很好，尽管顺序不同。两台服务器都安装了.NET 4.6，应用程序的目标是4.6。
为什么连接在一台服务器而不是另一台服务器上工作，尽管他们都说他们不接受MD5证书？此外，Wireshark透露，在2008 R2服务器上，Internet Explorer 11（不受.NET SchUseStrongCrypto标志管理，但使用Schannel）也无法建立初始TLS 1.2连接，但是它不发送RST而是发送FIN然后尝试并成功建立TLS 1.0连接（在2016服务器上IE11成功使用TLS 1.2） - 什么控制HttpClient是否/如何执行相同的回退？最后，如何指定和排序签名算法（例如，您可以在gpedit.msc中选择和订购密码套件），以及当客户端收到的证书与其所说的任何签名算法都不匹配时，应该采取什么行为？愿意用？
远程服务器上的SSL实验室报告显示除了IE 6（正如预期）之外的所有内容都与它成功协商，Windows 8.1+和OS X平台使用TLS 1.2。我在报告中注意到的另一件事是远程服务器的证书链实际上包括两个自签名证书，其中更近端使用SHA1而不是MD5，因此有两个“路径”。第一个路径报告为“受信任”，因为第一个自签名证书是“在信任存储区”;第二个是“不信任”，因为有问题的MD5证书是链中的最终根，“不在信任存储中”。这意味着其他HTTP客户端（如SSL Labs测试的浏览器）使用第一个路径并忽略MD5证书。
最终，这似乎是由于两个版本的Windows（可能在Schannel）之间存在一些根本区别，但这种差异是在任何地方记录或配置的吗？