搞定客户端证书错误，看这篇就够了
簡(jiǎn)介：?TLS/SSL 握手失敗引起的連接異常問(wèn)題怎么搞？阿里云 SRE 工程師手把手帶你排查解決。
1.TLS/SSL 握手基本流程
*圖片來(lái)源于網(wǎng)絡(luò)
2.案例分享
2.1CFCA 證書(shū)的歷史問(wèn)題
2.1.1背景
某客戶(hù)為其生產(chǎn)環(huán)境的站點(diǎn)申請(qǐng)了一張由 CFCA 簽發(fā)的證書(shū)。相關(guān)域名正確配置該證書(shū)且啟用 HTTPS 后，經(jīng)測(cè)試發(fā)現(xiàn)他們的客戶(hù)端 App 在低版本手機(jī)上（ iOS < 10.0，Android < 6.0）無(wú)法連接到相關(guān)站點(diǎn)。
客戶(hù)端調(diào)試發(fā)現(xiàn)，控制臺(tái)會(huì)看到證書(shū)無(wú)效的錯(cuò)誤信息（Invalid Certificate 或 Certificate Unknown ）。
2.1.2排查
起初，工程師并不知道客戶(hù)的證書(shū)是由哪個(gè)機(jī)構(gòu)簽發(fā)以及有什么問(wèn)題。而對(duì)于這類(lèi)問(wèn)題，一般均需要客戶(hù)端網(wǎng)絡(luò)包做進(jìn)一步的分析與判斷。因此安排客戶(hù)在受影響的設(shè)備上進(jìn)行問(wèn)題復(fù)現(xiàn)及客戶(hù)端抓包操作。
獲取到網(wǎng)絡(luò)包后，首先確認(rèn)了客戶(hù)端連接失敗的直接原因?yàn)?TLS 握手過(guò)程異常終止，見(jiàn)下：
查看 Encrypted Alert 內(nèi)容，錯(cuò)誤信息為 0x02 0x2E。根據(jù) TLS 1.2 協(xié)議（RFC5246 ）的定義， 該錯(cuò)誤為因?yàn)?certificate_unknown。
繼續(xù)查看該證書(shū)的具體信息，根據(jù) Server Hello 幀中攜帶的證書(shū)信息得知該證書(shū)由證書(shū)機(jī)構(gòu) China Financial Certification Authority(CFCA) 簽發(fā)。再根據(jù)證書(shū)信息中的 Authority Information Access (AIA) 信息確認(rèn) Intermediate CA 和 Root CA 證書(shū)。確認(rèn)該證書(shū)簽發(fā)機(jī)構(gòu)的根證書(shū)為 CFCA EV ROOT。
回到存在問(wèn)題的手機(jī)設(shè)備上（Android 5.1），檢查系統(tǒng)內(nèi)置的受信任 CA 根證書(shū)列表，未能找到 CFCA EV ROOT CA 證書(shū)；而在正常連接的手機(jī)上，可以找到該 CA 的根證書(shū)并默認(rèn)設(shè)置為”信任“。
查閱 CFCA 證書(shū)的相關(guān)說(shuō)明，該機(jī)構(gòu)的證書(shū)在 iOS 10.1 及 Android 6.0 及以上版本才完成入根接入。
*參考:https://www.cfca.com.cn/upload/20161101.pdf
2.1.3小結(jié)
從上面的分析可以看到，該問(wèn)題的根因是低版本客戶(hù)端設(shè)備沒(méi)有內(nèi)置 CFCA 的 CA 根證書(shū)。因此，基本的解決方案包括：
需要結(jié)合不同的業(yè)務(wù)場(chǎng)景選擇合理解決方案。
2.2證書(shū)鏈信任模式引起的問(wèn)題
2.2.1背景
某客戶(hù)新增了一個(gè)容災(zāi)備用接入地址，啟用了一個(gè)新的域名并配置了一張全新的證書(shū)。測(cè)試發(fā)現(xiàn)，切換到該備用地址時(shí)，Android 客戶(hù)端無(wú)法正常連接，報(bào)證書(shū)未知錯(cuò)誤（Certificate Unknown）；iOS 客戶(hù)端表現(xiàn)正常。
2.2.2排查
和 2.1 的問(wèn)題類(lèi)似，首先在受影響的設(shè)備上進(jìn)行問(wèn)題復(fù)現(xiàn)及客戶(hù)端抓包操作。
獲取到網(wǎng)絡(luò)包之后，確認(rèn)了客戶(hù)端連接失敗的直接原因?yàn)?TLS 握手過(guò)程異常終止，原因與 2.1 中的問(wèn)題一樣，為Certificate Unknown ：
類(lèi)似問(wèn)題 2.1 的排查動(dòng)作，查看該證書(shū)的 CA 根證書(shū)及根證書(shū)的信任情況。
發(fā)現(xiàn)該證書(shū)由中間 CA 機(jī)構(gòu) Secure Site Pro CA G2 簽發(fā)，其根 CA 為 DigiCert Global Root CA:
DigiCert Global Root CA 作為一個(gè)廣泛支持的證書(shū)簽發(fā)機(jī)構(gòu)，其根 CA 證書(shū)在絕大多數(shù)的設(shè)備上均為受信任狀態(tài)，這一點(diǎn)在受影響的設(shè)備上也得到了確認(rèn)。既然根 CA 的證書(shū)處于信任狀態(tài)，為何證書(shū)驗(yàn)證還是失敗？這成為下一步排查的重點(diǎn)方向。
同一臺(tái)設(shè)備，切換到正常環(huán)境下，也完成一次抓包操作。獲取到新的網(wǎng)絡(luò)包后做對(duì)比分析，發(fā)現(xiàn)兩種情況下網(wǎng)絡(luò)包中體現(xiàn)的區(qū)別為：
正常環(huán)境下，服務(wù)器返回的證書(shū)包含了完整的 CA 證書(shū)鏈；
異常情況下，服務(wù)端返回的證書(shū)僅包含葉節(jié)點(diǎn) CA 證書(shū)。
根據(jù)上述線索進(jìn)行排查研究，發(fā)現(xiàn)：不同于其他平臺(tái)，Android 客戶(hù)端默認(rèn)是不會(huì)通過(guò) AIA Extension 去做證書(shū)鏈的校驗(yàn)。
*參考：https://tools.ietf.org/html/rfc3280#section-4.2.2.1?；https://developer.android.com/training/articles/security-ssl#UnknownCa
因此，當(dāng)中間 CA 證書(shū)未安裝或未緩存時(shí)，客戶(hù)端 App 是不會(huì)主動(dòng)拉取中間 CA 證書(shū)并做進(jìn)一步信任鏈校驗(yàn)的，從而導(dǎo)致證書(shū)校驗(yàn)失敗。
2.2.3小結(jié)
從上面的排查分析看到，該問(wèn)題和 Android 平臺(tái)自身的證書(shū)校驗(yàn)機(jī)制和證書(shū)打包方式相關(guān)。解決方案包括：
代碼層面手動(dòng)定制 TrustManager 去定制校驗(yàn)過(guò)程；
或重新打包證書(shū)，將中間 CA 證書(shū)和根 CA 證書(shū)一同打包到服務(wù)端證書(shū)中。
該客戶(hù)綜合開(kāi)發(fā)成本與環(huán)境現(xiàn)狀，選擇重新打包證書(shū)。新的證書(shū)配置完成后，問(wèn)題得到解決。
2.3加密套件協(xié)商引起的問(wèn)題
2.3.1背景
某客戶(hù)反饋他們的 iOS 客戶(hù)端 App 用戶(hù)在特定運(yùn)營(yíng)商網(wǎng)絡(luò)環(huán)境下無(wú)法打開(kāi)特定的業(yè)務(wù)站點(diǎn)（HTTPS 站點(diǎn)）。客戶(hù)端處于白屏等待狀態(tài)并最終報(bào)錯(cuò)；而在同樣的網(wǎng)絡(luò)環(huán)境下，系統(tǒng)瀏覽器可以打開(kāi)該站點(diǎn)；同一臺(tái)設(shè)備，切換到另一個(gè)網(wǎng)絡(luò)運(yùn)營(yíng)商下，也可以訪問(wèn)該站點(diǎn)。
2.3.2排查
由于該問(wèn)題直接表現(xiàn)在 Web 層，因此首先嘗試通過(guò) Charles 抓取 HTTP 層包進(jìn)行分析。HTTP 日志發(fā)現(xiàn)相關(guān) HTTP 請(qǐng)求并未發(fā)出。
由此懷疑問(wèn)題發(fā)生在 TCP 層，進(jìn)而在受影響的設(shè)備上進(jìn)行問(wèn)題復(fù)現(xiàn)及客戶(hù)端抓包操作。
獲取到網(wǎng)絡(luò)包后，首先確認(rèn)問(wèn)題：
從上面的網(wǎng)絡(luò)包可以看到，服務(wù)端（機(jī)房 P 中的服務(wù)器提供接入服務(wù)）在收到 Client Hello 后，直接返回了 Handshake Failure，這種情況下，一般需要服務(wù)端配合排查握手失敗的直接原因。在客戶(hù)端條件下，可以進(jìn)一步縮小排查疑點(diǎn)。
重新考慮客戶(hù)問(wèn)題條件：相同的網(wǎng)絡(luò)條件下，系統(tǒng)瀏覽器可以打開(kāi)該頁(yè)面；同一設(shè)備切換到另一運(yùn)營(yíng)商下（站點(diǎn)此時(shí)由機(jī)房 Q 中的服務(wù)器提供接入服務(wù)），可以正常訪問(wèn)。針對(duì)這這兩種正常情況進(jìn)行抓包和進(jìn)一步分析。
通過(guò)對(duì)三種情況的網(wǎng)絡(luò)觀察發(fā)現(xiàn)：
根據(jù)上述情況，可以推論問(wèn)題的基本情況為：
最終導(dǎo)致 問(wèn)題 App 無(wú)法通過(guò) 機(jī)房 P 中的服務(wù)器 訪問(wèn)該站點(diǎn)。
2.3.3 小結(jié)
從上面的分析結(jié)論可以看到，由于客戶(hù)端和服務(wù)端加密套件不匹配，導(dǎo)致在特定情況下的握手失敗。進(jìn)一步的問(wèn)題解決方案包括：
調(diào)整客戶(hù)端加密套件，增加支持的 Cipher Suites（涉及客戶(hù)端底層 TLS/SSL 庫(kù)的升級(jí)）；
調(diào)整服務(wù)端加密套件，增加支持的 Cipher Suites（涉及服務(wù)端 TLS/SSL 接入配置）。
該客戶(hù)最終選擇調(diào)整服務(wù)端加密套件，問(wèn)題得到解決。
3.總結(jié)
從上述案例的分享和實(shí)踐中可以看到，TLS 層面的問(wèn)題在客戶(hù)端的癥狀表現(xiàn)上有相似之處，但是問(wèn)題的根因卻大相徑庭。這里例舉的問(wèn)題雖不能覆蓋所有的問(wèn)題場(chǎng)景，但可以看到基本的排查思路如下：
判斷問(wèn)題是否屬于 TLS/SSL 層面的問(wèn)題。
抓取網(wǎng)絡(luò)包；有條件的情況下，可以針對(duì)正常和異常情況抓取兩份網(wǎng)絡(luò)包，以便后續(xù)進(jìn)行對(duì)比分析。
根據(jù)網(wǎng)絡(luò)包探尋問(wèn)題發(fā)生的直接原因，進(jìn)而進(jìn)一步探究問(wèn)題的根本原因。
根據(jù)分析結(jié)論并結(jié)合業(yè)務(wù)場(chǎng)景，選擇合適的解決方案。
這類(lèi)問(wèn)題的排查基礎(chǔ)是對(duì) HTTPS 和 TLS/SSL 協(xié)議的理解以及對(duì)分析工具的掌握。在移動(dòng)領(lǐng)域，這類(lèi)問(wèn)題存在一定的共性，直接了解上述結(jié)論和分析方法可以幫助開(kāi)發(fā)者快速“出坑”。
參考
- 如何抓取網(wǎng)絡(luò)包，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
彩（廣）蛋（告）
針對(duì)市面上移動(dòng)應(yīng)用普遍存在的破解、篡改、盜版、釣?欺詐、內(nèi)存調(diào)試、數(shù)據(jù)竊取等各類(lèi)安全風(fēng)險(xiǎn)，mPaaS 「移動(dòng)安全加固」依賴(lài)于阿里云集團(tuán)的移動(dòng)安全加固技術(shù)，經(jīng)歷了淘系等億級(jí)應(yīng)用的安全性考驗(yàn)。
能夠有效為移動(dòng)應(yīng)用提供穩(wěn)定、簡(jiǎn)單、有效的安全保護(hù)，提高 App 的整體安全水平，力保應(yīng)用不被逆向破解，在安全性上具有非常可靠的保障。
?
?
?
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的搞定客户端证书错误，看这篇就够了的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： PolarDB-X 2.0：使用一个透明
- 下一篇： 浅谈RSocket与响应式编程