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

在我的情况下，两者都是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>

然后log中的错误让我得到了这个解

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

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

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

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

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; };

设置方法

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+没有设置这个问题…自动协议值?