最近同事在工作中遇到一件非常离奇的事件，通过HttpClient请求三方的HTTPS接口，在自己的电脑上运行一切正常，在服务器上一直报错：
The SSL connection could not be established，但是PostMan和Chrome却可以正常请求，这个问题已经卡了好久找不到原因。
1.背景
- 本机系统：Windows 11
- 服务器系统：Windows Server 2012
- .Net版本：.Net Core 3.1
- IE访问：握手失败
- Chrome：握手成功
- PostMan：握手成功
- 程序使用HttpClient：握手失败
2. 问题分析
在网上找了很多方案，这些代码完全没有任何作用，类似下面这种
- 添加证书：
//Certificates
X509Certificate2 x509Certificate2 = new X509Certificate2("C:\\Users\\linpa\\Desktop\\预生产证书认证导入教程\\cnooctrm.pem");
myReq.ClientCertificates.Add(x509Certificate2);
ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(CheckValidationResult);
- 忽略证书
var handler = new WebRequestHandler();
handler.ServerCertificateValidationCallback = delegate { return true; };
var httpClient = new HttpClient(handler);
httpClient.BaseAddress = new Uri("https://www.baidu.com");
var response = await httpClient.GetAsync("https://www.baidu.com");
- 指定protocol使用TLS12 | TLS13
用powershell 通过 invoke-webrequest请求也无法建立连接
之后用Java的程序写了个最简单的请求，秒通。这就强烈的激发了我的好奇心，为什么Java可以，.net不可以呢？
既然powershell和ie都无法成功请求，那么最先怀疑的就是操作系统，2012来说却是有点老了，但是为什么有的程序又能正常请求呢？
基于这个切入点，去网上查阅了大量资料，研究了一下SSL的通信原理，因为服务器本身已经开启了TLS 1.2，并且服务端的协议也是基于TLS1.2的。所以问题应该出在加密套件上了。
3.求证
-
通过MySSL对要访问的API域名进行检测，得到的信息如下：
确定协议是TLS1.2
加密套件是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
image.png -
用IISCrypto在.net程序所在的服务器进行检测，这时候TLS1.2是开启的
image.png
接着看一下加密套件，可以看到并没有我们要请求的连接对应的加密套件
image.png
那既然系统里不存在加密套件，那么其他应用为什么能正常请求呢？在查阅了微软的文档之后得出了结论：
.net请求使用的SSLStream是依赖于操作系统本身的，而Chrome、Postman等软件是不依赖操作系统的
Ok，到此为止我们的问题是比较清晰了，那么难道说在.net runtime下难道没有其他办法了么？
4. 解决方案
- 升级操作系统，至少到Windows server 2016
不过这个显然不可能实现，客户也不答应（人Java不是跑的好好地，不行就换Java团队来） - 用Java去请求，然后我们去请求Java。。。。，走http请求应该是ok的，当然也不可能真这么搞
- 使用其他语言搞一个DLL让C#来调用，比如Go 语言提供了 CGO 机制，不过这个开发成本不太划算
既然HttpClient和WebRequest都不行，有没有不依赖runtime的原生实现呢？类似于第三种方案，答案是有
GitHub上有这么一个项目：https://github.com/stil/CurlThin
它不依赖于操作系统的密码套件，可以自己指定，相关代码如下：
CurlResources.Init();
var global = CurlNative.Init();
var easy = CurlNative.Easy.Init();
string content;
try
{
var dataCopier = new DataCallbackCopier();
CurlNative.Easy.SetOpt(easy, CURLoption.URL, "https://someendpoints.net/thatendpoint?fake=true");
CurlNative.Easy.SetOpt(easy, CURLoption.WRITEFUNCTION, dataCopier.DataHandler);
//This string is needed when you call a https endpoint.
CurlNative.Easy.SetOpt(easy, CURLoption.CAINFO, CurlResources.CaBundlePath);
var headers = CurlNative.Slist.Append(SafeSlistHandle.Null, "Authorization: Bearer blablabla");
CurlNative.Easy.SetOpt(easy, CURLoption.HTTPHEADER, headers.DangerousGetHandle());
//Your set of ciphers, full list is here https://curl.se/docs/ssl-ciphers.html
CurlNative.Easy.SetOpt(easy, CURLoption.SSL_CIPHER_LIST, "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256");
CurlNative.Easy.Perform(easy);
content = Encoding.UTF8.GetString(dataCopier.Stream.ToArray());
}
finally
{
easy.Dispose();
if (global == CURLcode.OK)
CurlNative.Cleanup();
}
return content;
至此，这个问题总算是被解决了，虽然算不上完美，不过至少不需要因此而升级操作系统或者弃用.NET。
DotNet的官方github仓库曾经有人提过类似的issue，不过被不能复现、不是NET的问题等close了。不过我确实没想明白微软这么做的目的是什么？为什么一定要强依赖操作系统，难道会更安全？
以下是分过程中用到的一些工具链接，希望对你有帮助，如果有更好的方案一定要分享
myssl：https://myssl.com/
IISCrypto：https://www.nartac.com/Products/IISCrypto/Download
CurlThin：https://github.com/stil/CurlThin
