请求被中止: 未能创建 SSL/TLS 安全通道

2023 年，曾使用 .NET 开发微软 Azure 的翻译接口，返回结果一切正常。

前几天再次使用原来的代码，需要再次进行批量翻译的时候，发现程序竟然报错无法获取结果了。

返回的错误是：

请求被中止: 未能创建 SSL/TLS 安全通道。
The request was aborted: Could not create SSL/TLS secure channel.

原先的代码里，存在网上讨论过的常见解决方案：

特别是指定 Tls12 协议，已经在代码里体现，说明问题不在这里。

查到有文章说，程序使用的 .NET 版本和 Tls 1.2 有关，关系如下：

1. .NET 4.6 及以上版本：默认支持 TLS 1.2。

2. .NET 4.5：支持 TLS 1.2，但不是默认协议。需要在连接 WebRequest.Create 之前执行：ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

3. .NET 4.0：不支持 TLS 1.2，但如果系统上安装了 .NET 4.5（或更高版本），那么仍然可以选择使用 TLS 1.2。唯一的问题是 .NET 4.0 中的 SecurityProtocolType 没有 TLS1.2 的条目，因此必须使用枚举值的数字表示：ServicePointManager.SecurityProtocol = CType(3072, SecurityProtocolType)

4. .NET 3.5 或更低版本：部分操作系统不支持 TLS 1.2，并且需要安装补丁和修改注册表等，相对麻烦，详见：https://support.microsoft.com/en-us/kb/3154517、https://support.microsoft.com/en-us/kb/3154518 和 https://support.microsoft.com/en-us/kb/3154519。

当前我的服务器系统使用的是 Windows Server 2012 R2 + .Net Framework 4.8，按道理说，完全满足 .NET 4.6 以上并支持 TLS 1.2 协议，那么问题也不是在这里。

后来又查询到一个知识点：密码套件 Cipher Suites。

在创建一个 TLS 连接后，一次也称 TLS 握手协议的握手发生。在这个握手，一条 ClientHello 和一条 ServerHello 消息被发出。首先，客户端按照偏好的顺序发送它支持的密码套件的列表。然后服务器回复它从客户端的列表中选择的密码套件。

以上知识点，一般编程开发人员，很难会去深入了解这些底层的知识。按照我的肤浅理解就是，虽然发送端（客户端）和接收端（服务端）都使用了 TLS 1.2 协议，但是接受端会要求发送端提供认可的一套加解密验证标准，不符合接收端的标准，接收端会拒绝发送端的请求。也就是说，小弟要给大哥送礼，大哥要求小弟按照 2024 年的生日标准送礼，大哥说我只收美金，小弟给我日元或韩元或其他币种，大哥我是不收的，其它币种不安全，容易出事。

IISCrypto 可以很方便查看和修改自己系统的 Schannel 和 Cipher Suites

使用 www.ssllabs.com 这个网站可以查到接收端服务器，所使用的 TLS 协议版本和 Cipher Suites 密码套件。

通过查询得知，Azure 翻译接口，服务器使用了三个 TLS 1.2 套件：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

而我的 Windows Server 2012 R2 里一个对应的密码套件都没有，这才是请求被中止的真正原因。唯一的方法就是，升级到 Windows Server 2016 或更高版本。

在 Windows Server 2016 下，可看到存在前两个套件，满足通信条件。

TLS/SSL 中的密码套件 (Schannel SSP)
https://learn.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel

最终总结：

微软 Azure 翻译接口，或者说所有接口，在早些时候更新了密码套件，剔除了部分老旧套件，只保留了三个套件，如果发送请求方的机器没有这三个密码套件中的任何一个，那么发送请求会被中止。

额外说明：

在 Windows Server 2012 R2 上，使用 Postman 竟然可以成功获取到数据，可能 Postman 自带了密码套件，未使用 Windows 系统内置的套件。

欢迎搜索关注“小贝冲冲冲”，话费会员充值好用不贵