由于以下错误消息，我们无法使用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。这会改变什么吗?
我们在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
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请求在受影响的机器上失败)。
注意:这里投票最多的几个答案建议设置ServicePointManager。安全协议，但微软明确建议不要这样做。下面，我将讨论此问题的典型原因以及解决该问题的最佳实践。
这个问题的最大原因之一是活动的。net框架版本。. net框架运行时版本会影响默认启用的安全协议。
在ASP。NET站点，框架运行时版本通常在web.config中指定。(见下文)
在其他应用程序中，运行时版本通常是构建项目的版本，而不管它是否运行在具有更新的. net版本的机器上。
似乎没有任何权威的文档说明它在不同版本中是如何具体工作的，但似乎默认值或多或少是这样确定的:
| Framework Version |
Default Protocols |
| 4.5 and earlier |
SSL 3.0, TLS 1.0 |
| 4.6.x |
TLS 1.0, 1.1, 1.2, 1.3 |
| 4.7+ |
System (OS) Defaults |
对于较旧的版本，根据系统上安装的. net运行时的不同，您的里程可能会有所不同。例如，可能会出现这样的情况，您正在使用一个非常旧的框架，不支持TLS 1.0，或者使用4.6。不支持TLS 1.3。
微软的文档强烈建议使用4.7+和系统默认值:
我们建议您:
在你的应用程序上瞄准。net Framework 4.7或更高版本。在你的WCF应用中瞄准。net Framework 4.7.1或更高版本。
不指定TLS版本。配置代码，让操作系统决定TLS版本。
执行彻底的代码审计，以验证您没有指定TLS或SSL版本。
ASP。NET站点:检查<httpRuntime>元素中的targetFramework版本，因为这个(当出现时)决定了你的站点实际使用的运行时:
<httpRuntime targetFramework="4.5" />
好:
<httpRuntime targetFramework="4.7" />
