由于以下错误消息，我们无法使用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 XP中工作，但在Windows 7中，你必须在开头添加这个:
// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons
现在，它工作得很完美。
齿顶高
Robin French提到过;如果你在配置PayPal时遇到了这个问题，请注意从2018年12月3日开始他们将不支持SSL3。您需要使用TLS。这是关于它的Paypal页面。
正如你所知道的，有很多原因可能会发生这种情况。我想我应该加上我遇到的原因…
如果你设置了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 ...
如果服务器对HTTP请求返回HTTP 401未授权响应，则会出现“请求已终止:无法创建SSL/TLS安全通道”异常。
您可以通过打开跟踪级系统来确定是否发生这种情况。Net日志记录用于客户端应用程序，如本回答中所述。
一旦日志配置就绪，运行应用程序并重现错误，然后在日志输出中查找如下一行:
System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.
在我的情况下，我未能设置服务器所期望的特定cookie，导致服务器以401错误响应请求，从而导致“无法创建SSL/TLS安全通道”异常。
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
在我的情况下，这个异常的根源是在代码的某些时候，下面的代码被调用:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
这真的很糟糕。它不仅指示. net使用不安全的协议，而且还会影响在您的应用域中随后发出的每一个新的WebClient(和类似的)请求。(请注意，传入的web请求在你的ASP中不受影响。NET应用程序，但新的WebClient请求，如与外部web服务对话，是)。
在我的情况下，它实际上并不需要，所以我可以删除该语句，所有其他的web请求重新开始正常工作。根据我在其他地方的阅读，我了解到一些事情:
This is a global setting in your appdomain, and if you have concurrent activity, you can't reliably set it to one value, do your action, and then set it back. Another action may take place during that small window and be impacted.
The correct setting is to leave it default. This allows .NET to continue to use whatever is the most secure default value as time goes on and you upgrade frameworks. Setting it to TLS12 (which is the most secure as of this writing) will work now but in 5 years may start causing mysterious problems.
If you really need to set a value, you should consider doing it in a separate specialized application or appdomain and find a way to talk between it and your main pool. Because it's a single global value, trying to manage it within a busy app pool will only lead to trouble. This answer: https://stackoverflow.com/a/26754917/7656 provides a possible solution by way of a custom proxy. (Note I have not personally implemented it.)
在我的例子中，当一个Windows服务试图连接到一个web服务时，我遇到了这个问题。在Windows事件中，我终于找到了一个错误代码。
事件ID 36888(通道)被引发:
The following fatal alert was generated: 40. The internal error state is 808.
最后，它与Windows热修复有关。在我的例子中是KB3172605和KB3177186
vmware论坛提出的解决方案是在windows中添加一个注册表项。添加以下注册表后，所有工作正常。
[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ \控制SecurityProviders \ SCHANNEL \ KeyExchangeAlgorithms \ diffie - hellman)
“ClientMinKeyBitLength”= dword: 00000200
显然，这与客户端https握手中缺失的值有关。
列出你的Windows HotFix:
wmic qfe list
解决方案线程:
https://communities.vmware.com/message/2604912#2604912
希望对大家有所帮助。
确保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;
我最近也遇到了同样的问题。我的环境运行在。net 4.6.1和VB.NET下。这就是我解决问题的方法:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3
ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate)
还有util。ValidateServerCertificate函数为:
Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
Return True
End Function
system.net.webeexception:请求被中止:无法创建
SSL/TLS安全通道。
在我们的例子中，我们使用的是软件供应商，所以我们没有权限修改。net代码。显然。net 4不会使用TLS v 1.2，除非有变化。
我们的解决方法是将SchUseStrongCrypto键添加到注册表中。您可以将下面的代码复制/粘贴到扩展名为.reg的文本文件中并执行它。它是我们解决问题的“补丁”。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
这个问题可以有很多答案，因为它是关于一个通用的错误消息。我们在一些服务器上遇到了这个问题，但在开发机器上没有。拔了大部分头发后，我们发现这是微软的一个漏洞。
https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect
从本质上讲，MS假定您想要较弱的加密，但操作系统被修补为只允许TLS 1.2，因此您会收到可怕的“请求被中止:无法创建SSL/TLS安全通道”。
有三个解决办法。
用适当的更新修补操作系统:http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166
在app.config/web中添加一个设置。配置文件(如上链接所述):
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
添加在另一个答案中已经提到的注册表设置。
所有这些都在我发布的知识库文章中提到过。
没有一个答案对我有用。
这是有效的方法:
而不是像这样初始化我的X509Certifiacte2:
var certificate = new X509Certificate2(bytes, pass);
我是这样做的:
var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);
注意X509KeyStorageFlags。出口! !
我没有改变其余的代码(WebRequest本身):
// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
// etc...
}
事实上，我甚至不确定前两行是否有必要……
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" />
设置方法
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
看起来还可以，因为Tls1.2是最新版本的安全协议。但我决定深入研究，并回答我们是否真的需要硬编码它。
规格:Windows Server 2012R2 x64。
从互联网上得知，. net framework 4.6+必须默认使用Tls1.2。但是当我把我的项目更新到4.6时，什么都没有发生。
我找到了一些信息，告诉我需要手动做一些更改，默认启用Tls1.2
https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi
但是建议的windows更新不适用于R2版本
但是帮助我的是在注册表中添加2个值。您可以使用下一个PS脚本，这样它们就会自动添加
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
这正是我想要的。但是我仍然不能回答为什么NetFramework 4.6+没有设置这个问题…自动协议值?
我在Windows 2008服务器上的. net 4.5.2 Winform应用程序上得到了相同的错误。
我尝试了以下修复方法:
ServicePointManager。SecurityProtocol = SecurityProtocolType. tls1 |安全协议类型。Tls11 | SecurityProtocolType.Tls12;
但这并没有起作用，错误的发生次数仍然存在。
根据上面的答案之一，是否必须覆盖注册表的SchUseStrongCrypto键。如果我设置这个键会有什么副作用吗?
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
我知道这是晚回答，但当我试图从win server 2012 R2(客户端)调用API(托管在win server 2016上)时，我遇到了同样的问题
经过大量调查，该问题与操作系统级别的握手问题有关，特别是主机服务器不支持来自客户端的密码列表。
当我使用Wireshark跟踪连接时，我知道了这个问题，我发现不支持发送的密码。
windows server 2012 R2对可能导致TLS/SSL握手的新密码的支持有限。
起点是当我看到这个错误“从远程端点收到致命警报。TLS协议定义的致命警报代码在事件查看器中为40”(事件查看器>>自定义视图>>管理事件))
After days of pulling what hair I have left out, we solved the problem. I tried everything suggested on this post and nothing worked for me. For us, we had a basic .Net Framework 4.8 console app running on a customers Windows VM. The on-premise server we were communicating with required that SSL Certificate Validation was turned off. One of our guys discovered that the server required we were using TLS 1.0 and on the registry settings of the VM, TLS 1.0 was disabled. Once we enabled that, it worked. I also needed to added the following two lines as mentioned many times above:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
我们在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