由于以下错误消息,我们无法使用WebRequest连接到HTTPS服务器:

请求被中止:无法创建SSL/TLS安全通道。

我们知道服务器没有有效的HTTPS证书,但为了绕过这个问题,我们使用下面的代码,我们从另一个StackOverflow帖子:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

问题是服务器从未验证证书,并出现上述错误而失败。有人知道我该怎么做吗?


我应该提到的是,我和一个同事几周前进行了测试,它运行得很好,与我上面写的类似。我们发现的唯一“主要区别”是,我用的是Windows 7,而他用的是Windows XP。这会改变什么吗?


当前回答

只要这是一个相对“活”的链接,我想我会添加一个新的选项。这种可能性是由于Poodle攻击的问题,该服务不再支持SSL 3.0。看看关于这个的谷歌语句。我在使用多个web服务时同时遇到了这个问题,并意识到一定发生了什么事情。我切换到TLS 1.2,一切都恢复正常了。

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

其他回答

我在尝试访问https://ct.mob0.com/Styles/Fun.png时遇到了这个问题,这是CloudFlare在其CDN上分发的一个图像,支持SPDY和奇怪的重定向SSL证书等疯狂的东西。

我没有像Simons的答案那样指定Ssl3,而是通过下面的Tls12来修复它:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

另一种可能是正在执行的代码没有所需的权限。

在我的例子中,我在使用Visual Studio调试器测试对web服务的调用时得到了这个错误。Visual Studio没有以管理员身份运行,这导致了此异常。

这个错误是一般的,有很多原因导致SSL/TLS协商失败。最常见的是无效或过期的服务器证书,您可以通过提供自己的服务器证书验证钩子来解决这个问题,但这并不一定是唯一的原因。服务器可能需要相互身份验证,它可能配置了一组客户端不支持的密码,它可能有太大的时间漂移,以至于握手无法成功,还有很多其他原因。

最好的解决方案是使用channel故障排除工具集。channnel是负责SSL和TLS的SSPI提供者,您的客户端将使用它进行握手。看看TLS/SSL工具和设置。

另请参阅如何启用通道事件日志记录。

我们在Windows Server 2012R2客户端中遇到了同样的问题。 错误40表示客户端和服务器不同意使用密码套件。 在大多数情况下,服务器需要客户端无法识别的密码套件。

如果你不能修改服务器设置,解决方案是将那些“缺失”的密码套件添加到客户端:

First, go to SSLLabs SSL Labs Enter the url of the site/api you are having problem to connect Wait a few minutes until the test is completed Go to 'Cipher Suites' section and read very carefully TLS 1.3 / TLS 1.2 There you will find the Cipher Suites accepted by the server Now in your windows server, go to Regedit Open the Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL There you will find 2 folders: 00010002 -->TLS 1.2 and 00010003 --> TLS 1.3 Now, edit the Functions key, and add the suites required by the server In our case, we needed to Add TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to 00010002 folder

Another possible cause of the The request was aborted: Could not create SSL/TLS secure channel error is a mismatch between your client PC's configured cipher_suites values, and the values that the server is configured as being willing and able to accept. In this case, when your client sends the list of cipher_suites values that it is able to accept in its initial SSL handshaking/negotiation "Client Hello" message, the server sees that none of the provided values are acceptable, and may return an "Alert" response instead of proceeding to the "Server Hello" step of the SSL handshake.

为了研究这种可能性,您可以下载Microsoft Message Analyzer,并使用它来跟踪当您尝试建立到服务器的HTTPS连接失败时(在c#应用程序中)发生的SSL协商。

如果您能够从另一个环境(例如您提到的Windows XP机器)成功建立HTTPS连接,或者可能通过在不使用操作系统加密套件设置的非微软浏览器(如Chrome或Firefox)中点击HTTPS URL,则在该环境中运行另一个Message Analyzer跟踪,以捕获SSL协商成功时发生的情况。

希望您能看到两个Client Hello消息之间的一些区别,从而能够准确地指出失败的SSL协商是什么原因导致它失败的。然后,您应该能够对Windows进行配置更改,以使其成功。IISCrypto是一个很好的工具(即使对于客户端pc,尽管它叫“IIS”)。

以下两个Windows注册表项控制你的电脑将使用的cipher_suites值:

微软HKLM \ SOFTWARE \政策\ \ SSL加密\ Configuration \ \ 00010002 HKLM \ SYSTEM \ CurrentControlSet \ \控制密码学\ \当地\ SSL配置\ 00010002

以下是我如何调查和解决这种无法创建SSL/TLS安全通道问题的实例的完整记录:http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html