由于以下错误消息,我们无法使用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。这会改变什么吗?


当前回答

确保ServicePointManager设置是在创建HttpWebRequest之前完成的,否则它将无法工作。

工作原理:

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
       | SecurityProtocolType.Tls11
       | SecurityProtocolType.Tls12
       | SecurityProtocolType.Ssl3;

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

失败:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
       | SecurityProtocolType.Tls11
       | SecurityProtocolType.Tls12
       | SecurityProtocolType.Ssl3;

其他回答

这些答案都不适合我,谷歌chrome和邮递员工作,握手服务器,但ie和。net不工作。在谷歌chrome在安全选项卡>连接显示加密和认证使用ECDHE_RSA与P-256和AES_256_GCM密码套件与服务器握手。

我在windows server 2012 R2上安装了IIS密码和密码套件列表,无法找到带有P-256和AES_256_GCM密码套件的ECDHE_RSA。然后我把Windows更新到上一个版本,但问题没有解决。最后在搜索之后,我明白了windows server 2012 R2不支持GSM,并将我的服务器更新到windows server 2016,我的问题解决了。

The top-voted answer will probably be enough for most people. However, in some circumstances, you could continue getting a "Could not create SSL/TLS secure channel" error even after forcing TLS 1.2. If so, you may want to consult this helpful article for additional troubleshooting steps. To summarize: independent of the TLS/SSL version issue, the client and server must agree on a "cipher suite." During the "handshake" phase of the SSL connection, the client will list its supported cipher-suites for the server to check against its own list. But on some Windows machines, certain common cipher-suites may have been disabled (seemingly due to well-intentioned attempts to limit attack surface), decreasing the possibility of the client & server agreeing on a cipher suite. If they cannot agree, then you may see "fatal alert code 40" in the event viewer and "Could not create SSL/TLS secure channel" in your .NET program.

The aforementioned article explains how to list all of a machine's potentially-supported cipher suites and enable additional cipher suites through the Windows Registry. To help check which cipher suites are enabled on the client, try visiting this diagnostic page in MSIE. (Using System.Net tracing may give more definitive results.) To check which cipher suites are supported by the server, try this online tool (assuming that the server is Internet-accessible). It should go without saying that Registry edits must be done with caution, especially where networking is involved. (Is your machine a remote-hosted VM? If you were to break networking, would the VM be accessible at all?)

在我公司的案例中,我们通过注册表编辑启用了几个额外的“ECDHE_ECDSA”套件,以修复当前的问题并防范未来的问题。但是如果你不能(或不愿意)编辑注册表,那么很多变通办法(不一定漂亮)就会出现在你的脑海中。例如:你的. net程序可以将它的SSL通信委托给一个单独的Python程序(它本身也可以工作,因为同样的原因,Chrome请求可能成功,而MSIE请求在受影响的机器上失败)。

您遇到的问题是aspNet用户没有访问证书的权限。您必须使用winhttpcertcfg.exe提供访问权限

关于如何设置的示例如下: http://support.microsoft.com/kb/901183

详细信息请参见步骤2

编辑:在最新版本的IIS中,此功能内置于证书管理器工具中-可以通过右键单击证书并使用管理私钥的选项来访问。更多详情请访问:https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

另一种可能是箱子上的证书输入不当。请确保选中周围的复选框。最初我没有这样做,所以代码要么超时,要么抛出相同的异常,因为私钥无法定位。

我通过命令行应用程序上传视频到Wistia时遇到了这个问题。我们的系统管理员通过使用SSL实验室扫描upload.wistia.com中列出的IIScrypto启用其他密码套件解决了这个问题

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048比特FS 256