图片来源于网络

2.案例分享

2.1 CFCA 证书的历史问题

2.1.1背景

某客户为其生产环境的站点申请了一张由 CFCA 签发的证书。相关域名正确配置该证书且启用 HTTPS 后，经测试发现他们的客户端 App 在低版本手机上（ iOS < 10.0，Android < 6.0）无法连接到相关站点。

客户端调试发现，控制台会看到证书无效的错误信息（Invalid Certificate 或 Certificate Unknown ）。

2.1.2 排查

起初，工程师并不知道客户的证书是由哪个机构签发以及有什么问题。而对于这类问题，一般均需要客户端网络包做进一步的分析与判断。因此安排客户在受影响的设备上进行问题复现及客户端抓包操作。

获取到网络包后，首先确认了客户端连接失败的直接原因为 TLS 握手过程异常终止，见下：

查看 Encrypted Alert 内容，错误信息为 0x02 0x2E。根据 TLS 1.2 协议（RFC5246 ）的定义， 该错误为因为 certificate_unknown。

继续查看该证书的具体信息，根据 Server Hello 帧中携带的证书信息得知该证书由证书机构 China Financial Certification Authority(CFCA) 签发。再根据证书信息中的 Authority Information Access (AIA) 信息确认 Intermediate CA 和 Root CA 证书。确认该证书签发机构的根证书为 CFCA EV ROOT。

回到存在问题的手机设备上（Android 5.1），检查系统内置的受信任 CA 根证书列表，未能找到 CFCA EV ROOT CA 证书；而在正常连接的手机上，可以找到该 CA 的根证书并默认设置为”信任“。

查阅 CFCA 证书的相关说明，该机构的证书在 iOS 10.1 及 Android 6.0 及以上版本才完成入根接入。

2.1.3小结

从上面的分析可以看到，该问题的根因是低版本客户端设备没有内置 CFCA 的 CA 根证书。因此，基本的解决方案包括：

1. 更换其他 CA 机构签发的证书，保证其 CA 根证书的在特定设备上已默认信任。
2. 手动在受影响的设备上安装该 CA 根证书及中间证书，并配置为信任状态。
3. 客户端 App 预置该 CA 根证书，并通过客户端代码配置信任该证书。

需要结合不同的业务场景选择合理解决方案。

2.2 证书链信任模式引起的问题

2.2.1 背景

某客户新增了一个容灾备用接入地址，启用了一个新的域名并配置了一张全新的证书。测试发现，切换到该备用地址时，Android 客户端无法正常连接，报证书未知错误（Certificate Unknown）；iOS 客户端表现正常。

2.2.2 排查

和 2.1 的问题类似，首先在受影响的设备上进行问题复现及客户端抓包操作。

获取到网络包之后，确认了客户端连接失败的直接原因为 TLS 握手过程异常终止，原因与 2.1 中的问题一样，为Certificate Unknown ：

类似问题 2.1 的排查动作，查看该证书的 CA 根证书及根证书的信任情况。

发现该证书由中间 CA 机构 Secure Site Pro CA G2 签发，其根 CA 为 DigiCert Global Root CA:

DigiCert Global Root CA 作为一个广泛支持的证书签发机构，其根 CA 证书在绝大多数的设备上均为受信任状态，这一点在受影响的设备上也得到了确认。既然根 CA 的证书处于信任状态，为何证书验证还是失败？这成为下一步排查的重点方向。

同一台设备，切换到正常环境下，也完成一次抓包操作。获取到新的网络包后做对比分析，发现两种情况下网络包中体现的区别为：

正常环境下，服务器返回的证书包含了完整的 CA 证书链；

异常情况下，服务端返回的证书仅包含叶节点 CA 证书。

根据上述线索进行排查研究，发现：不同于其他平台，Android 客户端默认是不会通过 AIA Extension 去做证书链的校验。

因此，当中间 CA 证书未安装或未缓存时，客户端 App 是不会主动拉取中间 CA 证书并做进一步信任链校验的，从而导致证书校验失败。

2.2.3 小结

从上面的排查分析看到，该问题和 Android 平台自身的证书校验机制和证书打包方式相关。解决方案包括：

代码层面手动定制 TrustManager 去定制校验过程；

或重新打包证书，将中间 CA 证书和根 CA 证书一同打包到服务端证书中。

该客户综合开发成本与环境现状，选择重新打包证书。新的证书配置完成后，问题得到解决。

2.3 加密套件协商引起的问题

2.3.1 背景

某客户反馈他们的 iOS 客户端 App 用户在特定运营商网络环境下无法打开特定的业务站点（HTTPS 站点）。客户端处于白屏等待状态并最终报错；而在同样的网络环境下，系统浏览器可以打开该站点；同一台设备，切换到另一个网络运营商下，也可以访问该站点。

2.3.2 排查

由于该问题直接表现在 Web 层，因此首先尝试通过 Charles 抓取 HTTP 层包进行分析。HTTP 日志发现相关 HTTP 请求并未发出。

由此怀疑问题发生在 TCP 层，进而在受影响的设备上进行问题复现及客户端抓包操作。

获取到网络包后，首先确认问题：

1. 通过页面域名在网络包中寻找 DNS 解析结果；
2. 根据 DNS 解析结果找到站点 IP，并过滤出客户端与该 IP 之间的访问情况；
3. 观察客户端与该服务器之间的网络活动，发现存在 TLS 握手失败的情况：

从上面的网络包可以看到，服务端（机房 P 中的服务器提供接入服务）在收到 Client Hello 后，直接返回了 Handshake Failure，这种情况下，一般需要服务端配合排查握手失败的直接原因。在客户端条件下，可以进一步缩小排查疑点。

重新考虑客户问题条件：相同的网络条件下，系统浏览器可以打开该页面；同一设备切换到另一运营商下（站点此时由机房 Q 中的服务器提供接入服务），可以正常访问。针对这这两种正常情况进行抓包和进一步分析。

通过对三种情况的网络观察发现：

• 问题 App 发出的 Client Hello 显示支持 17 种加密套件：

• 正常 App 发出的 Client Hello 显示支持 26 种加密套件：

1. 正常 App 和机房 P 服务器协商的加密套件为：TLS_RAS_WITH_3DES_EDE_CBC_SHA (0x000a) （不在问题 App 支持的加密套件范围内）；
2. 问题 App 和机房 Q 服务器协商的加密套件为：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)（在问题 App 支持的加密套件范围内）；

根据上述情况，可以推论问题的基本情况为：

1. 问题 App 发出去的握手请求，支持17种加密套件（ A 集合）；
2. 正常 App 发出去的握手请求，支持26种加密套件（ B 集合）；
3. 机房 P 的接入服务器，能支持 B 集合中的至少一种加密套件，不支持 A 集合中的所有加密套件；
4. 机房 Q 的接入服务器，既支持 A 集合中的至少一种加密套件，也支持 B 集合中的至少一种加密套件；

最终导致 问题 App 无法通过 机房 P 中的服务器 访问该站点。

2.3.3 小结

从上面的分析结论可以看到，由于客户端和服务端加密套件不匹配，导致在特定情况下的握手失败。进一步的问题解决方案包括：

调整客户端加密套件，增加支持的 Cipher Suites（涉及客户端底层 TLS/SSL 库的升级）；

调整服务端加密套件，增加支持的 Cipher Suites（涉及服务端 TLS/SSL 接入配置）。

该客户最终选择调整服务端加密套件，问题得到解决。

3.总结

从上述案例的分享和实践中可以看到，TLS 层面的问题在客户端的症状表现上有相似之处，但是问题的根因却大相径庭。这里例举的问题虽不能覆盖所有的问题场景，但可以看到基本的排查思路如下：

判断问题是否属于 TLS/SSL 层面的问题。

抓取网络包；有条件的情况下，可以针对正常和异常情况抓取两份网络包，以便后续进行对比分析。

根据网络包探寻问题发生的直接原因，进而进一步探究问题的根本原因。

根据分析结论并结合业务场景，选择合适的解决方案。

这类问题的排查基础是对 HTTPS 和 TLS/SSL 协议的理解以及对分析工具的掌握。在移动领域，这类问题存在一定的共性，直接了解上述结论和分析方法可以帮助开发者快速“出坑”。