请求已中止：无法创建 SSL/TLS 安全通道

Question

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

Answer 1

我终于找到了答案（我没有注意到我的来源，但它来自搜索）；

虽然代码在 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 页面。

Answer 2

.NET 4.5 中的解决方案是

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

如果您没有 .NET 4.5，请使用

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Answer 3

确保在创建 HttpWebRequest 之前进行 ServicePointManager 设置，否则它将不起作用。

作品：

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;

Answer 4

我在尝试访问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");

Answer 5

注意：此处投票最高的几个答案建议设置ServicePointManager.SecurityProtocol ，但 Microsoft 明确建议不要这样做。 下面，我将介绍此问题的典型原因以及解决此问题的最佳做法。

此问题的最大原因之一是活动的 .NET Framework 版本。 .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+	系统 (OS) 默认值

对于旧版本，根据系统上安装的 .NET 运行时，您的里程可能会有所不同。 例如，可能存在这样一种情况：您使用的是非常旧的框架并且不支持 TLS 1.0，或者使用 4.6.x 并且不支持 TLS 1.3。

Microsoft 的文档强烈建议使用 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" />

Answer 6

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

Answer 7

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

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

另请参阅如何启用 Schannel 事件日志记录。

Answer 8

在遇到同样的问题很多小时后，我发现运行客户端服务的 ASP.NET 帐户无权访问证书。 我通过进入运行 Web 应用程序的 IIS 应用程序池、进入高级设置并将身份从NetworkService更改为LocalSystem帐户来修复它。

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

Answer 9

设置方法

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

看起来没问题，因为 Tls1.2 是最新版本的安全协议。 但我决定深入研究并回答我们是否真的需要对其进行硬编码。

规格：Windows Server 2012R2 x64。

从互联网上得知 .NetFramework 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+ 不自动设置这个 ...Protocol 值的问题？

Answer 10

原始答案没有的东西。 我添加了更多代码以使其防弹。

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

Answer 11

如果服务器对 HTTP 请求返回HTTP 401 Unauthorized响应，则可能发生“请求已中止：无法创建 SSL/TLS 安全通道”异常。

您可以通过为您的客户端应用程序打开跟踪级 System.Net 日志记录来确定这是否发生，如本答案中所述。

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

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

在我的情况下，我未能设置服务器期望的特定 cookie，导致服务器响应 401 错误的请求，进而导致“无法创建 SSL/TLS 安全通道”异常。

Answer 12

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

要调查这种可能性，您可以下载Microsoft Message Analyzer ，并使用它对 SSL 协商进行跟踪，该协商发生在您尝试与服务器建立 HTTPS 连接但失败时（在您的 C# 应用程序中）。

如果您能够从其他环境（例如您提到的 Windows XP 计算机）成功建立 HTTPS 连接，或者可能通过在不使用操作系统密码套件设置的非 Microsoft 浏览器中点击 HTTPS URL，例如Chrome 或 Firefox），在该环境中运行另一个 Message Analyzer 跟踪以捕获 SSL 协商成功时发生的情况。

希望您会看到两个 Client Hello 消息之间的一些差异，这将使您能够准确指出失败的 SSL 协商导致它失败的原因。 然后，您应该能够对 Windows 进行配置更改，以使其成功。 IISCrypto是一个很好的工具（即使是客户端 PC，尽管名称为“IIS”）。

以下两个 Windows 注册表项控制您的 PC 将使用的 cipher_suites 值：

• HKLM\\SOFTWARE\\Policies\\Microsoft\\Cryptography\\Configuration\\SSL\\00010002
• HKLM\\SYSTEM\\CurrentControlSet\\Control\\Cryptography\\Configuration\\Local\\SSL\\00010002

这是我如何调查和解决此类Could not create SSL/TLS secure channel问题的实例的完整文章： http : //blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in -windows.html

Answer 13

另一种可能是盒子上的证书导入不当。 确保选中带圆圈的复选框。 最初我没有这样做，所以代码要么超时，要么抛出相同的异常，因为无法找到私钥。

Answer 14

这个在 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;
    }
}

Answer 15

对于大多数人来说，最高投票的答案可能就足够了。 但是，在某些情况下，即使在强制使用 TLS 1.2 之后，您仍可能继续收到“无法创建 SSL/TLS 安全通道”错误。 如果是这样，您可能需要查阅这篇有用的文章以了解其他故障排除步骤。 总结：独立于 TLS/SSL 版本问题，客户端和服务器必须就“密码套件”达成一致。 在 SSL 连接的“握手”阶段，客户端将列出其支持的密码套件，供服务器对照自己的列表进行检查。 但是在某些 Windows 机器上，某些常见的密码套件可能已被禁用（似乎是出于对限制攻击面的善意尝试），从而降低了客户端和服务器就密码套件达成一致的可能性。 如果他们不同意，那么您可能会在事件查看器中看到“致命警报代码 40”，并在您的 .NET 程序中看到“无法创建 SSL/TLS 安全通道”。

前面提到的文章解释了如何列出机器可能支持的所有密码套件并通过 Windows 注册表启用其他密码套件。 要帮助检查客户端上启用了哪些密码套件，请尝试访问 MSIE 中的此诊断页面。 （使用 System.Net 跟踪可能会给出更明确的结果。）要检查服务器支持哪些密码套件，请尝试使用此在线工具（假设服务器可通过 Internet 访问）。 不用说，注册表编辑必须谨慎进行，尤其是在涉及网络的情况下。 （您的机器是远程托管的虚拟机吗？如果您要中断网络连接，虚拟机是否可以访问？）

在我公司的案例中，我们通过注册表编辑启用了几个额外的“ECDHE_ECDSA”套件，以修复当前的问题并防止未来出现问题。 但是，如果您不能（或不会）编辑注册表，则会想到许多解决方法（不一定很漂亮）。 例如：您的 .NET 程序可以将其 SSL 流量委托给一个单独的 Python 程序（这本身可能会起作用，原因与 Chrome 请求可能会在 MSIE 请求在受影响的机器上失败的情况下成功相同）。

Answer 16

我有这个问题，因为我的 web.config 有：

<httpRuntime targetFramework="4.5.2" />

并不是：

<httpRuntime targetFramework="4.6.1" />

Answer 17

如您所知，发生这种情况的原因有很多。 以为我会添加我遇到的原因......

如果您将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 ...

Answer 18

在我的情况下，此异常的根源是在代码中的某个时刻调用了以下内容：

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

这真的很糟糕。 它不仅指示 .NET 使用不安全的协议，而且会影响随后在您的应用程序域中发出的每个新 WebClient（和类似）请求。 （请注意，传入的 Web 请求在您的 ASP.NET 应用程序中不受影响，但新的 WebClient 请求（例如与外部 Web 服务对话）会受到影响）。

就我而言，实际上并不需要它，因此我可以删除该语句，然后我的所有其他 Web 请求又可以正常工作了。 根据我在别处的阅读，我学到了一些东西：

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

Answer 19

就我而言，运行该应用程序的服务帐户无权访问私钥。 一旦我授予此权限，错误就消失了

1. 毫米波
2. 证书
3. 扩展到个人
4. 选择证书
5. 右键点击
6. 所有任务
7. 管理私钥
8. 添加

Answer 20

这样做对我有帮助：

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

Answer 21

我整天都在与这个问题作斗争。

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

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

奇怪的是没有其他错误消息，但“请求已中止：无法创建 SSL/TLS 安全通道。” 出现了这个错误

Answer 22

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

这可以设置在：

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

将设置向下滚动到“安全”并选择

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

Answer 23

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

Answer 24

终于为我找到了解决方案。

在调用 https url 之前尝试添加以下行（对于 .Net 框架 4.5）：

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Answer 25

我遇到了同样的问题，发现这个答案对我来说很有效。 密钥是 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

Answer 26

System.Net.WebException：请求被中止：无法创建 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

Answer 27

没有一个答案对我有用。

这是有效的：

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

   var certificate = new X509Certificate2(bytes, pass);

我是这样做的：

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

注意X509KeyStorageFlags.Exportable ！！

我没有更改其余代码（ 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...
}

事实上，我什至不确定前两行是否必要......

Answer 28

这个答案都对我不起作用，谷歌浏览器和邮递员工作并握手服务器，但 ie 和 .net 不工作。 在谷歌浏览器中的安全选项卡> 连接显示使用ECDHE_RSA 与 P-256 和 AES_256_GCM密码套件加密和身份验证与服务器握手。

我在 Windows Server 2012 R2 上安装了IIS Crypto并在密码套件列表中找不到带有 P-256 和 AES_256_GCM密码套件的ECDHE_RSA 。 然后我将 Windows 更新到最新版本，但问题没有解决。 最后经过搜索我了解到 windows server 2012 R2 不正确支持 GSM 并将我的服务器更新到 windows server 2016 并且我的问题解决了。

Answer 29

这对我来说是固定的，将网络服务添加到权限中。 右键单击证书 > 所有任务 > 管理私钥... > 添加... > 添加“网络服务”。

Answer 30

另一种可能性是正在执行的代码没有所需的权限。

就我而言，我在使用 Visual Studio 调试器测试对 Web 服务的调用时遇到此错误。 Visual Studio 未以管理员身份运行，这导致了此异常。

Answer 31

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

如何让 ASP.NET 访问证书存储中证书中的私钥？

Answer 32

这个问题可以有很多答案，因为它是关于通用错误消息的。 我们在一些服务器上遇到了这个问题，但在我们的开发机器上没有遇到。 拔掉大部分头发后，我们发现这是一个微软的错误。

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.config 文件。

3）添加另一个答案中已经提到的注册表设置。

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

Answer 33

由于以下错误消息，我们无法使用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。 这会有所改变吗？

Answer 34

就我而言，我在 Visual Studio 2022 下运行。我一次又一次地收到此错误。 通过代码，我看到它可以很好地检索证书。 安全性设置为 TLS1.2，以上两个答案。 无论出于何种原因，以管理员身份运行 Visual Studio使其工作。 也许有人可以向我解释代码是如何从商店中检索证书的。 我可以看到它和所有属性？ 为什么以这个世界的名义，除非我以管理员模式运行 VS，否则它不会处理请求？？？

Answer 35

由于以下错误消息，我们无法使用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。 这会有所改变吗？

Answer 36

就我而言，当Windows服务尝试连接到Web服务时，我遇到了这个问题。 最后，在Windows事件中查看时，我发现了错误代码。

引发事件ID 36888（Schannel）：

The following fatal alert was generated: 40. The internal error state is 808.

最后，它与Windows修补程序有关。 就我而言：KB3172605和KB3177186

在vmware论坛中提出的解决方案是在Windows中添加一个注册表项。 添加以下注册表后，一切正常。

[HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Control \\ SecurityProviders \\ SCHANNEL \\ KeyExchangeAlgorithms \\ Diffie-Hellman]

“ ClientMinKeyBitLength” = dword：00000200

显然，这与客户端的https握手中的值丢失有关。

列出您的Windows HotFix：

wmic qfe list

解决方案线程：

https://communities.vmware.com/message/2604912#2604912

希望对您有所帮助。

Answer 37

只要这是一个相对“实时”的链接，我就想添加一个新选项。 这种可能性是由于Poodle攻击的问题，该服务不再支持SSL 3.0。 查看有关此内容的Google声明。 我一次在几个Web服务上遇到了这个问题，意识到必须继续进行下去。 我切换到TLS 1.2，一切又恢复了。

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

Answer 38

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

Answer 39

除上述答案外，请确保已将CER证书，而不是PFX文件导入本地计算机商店。 有这两个文件时常见的错误。

Answer 40

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

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 位 FS 128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 位 FS 256

Answer 41

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

一个例子是在 UsernameToken Profile 下，其中的消息被<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>

Answer 42

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

在我的情况下，两者都很好，问题出在服务器的证书哈希算法中，客户端的 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>

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

Answer 43

经过几天拔掉我遗漏的头发后，我们解决了这个问题。 我尝试了这篇文章中建议的所有内容，但对我没有任何帮助。 对于我们来说，我们有一个基本的 .Net Framework 4.8 控制台应用程序在客户的 Windows VM 上运行。 我们与之通信的本地服务器要求关闭 SSL 证书验证。 我们的一个人发现服务器要求我们使用 TLS 1.0，而在 VM 的注册表设置上，TLS 1.0 被禁用。 一旦我们启用它，它就起作用了。 我还需要添加上面多次提到的以下两行：

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

Answer 44

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

Answer 45

我最近遇到了同样的问题。 我的环境在 .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

Answer 46

如果您不想、无法轻松或无法快速修补您的代码，您可以改为通过框架中的 .NET 代码强制使用 TLS 1.2。

这不是我的应用程序，但它帮助修补了我们旧的 .NET 4.5 应用程序（在 Server 2008r2 上运行）以再次使用 Paypal Payflow Gateway。 他们必须在 2018 年 6 月 25 日和 18 年 7 月 8 日之间的 Payflow 网关回调上开始强制连接到 TLS 1.2。

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

Answer 47

我在商店和档案中有证书。 我尝试连接文件并收到此错误消息。 当我在商店使用它时，它起作用了。 我最好的猜测是，当我想使用存档的证书时，由于证书在商店中而出现了某种冲突。 （同一台机器上的不同服务使用商店中的证书，我使用文件中的证书开发了不同的服务。在测试之前，它在开发上就像一个魅力一样）。

Answer 48

我在 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

Answer 49

从注册表中删除此选项帮助我在 Windows Server 2012 [HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\KeyExchangAlgorithms

Answer 50

我知道这是迟到的答案，但是当我尝试从 win server 2012 R2（客户端）调用 API（托管在 win server 2016 上）时遇到了同样的问题

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

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

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

起点是当我在事件查看器（事件查看器 >> 自定义视图 >> 管理事件）中看到此错误“收到来自远程端点的致命警报。TLS 协议定义的致命警报代码为 40”时

Answer 51

我们在客户端 Windows Server 2012R2 中遇到了同样的问题。 错误 40 表示客户端和服务器不同意使用的密码套件。 在大多数情况下，服务器需要客户端无法识别的密码套件。

如果您无法修改服务器设置，解决方案是以这种方式将那些“缺失”的密码套件添加到客户端：

1. 一、go转SSLLabs SSL Labs
2. 输入您遇到连接问题的站点/api 的 url
3. 等待几分钟直到测试完成
4. Go 到“密码套件”部分并仔细阅读 TLS 1.3 / TLS 1.2
5. 在那里你会找到服务器接受的密码套件
6. 现在在您的 windows 服务器中，go 到 Regedit
7. 打开密钥： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL
8. 在那里您会找到 2 个文件夹： 00010002 -->TLS 1.2 and 00010003 --> TLS 1.3
9. 现在，编辑 Functions 键，并添加服务器所需的套件
10. 在我们的例子中，我们需要将TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384添加到00010002文件夹