客戶端證書錯誤避坑指南

1.背景

HTTPS作爲站點安全的最佳實踐之一，已經得到了最廣泛的支持。然而在實際生產過程中，由TLS/SSL握手失敗引起的連接異常問題依然十分常見。本文將結合mPaaS（https://www.aliyun.com/product/mpaas）客戶端實際排查案例，介紹這類問題在移動領域的排查和解決方案。

2. TLS/SSL握手基本流程

HTTPS的主要作用是在不安全的網絡上創建一個基於TLS/SSL協議的安全信道，對竊聽和中間人攻擊提供一定程度的合理防護。TLS/SSL握手的基本流程如下圖描述：

圖1：TLS/SSL握手基本流程圖

3.案例分享

3.1 CFCA證書的歷史問題

3.1.1背景

某客戶爲其生產環境的站點申請了一張由CFCA（https://www.cfca.com.cn/）簽發的證書。相關域名正確配置該證書且啓用HTTPS後，經測試發現他們的客戶端App在低版本手機上（iOS<10.0，Android<6.0）無法連接到相關站點。
客戶端調試發現，控制檯會看到證書無效的錯誤信息（Invalid Certificate或Certificate Unknown）。

3.1.2排查

起初，工程師並不知道客戶的證書是由哪個機構簽發以及有什麼問題。而對於這類問題，一般均需要對客戶端網絡包做進一步的分析與判斷。因此安排客戶在受影響的設備上進行問題復現及客戶端抓包操作。

（1）獲取到網絡包後，首先確認了客戶端連接失敗的直接原因爲TLS握手過程異常終止，見下：

圖2：客戶端連接失敗抓包分析結果

（2）查看Encrypted Alert內容，錯誤信息爲0x02 0x2E。根據TLS 1.2協議（RFC5246，https://tools.ietf.org/html/rfc5246#page-69）的定義，該錯誤是因爲certificate_unknown。

（3）繼續查看該證書的具體信息，根據Server Hello幀中攜帶的證書信息得知該證書由證書機構China Financial Certification Authority(CFCA)簽發。再根據證書信息中的Authority Information Access (AIA)信息確認Intermediate CA和Root CA證書。確認該證書籤發機構的根證書爲CFCA EV ROOT。

（4）回到存在問題的手機設備上（Android 5.1），檢查系統內置的受信任CA根證書列表，未能找到CFCA EV ROOT CA證書；而在正常連接的手機上，可以找到該CA的根證書並默認設置爲“信任”。

（5）查閱CFCA證書的相關說明，該機構的證書在iOS 10.1及Android 6.0及以上版本才完成入根接入（參考https://www.cfca.com.cn/upload/20161101.pdf）：

圖3：CFCA證書的版本支持說明

3.1.3小結

從上面的分析可以看到，該問題的根因是低版本客戶端設備沒有內置CFCA的CA根證書。因此，基本的解決方案包括：

（1）更換其他CA機構簽發的證書，保證其CA根證書的在特定設備上已默認信任。

（2）手動在受影響的設備上安裝該CA根證書及中間證書，並配置爲信任狀態。

（3）客戶端App預置該CA根證書，並通過客戶端代碼配置信任該證書。

需要結合不同的業務場景選擇合理解決方案。

3.2證書鏈信任模式引起的問題

3.2.1背景

某客戶新增了一個容災備用接入地址，啓用了一個新的域名並配置了一張全新的證書。測試發現，切換到該備用地址時，Android客戶端無法正常連接，報證書未知錯誤（Certificate Unknown）；iOS客戶端表現正常。

3.2.2排查

和上一個問題類似，首先在受影響的設備上進行問題復現及客戶端抓包操作。

（1）獲取到網絡包之後，確認了客戶端連接失敗的直接原因爲TLS握手過程異常終止，原因與上一個問題一樣，爲Certificate Unknown：

圖4：客戶端連接失敗抓包分析結果

（2）類似上一個問題的排查動作，查看該證書的CA根證書及根證書的信任情況。發現該證書由中間CA機構Secure Site Pro CA G2簽發，其根CA爲DigiCert Global Root CA：

圖5：證書籤發機構排查結果

圖6：根CA排查結果

（3）DigiCert Global Root CA作爲一個廣泛支持的證書籤發機構，其根CA證書在絕大多數的設備上均爲受信任狀態，這一點在受影響的設備上也得到了確認。既然根CA的證書處於信任狀態，爲何證書驗證還是失敗？這成爲下一步排查的重點方向。

（4）同一臺設備，切換到正常環境下，也完成一次抓包操作。獲取到新的網絡包後做對比分析，發現兩種情況下網絡包中體現的區別爲：

• 正常環境下，服務器返回的證書包含了完整的CA證書鏈；
• 而異常情況下，服務端返回的證書僅包含葉節點CA證書。
  

  圖7：正常環境下服務器返回完整CA證書鏈

圖8：異常環境下服務端返回僅包含葉節點CA證書

（5）根據上述線索進行排查研究，發現：不同於其他平臺，Android客戶端默認是不會通過AIA Extension去做證書鏈的校驗（AIA機制參考https://tools.ietf.org/html/rfc3280#section-4.2.2.1）。因此，當中間CA證書未安裝或未緩存時，客戶端App是不會主動拉取中間CA證書並做進一步信任鏈校驗的，參考https://developer.android.com/training/articles/security-ssl#UnknownCa，從而導致證書校驗失敗。

3.2.3小結

從上面的排查分析看到，該問題和Android平臺自身的證書校驗機制和證書打包方式相關。解決方案包括：

（1）代碼層面手動定製TrustManager去定製校驗過程；

（2）或重新打包證書，將中間CA證書和根CA證書一同打包到服務端證書中。

該客戶綜合開發成本與環境現狀，選擇重新打包證書。新的證書配置完成後，問題得到解決。

3.3加密套件協商引起的問題

3.3.1背景

某客戶反饋他們的iOS客戶端App用戶在特定運營商網絡環境下無法打開特定的業務站點（HTTPS站點）。客戶端處於白屏等待狀態並最終報錯；而在同樣的網絡環境下，系統瀏覽器可以打開該站點；同一臺設備，切換到另一個網絡運營商下，也可以訪問該站點。

3.3.2排查

（1）由於該問題直接表現在Web層，因此首先嚐試通過Charles抓取HTTP層包進行分析。HTTP日誌發現相關HTTP請求並未發出。

（2）由此懷疑問題發生在TCP層，進而在受影響的設備上進行問題復現及客戶端抓包操作。

（3）獲取到網絡包後，首先確認問題：

1. 通過頁面域名在網絡包中尋找DNS解析結果；
2. 根據DNS解析結果找到站點IP，並過濾出客戶端與該IP之間的訪問情況；
3. 觀察客戶端與該服務器之間的網絡活動，發現存在TLS握手失敗的情況：
   

   圖9：抓包分析發現TLS握手失敗情況

（4）從上面的網絡包可以看到，服務端（機房P中的服務器提供接入服務）在收到Client Hello後，直接返回了Handshake Failure，這種情況下，一般需要服務端配合排查握手失敗的直接原因。在客戶端條件下，可以進一步縮小排查疑點。

（5）重新考慮客戶問題條件：相同的網絡條件下，系統瀏覽器可以打開該頁面；同一設備切換到另一運營商下（站點此時由機房Q中的服務器提供接入服務），可以正常訪問。針對這兩種正常情況進行抓包和進一步分析。

（6）通過對三種情況的網絡觀察發現：

1. 問題App發出的Client Hello顯示支持17種加密套件：
   

   圖10：問題app發出的Client Hello顯示支持17種加密套件

2. 正常App發出的Client Hello顯示支持26種加密套件：
   

   圖11：正常App發出的Client Hello顯示支持26種加密套件

3. 正常App和機房P服務器協商的加密套件爲：TLS_RAS_WITH_3DES_EDE_CBC_SHA (0x000a)（不在問題App支持的加密套件範圍內）；
4. 問題App和機房Q服務器協商的加密套件爲：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)（在問題App支持的加密套件範圍內）；

（7）根據上述情況，可以推論問題的基本情況爲：

• 問題App發出去的握手請求，支持17種加密套件（A集合）；
• 正常App發出去的握手請求，支持26種加密套件（B集合）；
• 機房P的接入服務器，能支持B集合種的至少一種加密套件，不支持A集合中的所有加密套件；
• 機房Q的接入服務器，既支持A集合中的至少一種加密套件，也支持B集合中的至少一種加密套件；
• 最終導致問題App無法通過機房P中的服務器訪問該站點。

3.3.3小結

從上面的分析結論可以看到，由於客戶端和服務端加密套件不匹配，導致在特定情況下的握手失敗。進一步的問題解決方案包括：

（1）調整客戶端加密套件，增加支持的Cipher Suites（涉及客戶端底層TLS/SSL庫的升級）；

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

該客戶最終選擇調整服務端加密套件，問題得到解決。

4.總結

從上述案例的分享和實踐中可以看到，TLS層面的問題在客戶端的症狀表現上有相似之處，但是問題的根因卻大相徑庭。這裏列舉的問題雖不能覆蓋所有的問題場景，但可以看到基本的排查思路如下：
（1）判斷問題是否屬於TLS/SSL層面的問題。

（2）抓取網絡包；有條件的情況下，可以針對正常和異常情況抓取兩份網絡包，以便後續進行對比分析。

（3）根據網絡包探尋問題發生的直接原因，進而進一步探究問題的根本原因。

（4）根據分析結論並結合業務場景，選擇合適的解決方案。

這類問題的排查基礎是對HTTPS和TLS/SSL協議的理解以及對分析工具的掌握。在移動領域，這類問題存在一定的共性，直接瞭解上述結論和分析方法可以幫助開發者快速“出坑”。

參考資料：
（1）如何抓取網絡包，https://help.aliyun.com/document_detail/159169.html
（2）Security with HTTPS and SSL，https://developer.android.com/training/articles/security-ssl
（3）Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile， https://tools.ietf.org/html/rfc5280

作者：王愈

阿里雲智能GTS-SRE團隊金融線技術服務經理

曾就職於微軟全球技術服務中心，互聯網開發支持服務部。現在就職於阿里雲智能 SRE金融線技術服務經理團隊，主要負責金融線客戶的移動開發（mPaaS）解決方案、開發諮詢等工作。

我們是阿里雲智能全球技術服務-SRE團隊，我們致力成爲一個以技術爲基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。