（如果您想知道为什么我要启用不推荐使用的密码套件，最简单的答案是，对于less数人来说，由于它们卡在Windows Server 2003上，所以不能使用任何更新的东西，他们可以做任何事情，我们不希望我们提供的服务停止工作，如果我们可以帮助它。）
我已经使用IIS Crypto来启用一些协议，密码，哈希，密钥交换和密码套件（ 这里是一个完整的列表 ），应该包括我们的产品通过TLS 1.0连接到这个服务器的必要条件，考虑到Schannel在Windows Server中的function（由于IIS Crypto中应用了更改，因此服务器已重新启动。）
但是，服务器将删除连接并将其logging到以下两个事件日志条目中，由Schannel在系统事件日志中发布：
“从远程客户端应用程序收到TLS 1.0连接请求，但服务器不支持客户端应用程序支持的任何密码套件，SSL连接请求失败。 – 事件ID 36874
其次是
“致命的警报被生成并发送到远程端点，这可能导致连接终止，TLS协议定义的致命错误代码是40，Windows SChannel错误状态是1205。 – 事件ID 36888
在客户端使用Wireshark，我可以看到它正在尝试协商以下密码套件：
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009) Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064) Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062) Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003) Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012) Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063) 其中：
TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_3DES_EDE_CBC_SHA
包含在我使用IIS Crypto启用的内容中。 然而，服务器仍然不想触摸这些密码套件并允许build立连接。 它只是删除连接，正如通过使用OpenSSL进行连接的尝试所certificate的那样。
为什么IIS或Schannel不允许使用这些密码套件，据我所知，我已经configuration它们使用它们而不pipe默认值是什么？
我知道这是旧的，但如果有人想知道更多，也有registry内的位置为此。 我的想法是，也许TLS 1.0是启用= 0或DisabledByDefault = 1？
registry位置：\ HKey_Local_Machine \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Protocols
如果协议registry文件夹中有键和客户端和服务器的子键，并且其中的DWORD内有DisabledByDefault和Enabled，那就是configuration它。 Win 2012（r1）的默认状态是TLS1，默认情况下是允许和允许的。 （如果没有，你可以添加它们）
（请注意，服务器用于传入连接，而客户端用于传出。）
参考文献：
registry位置：\ HKey_Local_Machine \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers
我们也使用了IIS Crypto，经过大量的研究，发现每个人都使用这个程序。 （它释放了我们在组策略编辑器的密码套件列表上的1023字符限制。）
（另外：如果3DES（三重DES）被剔除，Win XP将失去与HTTPS的所有连接。
参考文献：
TL; DR： 提出并使用Linux和Nginx 。
我从来没有find缺失的答案。 除了提到的Windows Server 2012 R2服务器之外，我设置了一个Windows Server 2008 R2服务器，并完全更新了这个，并以相同的方式使用了IIS Crypto，在我看来，似乎在某些更新中部署了某种RC4 kill开关该行无法以文档化的方式停用，特别是因为另一个未修补的Windows Server 2012 R2服务器不能执行相同的操作。
由于我不能忍受运行Windows Update的恐惧，我不得不求助于运行Nginx的Ubuntu服务器，在服务器上处理TLS终止和反向代理服务器上的普通HTTP，现在我不必公开公开。 微软缺乏详尽准确的文档，并希望在较小的更新中显着地改变行为，这显示了他们的客户和他们的业务的蔑视，他们会很好地向竞争对手展示关于如何关心客户安全性的教训，同时仍然相信他们以自己的判断。
大多数组织都将遵循IIS 8强化准则： https ： //benchmarks.cisecurity.org/tools2/iis/CIS_Microsoft_IIS_8_Benchmark_v1.0.0.pdf
我build议你检查一下这里定义的值：HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 SchUseStrongCrypto
打开Strong Crypto会自动禁用RC4支持，而不是IIS Crypto工具所触及的。