1、问题说明

前几天运维同事反馈开发同事代码在Windows 2008 R2 Datacenter服务器上运行DotNet Framework程序出现无法正常建立SSL/TLS连接的情况，在自己的电脑上运行是OK的，代码也没有改过。于是木子问他改了服务器上什么配置没有，他说改了注册表也不行。接过这个坑，心里万马奔腾，没事改注册表，这还能够回滚吗？这坑还可以越得过去吗？连忙问了一下，改注册表有记录吗？他说还在服务器桌面上，松了一口气，还可以回滚（后来回滚操作的时候发现他是直接从网上COPY的别人写的注册表文件，COPY过来的是乱码的，所以实际导入的都是错的……）。先根据对应注册表修改文件改回了注册表配置，重启服务器。

再通过DotNet Framework代码测试接口出现以下错误：

时间：2020-03-23 12:07:44 执行开始。。。
时间：2020-03-23 12:07:44 接口出现异常WebException:
Response报文：请求被中止: 未能创建 SSL/TLS 安全通道。
时间：2020-03-23 12:07:44 执行结束。。。
时间：2020-03-23 12:07:44 总耗时：428毫秒

2、排查错误

于是写了一个Python脚本测试了一把是正常的，又通过Chrome浏览器访问接口也可以正常响应，但使用DotNet Framework写的代码就是不行。于是Google了一下，希望能够尽快解决问题，回复基本上都是修改DotNet代码，添加对于4.0对TLS1.2的支持，还有就是改注册表，开启TLS1.2的支持。前者我觉得是有可能的，根据微软官方信息显示DotNet Framework 4.0需要手动配置TLS1.2的支持才能够响应TLS1.2。于是加了以下代码：

ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 |(SecurityProtocolType)768 | (SecurityProtocolType)3072;

测试OK，OK问题解决了？找了另一台服务器一测试，还是不行。怎么可能一台服务器可以，另一台不行了？没有道理啊。本以为这个问题就这么简单就解决了，但实际结果并非如此，查看日志还是一样的报错Response报文：请求被中止: 未能创建 SSL/TLS 安全通道。看来只能够通过抓包解决问题了，于是分别在行与不行的服务器上安装了Wireshark，进行抓包分析。先在正常服务器上抓包，从下图可以看到，是很正常的。

而在非正常的服务器上抓包，报错（因为在测试过程中，没有保存抓包数据，只记录了报错关键字）：

Level: Fatal, Description: HandShake Failure

一般来说，这种错误是因为加密套件不匹配造成的，所以开始比较两台服务器之间加密套件的区别。

#因为没有截图保存，只导出了Cipher Suites进行比较，发现正常的服务器支持28种Cipher Suites，而非正常的服务器只支持21种Cipher Suites，相差7种Cipher Suites。
#非正常服务器
Cipher Suites (21 suites)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
    Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
#正常服务器
Cipher Suites (28 suites)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
    Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

再仔细查看了一下正常响应的服务器，在发送Server Hello时使用的加密套件（Cipher Suite）是：TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

而非正常的服务器响应的是：TLS 1.2 Alert(Level: Fatal, Description:Handshake failure)，从这里就可以很清楚的看到原因了，是因为客户端不支持Cipher Suite：TLS_DHE_RSA_WITH_AES_256_GCM_SHA384造成的，所以HTTPS请求连接建立才会失败。

3、解决问题

找到问题，解决问题就简单了，Windows IIS Cipher Suites问题，我们可以通过IIS Crypto工具进行解决。下载工具IIS Crypto，然后查看当前服务器的加密套件：

我们会发现在这里面并没有证书支持的加密套件，于是我手动添加了证书所支持的加密套件，重启服务器。

再请求对接接口，现在可以正常获取数据了。

时间：2020-03-23 14:55:30 执行开始。。。
时间：2020-03-23 14:55:45 {
  "current_page": 1,
  "data": [
    {
      "id": xxx,
      "PID": "xxxx",
      "totalCount": "0"
    },

正常响应抓包：

至此，这个问题就解决了。