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


当前回答

对于SOAP/WCF用户,当服务器拒绝您的WS-Security配置时,也会发生此错误。客户端接收到的错误信息非常模糊,但是服务器管理员可能能够确定原因。

UsernameToken配置文件下有一个这样的例子,其中消息被<wsu:Created> time视为过期,不是有效的ISO 8601 datetime,原因可能是格式错误、不是UTC或服务器时间不匹配。

<wsse:UsernameToken wsu:Id="Example-1">
   <wsse:Username> ... </wsse:Username>
   <wsse:Password Type="..."> ... </wsse:Password>
   <wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
   <wsu:Created>2021-01-31T19:00:00.0000000Z</wsu:Created>
</wsse:UsernameToken>

其他回答

我一整天都在为这个问题而挣扎。

当我用。net 4.5创建一个新项目时,我终于让它工作了。

但如果我降级到4.0,我又遇到了同样的问题,而且对于那个项目来说是不可逆转的(即使我试图再次升级到4.5)。

奇怪的是,没有其他错误消息,但“请求被中止:无法创建SSL/TLS安全通道。

在这个问题上花了很多时间后,我发现ASP。运行客户端服务的NET帐户没有访问证书的权限。我通过进入web应用程序运行的IIS应用程序池,进入高级设置,并将身份从NetworkService更改为LocalSystem帐户来修复它。

更好的解决方案是让证书与默认的NetworkService帐户一起工作,但这适用于快速功能测试。

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请求在受影响的机器上失败)。

正如你所知道的,有很多原因可能会发生这种情况。我想我应该加上我遇到的原因…

如果你设置了WebRequest的值。Timeout到0,这是抛出的异常。下面是我的代码…(只是超时值不是硬编码的0,而是一个被无意中设置为0的参数)。

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

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