DotNet SSL TLS证书问题分析排障

问题说明

前几天运维同事反馈开发同事代码在Windows 2008 R2 Datacenter服务器上跑会出现无法正常建立SSL/TLS连接的情况，在自己的电脑上跑是OK的，代码也没有变动过。于是我问他改了服务器上什么配置没有，他说改了注册表也不行。接过这个坑，心里有一万条艹，没事改注册表，这还能够回滚吗？这坑还可以越得过去吗？连忙问了一下，改注册表有记录吗？他说还在服务器桌面上，松了一口气，还可以回滚。先根据对应注册表修改文件改回了注册表配置，重启服务器。

再通过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毫秒

排查错误

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

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

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

问题说明

再通过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毫秒

排查错误

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

`1`	`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请求连接建立才会失败。

解决问题

找到问题，解决问题就简单了，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"},

正常响应抓包：

扩展思考

怎么知道对应证书支持哪些加密套件了？

我们可以通过这个工具的Site Scanner，输入对应URL，然后Scan，这时候会打开ssllabs，进行网站证书检测，我们可以拉到最后面，有一个Cipher Suites就可以看到对应的TLS 1.2加密套件支持。

这里我们可以看到此证书是支持5种加密套件的，而我们的服务器完美的错过了这5种加密套件，但也并非所有的服务器都错过了，所以出现有些服务器可以正常访问接口，有些服务器不正常。

还有一种方法，就是我们通过Chrome，按F12，选择Security，也可以查看到对应的安全连接设置。

或者通过nmap命令查看：

~ » nmap -p 443 --script ssl-enum-ciphers www.oubayun.com
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-23 17:23 CST
Nmap scan report for www.oubayun.com (xxx.xxx.xxx.xxx)
Host is up (0.065s latency).PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       Key exchange (dh 2048) of lower strength than certificate key
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: ANmap done: 1 IP address (1 host up) scanned in 18.84 seconds

另外还可以通过sslScan命令查看其它推荐的加密套件。

b~ » sslscan www.oubayun.com
Version: 1.11.13-static
OpenSSL 1.0.2f  28 Jan 2016Connected to xxx.xxx.xxx.xxxTesting SSL server www.oubayun.com on port 443 using SNI name www.oubayun.comTLS Fallback SCSV:
Server supports TLS Fallback SCSVTLS renegotiation:
Session renegotiation not supportedTLS Compression:
Compression disabledHeartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleedSupported Server Cipher(s):
#这里我们可以看到首选的是： ECDHE-RSA-AES256-GCM-SHA384
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bitsSSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    4096Subject:  www.oubayun.com
Altnames: DNS:www.oubayun.com
Issuer:   Let's Encrypt Authority X3Not valid before: Feb 29 09:35:16 2020 GMT
Not valid after:  May 29 09:35:16 2020 GMT

当然查看Cipher Suites的方法不仅仅只有这些，还有很多其它的方法。

怎么开启TLS 1.2支持？

这是我们也可以通过这个工具，点击Schannel，然后勾选TLS 1.2，选择Apply，再重启服务器即可。

TLS 1.2支持37种加密套件，但建议使用以下种类：

#Nginx设置
AESGCM+ECDH
ARIAGCM+ECDH
CHACHA20+ECDH

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

`1`	`Level: Fatal, Description: HandShake Failure`