**於網路
2.1 cfca 證書的歷史問題
2.1.1背景
客戶端除錯發現，控制台會看到證書無效的錯誤資訊（invalid certificate 或 certificate unknown ）。
2.1.2 排查
起初，工程師並不知道客戶的證書是由哪個機構簽發以及有什麼問題。而對於這類問題，一般均需要客戶端網路包做進一步的分析與判斷。因此安排客戶在受影響的裝置上進行問題復現及客戶端抓包操作。
獲取到網路包後，首先確認了客戶端連線失敗的直接原因為 tls 握手過程異常終止，見下：
檢視 encrypted alert 內容，錯誤資訊為 0x02 0x2e。根據 tls 1.2 協議（rfc5246 ）的定義， 該錯誤為因為 certificate_unknown。
回到存在問題的手機裝置上（android 5.1），檢查系統內建的受信任 ca 根證書列表，未能找到 cfca ev root ca 證書；而在正常連線的手機上，可以找到該 ca 的根證書並預設設定為」信任「。
查閱 cfca 證書的相關說明，該機構的證書在 ios 10.1 及 android 6.0 及以上版本才完成入根接入。
2.1.3小結
從上面的分析可以看到，該問題的根因是低版本客戶端裝置沒有內建 cfca 的 ca 根證書。因此，基本的解決方案包括：
更換其他 ca 機構簽發的證書，保證其 ca 根證書的在特定裝置上已預設信任。
手動在受影響的裝置上安裝該 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 去做證書鏈的校驗。
2.2.3 小結
**層面手動定製 trustmanager 去定製校驗過程；
或重新打包證書，將中間 ca 證書和根 ca 證書一同打包到服務端證書中。
該客戶綜合開發成本與環境現狀，選擇重新打包證書。新的證書配置完成後，問題得到解決。
2.3 加密套件協商引起的問題
2.3.1 背景
2.3.2 排查
由於該問題直接表現在 web 層，因此首先嘗試通過 charles 抓取 http 層包進行分析。http 日誌發現相關 http 請求並未發出。
由此懷疑問題發生在 tcp 層，進而在受影響的裝置上進行問題復現及客戶端抓包操作。
獲取到網路包後，首先確認問題：
通過頁面網域名稱在網路包中尋找 dns 解析結果；
根據 dns 解析結果找到站點 ip，並過濾出客戶端與該 ip 之間的訪問情況；
觀察客戶端與該伺服器之間的網路活動，發現存在 tls 握手失敗的情況：
從上面的網路包可以看到，服務端（機房 p 中的伺服器提供接入服務）在收到 client hello 後，直接返回了 handshake failure，這種情況下，一般需要服務端配合排查握手失敗的直接原因。在客戶端條件下，可以進一步縮小排查疑點。
重新考慮客戶問題條件：相同的網路條件下，系統瀏覽器可以開啟該頁面；同一裝置切換到另一運營商下（站點此時由機房 q 中的伺服器提供接入服務），可以正常訪問。針對這這兩種正常情況進行抓包和進一步分析。
通過對三種情況的網路觀察發現：
根據上述情況，可以推論問題的基本情況為：
機房 p 的接入伺服器，能支援 b 集合中的至少一種加密套件，不支援 a 集合中的所有加密套件；
機房 q 的接入伺服器，既支援 a 集合中的至少一種加密套件，也支援 b 集合中的至少一種加密套件；
2.3.3 小結
從上面的分析結論可以看到，由於客戶端和服務端加密套件不匹配，導致在特定情況下的握手失敗。進一步的問題解決方案包括：
調整客戶端加密套件，增加支援的 cipher suites（涉及客戶端底層 tls/ssl 庫的公升級）；
調整服務端加密套件，增加支援的 cipher suites（涉及服務端 tls/ssl 接入配置）。
該客戶最終選擇調整服務端加密套件，問題得到解決。
從上述案例的分享和實踐中可以看到，tls 層面的問題在客戶端的症狀表現上有相似之處，但是問題的根因卻大相徑庭。這裡例舉的問題雖不能覆蓋所有的問題場景，但可以看到基本的排查思路如下：
判斷問題是否屬於 tls/ssl 層面的問題。
抓取網路包；有條件的情況下，可以針對正常和異常情況抓取兩份網路包，以便後續進行對比分析。
根據網路包探尋問題發生的直接原因，進而進一步**問題的根本原因。
根據分析結論並結合業務場景，選擇合適的解決方案。
這類問題的排查基礎是對 https 和 tls/ssl 協議的理解以及對分析工具的掌握。在移動領域，這類問題存在一定的共性，直接了解上述結論和分析方法可以幫助開發者快速「出坑」。
iis https 客戶端證書
1 自建根證書 makecert r pe n cn webssltestroot b 12 22 2013 e 12 23 2024 ss root sr localmachine len 2048 2 建 用的證書 makecert pe n cn www.aaa.com b 12 22 201...
ASIHTTPRequest 客戶端證書支援
有時伺服器要求提供客戶端證書，從1.8版本開始，你可以隨request傳送證書。1 2 3 4 5 will send the certificate attached to the identity identity is a secidentityref requestsetclientcert...
ASIHTTPRequest 客戶端證書支援
有時伺服器要求提供客戶端證書，從1.8版本開始，你可以隨request傳送證書。1 2 3 4 5 will send the certificate attached to the identity identity is a secidentityref requestsetclientcert...