请求被中止:无法创建SSL/TLS安全通道 - The request was aborted: Could not create SSL/TLS secure channel

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

The request was aborted: Could not create SSL/TLS secure channel.

我们知道服务器没有有效的 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。这会改变什么吗?

1310601 次浏览
小开

您可以尝试安装演示证书(一些ssl提供程序提供一个月的免费演示证书)，以确定问题是否与证书有效性有关。

小开

您遇到的问题是 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

小开

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

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

参见如何启用通道事件日志。

小开
最佳答案

我终于找到了答案(我没有注明我的来源，但它来自偶然的一次搜索);

虽然代码在 Windows XP 中工作，但在 Windows 7 中，你必须在开头添加这个:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

现在，它工作得很好。

ADDENDUM

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 ...
小开

请求被中止:无法创建SSL/TLS安全通道;如果服务器对HTTP请求返回HTTP 401未经授权响应，则会发生异常。

您可以通过打开跟踪级系统来确定是否发生这种情况。客户端应用程序的网络日志记录，如这个答案中所述。

一旦日志配置就绪，运行应用程序并重现错误，然后在日志输出中查找如下一行:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

在我的情况下，我未能设置服务器期望的特定cookie，导致服务器响应请求时出现401错误，这反过来又导致“无法创建SSL/TLS安全通道”。例外。

小开

我在尝试点击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");
小开

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

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

小开

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

更好的解决方案是让证书使用默认的NetworkService帐户，但这适用于快速功能测试。

小开

对我来说，问题是我试图将IIS作为web服务部署在服务器上，我在服务器上安装了证书，但运行IIS的用户对证书没有正确的权限。

如何给ASP。NET访问证书存储中的证书中的私钥?< / >

小开

对我来说，这只是发生在一个网站上，结果是它只有RC4密码可用。在之前加强服务器的努力中，我禁用了RC4密码，一旦我重新启用这个问题就解决了。

小开

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

# EYZ0

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

奇怪的是，这个错误除了"请求被中止:无法创建SSL/TLS安全通道。"之外没有其他错误消息出现

小开

这是原始答案所没有的。我又加了些代码让它防弹。

ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
小开

The request was aborted: Could not create SSL/TLS secure channel错误的另一个可能原因是客户端PC配置的cipher_suites值与服务器配置为愿意和能够接受的值之间的不匹配。在这种情况下，当您的客户端在其初始SSL握手/协商“客户端Hello”消息中发送它能够接受的cipher_suites值列表时，服务器认为所提供的值都是不可接受的，并可能返回“Alert”响应，而不是继续进行SSL握手的“服务器Hello”步骤。

为了研究这种可能性，您可以下载微软消息分析器，并使用它来跟踪当您尝试建立到服务器的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

这里是我如何调查和解决Could not create SSL/TLS secure channel问题的一个实例的完整记录: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请求重新开始正常工作。根据我在其他地方的阅读，我了解到一些事情:

  • 这是你的appdomain中的一个全局设置，如果你有并发活动，你不能可靠地将它设置为一个值，执行你的操作，然后再将它设置回来。另一个动作可能在这个小窗口期间发生并受到影响。
  • 正确的设置是保持默认值。这使得。net可以继续使用任何最安全的默认值，随着时间的推移和你升级框架。将其设置为TLS12(在撰写本文时是最安全的)将工作现在，但5年后可能会开始引起神秘的问题。
  • 如果您确实需要设置一个值，您应该考虑在一个单独的专用应用程序或appdomain中进行设置，并找到一种方法在它和您的主池之间进行通信。因为它是一个单一的全局值，试图在繁忙的应用程序池中管理它只会导致麻烦。这个答案:https://stackoverflow.com/a/26754917/7656通过自定义代理提供了一个可能的解决方案。(注意，我并没有亲自实现它。)
小开

如果客户端是一台windows机器，一个可能的原因可能是服务所需的tls或ssl协议未激活。

可以设置为:

控制面板->网络和Internet -> Internet选项->高级

向下滚动设置到“安全”，在两者之间进行选择

  • 使用SSL 2.0
  • 使用SSL 3.0
  • 使用TLS 1.0协议
  • 使用TLS 1.1
  • 使用TLS 1.2

enter image description here

小开

我有这个问题是因为我的网。配置:

<httpRuntime targetFramework="4.5.2" />

而不是:

<httpRuntime targetFramework="4.6.1" />
小开

在我的例子中，当一个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

希望对大家有所帮助。

小开

这一个是为我工作在MVC webclient

public string DownloadSite(string RefinedLink)
{
try
{
Uri address = new Uri(RefinedLink);


ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;


System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;


using (WebClient webClient = new WebClient())
{
var stream = webClient.OpenRead(address);
using (StreamReader sr = new StreamReader(stream))
{
var page = sr.ReadToEnd();


return page;
}
}


}
catch (Exception e)
{
log.Error("DownloadSite - error Lin = " + RefinedLink, e);
return null;
}
}
小开

在我的例子中，运行应用程序的服务帐户没有访问私钥的权限。一旦我给予了这个许可，错误就消失了

  1. mmc
  2. 证书
  3. 扩展到个人
  4. 选择证书
  5. 右击
  6. 所有任务
  7. 管理私钥
  8. 添加业务帐户用户
小开

默认的。net ServicePointManager.SecurityProtocol使用SSLv3和TLS。如果您正在访问Apache服务器，有一个名为SSLProtocol的配置变量，默认为TLSv1.2。您可以设置ServicePointManager.SecurityProtocol以使用您的web服务器支持的适当协议，或者更改Apache配置以允许所有协议，如SSLProtocolall。

小开

在。net 4.5中，这个问题的解决方案是

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

如果你没有。net 4.5，那就使用

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
小开

如果您是从Visual Studio运行代码，请尝试以管理员身份运行Visual Studio。为我修正了这个问题。

小开

这对我来说是固定的，添加网络服务到权限。 右键单击证书 > 所有任务 > 管理私钥… > 添加…> 添加"Network Service"

小开

我也有同样的问题，发现这个答案对我来说工作正常。密码是3072。这个链接提供了关于“3072”修复的详细信息。

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;


XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

在我的情况下，有两个提要需要修复:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss
小开

确保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
小开

如果你不想，不容易，或者不能快速地给你的代码打补丁，相反，你可以在框架中强制你的 .net 代码使用 TLS 1.2。

这不是我的应用程序，但它帮助修复了我们的旧的。net 4.5 应用程序(在Server 2008r2上运行)，再次与Paypal Payflow Gateway一起工作。他们一定是在6/25/18和7/8/18之间开始在资金流网关回调上强制连接到TLS 1.2。

详情:https://github.com/TheLevelUp/pos-tls-patcher 下载: https://github.com/TheLevelUp/pos-tls-patcher/releases < / p >

小开

System.Net。请求被中止:无法创建

. 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安全通道。”

有三个解决办法。

  1. 用正确的更新修补操作系统:http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

  2. 在app.config/web中添加一个设置。配置文件(如上链接所述):

    <runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
  1. 添加在另一个答案中已经提到的注册表设置。

所有这些都在我发布的知识库文章中提到过。

小开

没有一个答案对我有用。

这是有效的方法:

而不是像这样初始化我的X509Certifiacte2:

   var certificate = new X509Certificate2(bytes, pass);

我是这样做的:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

# eyz1 # eyz0 # eyz2

我没有改变代码的其余部分(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...
}

事实上，我甚至不确定前两行是否有必要……

小开

我有证书在存储和文件。我试图连接文件，得到这个错误消息。我在店里用的那台还能用。我的最佳猜测是，当我想使用文件中的证书时，由于存储了证书而导致了某种冲突。 (同一台机器上的另一个服务使用存储中的证书，而我已经使用文件中的证书开发了一个不同的服务。

小开

top-voted回答可能对大多数人来说已经足够了。但是，在某些情况下，即使在强制使用TLS 1.2之后，您也可能继续得到“无法创建SSL/TLS安全通道”错误。如果是这样，您可能需要咨询这篇有用的文章以获得其他故障排除步骤。总而言之:与TLS/SSL版本问题无关，客户端和服务器必须就“加密套件”达成一致。在SSL连接的“握手”阶段，客户端将列出其支持的密码套件供服务器对照自己的列表进行检查。但在一些Windows机器上，某些常见的密码套件可能已被禁用(似乎是出于好意试图限制攻击面)，降低了客户端被攻击的可能性。服务器同意加密套件。如果他们不能达成一致，那么您可能会在事件查看器中看到“致命警报代码40”，并且在. net程序中看到“无法创建SSL/TLS安全通道”。

前面的文章解释了如何列出一台机器可能支持的所有密码套件，并通过Windows注册表启用其他密码套件。要帮助检查客户机上启用了哪些密码套件，请尝试访问MSIE中的此诊断页面。(使用系统。网络追踪可能会给出更明确的结果。)要检查服务器支持哪些密码套件，请尝试这个在线工具(假设服务器可以通过internet访问)。不用说，注册表编辑必须谨慎进行，尤其是在涉及到网络的地方。(您的机器是远程托管的VM吗?如果你要中断网络连接，虚拟机还能被访问吗?)

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

小开

我通过命令行应用程序上传视频到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 bits FS 256

小开

这里投票最多的几个答案建议设置ServicePointManager.SecurityProtocol，但微软明确建议反对这样做。下面，我将讨论此问题的典型原因以及解决该问题的最佳实践。

这个问题的最大原因之一是活动的。net框架版本。. net框架运行时版本会影响默认启用的安全协议。

  • 在ASP。NET站点，框架运行时版本通常在web.config中指定。(见下文)
  • 在其他应用程序中，运行时版本通常是构建项目的版本，而不管它是否运行在具有更新的. net版本的机器上。

似乎没有任何权威的文档说明它在不同版本中是如何具体工作的，但似乎默认值或多或少是这样确定的:

框架版本 默认协议
4.5及以前版本 SSL 3.0, TLS 1.0
4.6.x TLS 1.0, 1.1, 1.2, 1.3
4.7 + System (OS)默认值

对于较旧的版本，根据系统上安装的. 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+没有设置这个问题…自动协议值?

小开

另一种可能是正在执行的代码不具备所需的前提。

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

小开

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

enter image description here

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

小开

我在Windows 2008服务器上的. net 4.5.2 Winform应用程序上得到了相同的错误。

我尝试了以下修复方法:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1|SecurityProtocolType.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
小开

这样做帮助了我:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
小开
在Windows Server 2012中，从注册表中删除这个选项对我有帮助 控制[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ \ SecurityProviders \ SCHANNEL \ KeyExchangAlgorithms < / p >

enter image description here

小开

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

UsernameToken配置文件下有一个例子，其中消息被认为过期，<wsu:Created>时间不是有效的ISO 8601日期时间，要么是由于格式错误，不是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>
小开

终于为我找到了解决办法。

尝试在调用https url之前添加下面的行(用于.Net framework 4.5):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
小开

以上大多数答案都提到了会话算法或密钥交换算法。

在我的情况下，两者都是OK的，问题是在服务器的证书哈希算法，在客户端PC上没有启用。

我在应用程序的配置中添加了一个部分。

<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net">
<listeners>
<add name="System.Net" />
</listeners>
</source>
<source name="System.Net.Sockets">
<listeners>
<add name="System.Net" />
</listeners>
</source>
<source name="System.Net.Cache">
<listeners>
<add name="System.Net" />
</listeners>
</source>
</sources>
<sharedListeners>
<add
name="System.Net"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Net.trace.log"
/>
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
<add name="System.Net.Sockets" value="Verbose" />
<add name="System.Net.Cache" value="Verbose" />
</switches>
</system.diagnostics>

然后日志中的错误导致我找到了这个解决方案

小开

我知道这是晚回答，但当我试图从win server 2012 R2(客户端)调用API(托管在win server 2016上)时，我遇到了同样的问题

经过大量调查，该问题与操作系统级别的握手问题有关，特别是主机服务器不支持来自客户端的密码列表。

当我使用Wireshark跟踪连接时，我知道了这个问题，我发现不支持发送的密码。

windows server 2012 R2对可能导致TLS/SSL握手的新密码的支持有限。

起点是当我在事件查看器中看到这个错误从远程端点收到致命警报。TLS协议定义的致命警报代码为40" (事件查看器>>定制视图>>管理事件))

小开
在我的例子中，我在Visual Studio 2022下运行。我一次又一次地得到这个错误。通过代码，我看到它很好地检索了证书。安全性设置为TLS1.2，以上两个答案都是如此。不管出于什么原因，以管理员身份运行Visual Studio让它成功了! 也许有人可以向我解释一下代码是如何从存储中检索到证书的。我能看到它和所有的属性。为什么在这个世界上它不处理请求，除非我在管理模式下运行VS ?< / p >
小开

经过几天的拉扯我留下的头发，我们解决了这个问题。我尝试了这篇文章中建议的所有方法，但没有一个对我有效。对我们来说，我们有一个基本的。net Framework 4.8控制台应用程序运行在客户的Windows虚拟机上。与我们通信的本地服务器要求关闭SSL证书验证。我们的一个人发现服务器要求我们使用TLS 1.0，在虚拟机的注册表设置上，TLS 1.0被禁用。一旦我们启用了它，它就起作用了。我还需要添加以下两行，上面已经多次提到:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

提交答案