关于react.js:搞定客户端证书错误看这篇就够了

简介： TLS/SSL 握手失败引起的连贯异样问题怎么搞？阿里云 SRE 工程师手把手带你排查解决。

1.TLS/SSL 握手根本流程

* 图片来源于网络

2. 案例分享

2.1CFCA 证书的历史问题

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 及以上版本才实现入根接入。

* 参考:https://www.cfca.com.cn/upload/20161101.pdf

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 去做证书链的校验。

* 参考：https://tools.ietf.org/html/rfc3280#section-4.2.2.1；https://developer.android.com/training/articles/security-ssl#UnknownCa

因而，当两头 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 中的服务器提供接入服务），能够失常拜访。针对这这两种失常状况进行抓包和进一步剖析。

通过对三种状况的网络察看发现：

1. 问题 App 收回的 Client Hello 显示反对 17 种加密套件：

1. 失常 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 协定的了解以及对剖析工具的把握。在挪动畛域，这类问题存在肯定的共性，间接理解上述论断和分析方法能够帮忙开发者疾速“出坑”。

参考

• 如何抓取网络包，https://help.aliyun.com/document_detail/159169.html
• Security with HTTPS and SSL，https://developer.android.com/training/articles/security-ssl
• Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile，https://tools.ietf.org/html/rfc5280

彩（广）蛋（告）

针对市面上挪动利用普遍存在的破解、篡改、盗版、钓⻥欺诈、内存调试、数据窃取等各类平安危险，mPaaS「挪动平安加固」依赖于阿里云团体的挪动平安加固技术，经验了淘系等亿级利用的安全性考验。

可能无效为挪动利用提供稳固、简略、无效的平安爱护，进步 App 的整体平安程度，力保利用不被逆向破解，在安全性上具备十分牢靠的保障。

原文链接
本文为阿里云原创内容，未经容许不得转载。