1. 引言

????????本周二長(zhǎng)城項(xiàng)目在收尾過(guò)程中，出現(xiàn)了一個(gè)車(chē)端無(wú)法進(jìn)行注冊(cè)的問(wèn)題：curl提示證書(shū)認(rèn)證失敗（其實(shí)已經(jīng)能確認(rèn)問(wèn)題方向了，運(yùn)維人員去確認(rèn)證書(shū)問(wèn)題即可）。雖然最終的原因是由于長(zhǎng)城運(yùn)維人員導(dǎo)致的。但是這個(gè)過(guò)程讓我頗受“感動(dòng)“。

1. 問(wèn)題出現(xiàn)的當(dāng)天，運(yùn)維人員沒(méi)有思路，導(dǎo)致現(xiàn)場(chǎng)測(cè)試，開(kāi)發(fā)人員一起調(diào)試到晚上10點(diǎn)。
2. 當(dāng)我們咨詢(xún)長(zhǎng)城人員是否對(duì)服務(wù)器進(jìn)行修改時(shí)，由于我們并不能明確說(shuō)明問(wèn)題點(diǎn)。導(dǎo)致客戶(hù)一直不會(huì)主動(dòng)去響應(yīng)。（屬于雙方的問(wèn)題）
3. 問(wèn)題定位的不明確。導(dǎo)致項(xiàng)目經(jīng)理問(wèn)題推進(jìn)不順利以及消耗我們內(nèi)部許多資源。（屬于我們技術(shù)支持不到位）

????????經(jīng)過(guò)此事，我覺(jué)得打鐵還需自身硬。雖然問(wèn)題的原因是因?yàn)榭蛻?hù)做了修改。但是我們卻一直不能定位到問(wèn)題。這就屬于我們的能力問(wèn)題了。

????????本文，主要是想分享一下該問(wèn)題的分析思路，以及證書(shū)認(rèn)證相關(guān)的知識(shí)。希望能對(duì)同事們有所幫助。

2. 問(wèn)題復(fù)現(xiàn)過(guò)程

問(wèn)題日志截圖如下：

圖一：車(chē)端注冊(cè)，平臺(tái)反饋失敗

從圖中，我們可以得出，curl 錯(cuò)誤碼51（認(rèn)證失敗）。

應(yīng)對(duì)措施：請(qǐng)運(yùn)維人員進(jìn)行證書(shū)相關(guān)的排查。

????????運(yùn)維人員進(jìn)行了操作之后，得出結(jié)論：并沒(méi)有對(duì)證書(shū)進(jìn)行修改，并且他自己通過(guò)curl 指令，在服務(wù)器中是可以訪問(wèn)成功的。如圖：

圖二：運(yùn)維人員在服務(wù)器上，進(jìn)行驗(yàn)證

????????之后就沒(méi)有下文，問(wèn)題就卡住了（當(dāng)時(shí)我的內(nèi)心是崩潰的）。我用同樣的根證書(shū)，客戶(hù)端證書(shū)，客戶(hù)端密鑰，都是無(wú)法訪問(wèn)成功的（拒絕連接）。后來(lái)我猜測(cè)應(yīng)該是平臺(tái)當(dāng)時(shí)建立了路由規(guī)則，可惜沒(méi)辦法驗(yàn)證了。

圖三:嘗試連接OTA 平臺(tái)服務(wù)器，卻被拒絕訪問(wèn)

????????問(wèn)題掛在這里，過(guò)了幾天，客戶(hù)終于重視了這個(gè)問(wèn)題，派了對(duì)方的運(yùn)維人員進(jìn)行查看?；税雮€(gè)小時(shí)，問(wèn)題就解決掉了。

圖四：客戶(hù)問(wèn)題定位

????????雖然定位的不一定準(zhǔn)確，但是可以確定的是：服務(wù)器的根證書(shū)有問(wèn)題。

????????經(jīng)過(guò)此事，我花了點(diǎn)時(shí)間，查閱網(wǎng)上資料，以及請(qǐng)問(wèn)通知，總結(jié)了https 認(rèn)證過(guò)程中的一些知識(shí)點(diǎn)?？偨Y(jié)之后，感覺(jué)之前還是自己知識(shí)面窄了，導(dǎo)致浪費(fèi)了不少的資源。

3. 知識(shí)點(diǎn)總結(jié)

3.1 ?名詞介紹

對(duì)于初學(xué)者，建議先了解一下名詞。

名詞	解釋
證書(shū)	SSL協(xié)議中的證書(shū)，其主要功能有兩點(diǎn)。 1.??? 身份驗(yàn)證 2.??? 數(shù)據(jù)加密傳輸 因此證書(shū)中一般包含以下信息：公鑰，持有者信息，證書(shū)認(rèn)證機(jī)構(gòu)的CA信息，證書(shū)有效期等。
單向認(rèn)證	單項(xiàng)認(rèn)證是我們平時(shí)用的比較多的訪問(wèn)方式。比如我們?cè)L問(wèn)百度網(wǎng)站，采用的就是單項(xiàng)認(rèn)證。瀏覽器只需要認(rèn)證服務(wù)端的合法性即可。
雙向認(rèn)證	顧名思義，客戶(hù)端不僅要驗(yàn)證服務(wù)器的合法性。服務(wù)器也要驗(yàn)證客戶(hù)端的合法性。
證書(shū)鏈	一個(gè)證書(shū)列表，若對(duì)端證書(shū)授權(quán)于列表中其一，則認(rèn)為對(duì)端證書(shū)可信
根證書(shū)	根證書(shū)其實(shí)就是CA認(rèn)證中心的一種體現(xiàn)。若本地信任該證書(shū)，即表明信任該CA認(rèn)證中心相關(guān)的下屬證書(shū)。
自簽證書(shū)	用自己生成的根證書(shū)，簽發(fā)證書(shū)。但是這種證書(shū)對(duì)于一般的平臺(tái)是不可信的。
商簽證書(shū)	與自簽證書(shū)相反。使用的是商業(yè)根證書(shū)，簽發(fā)證書(shū)。由于商業(yè)根證書(shū)一般是被大眾所信任的。根據(jù)證書(shū)鏈的原理，簽發(fā)的證書(shū)也就被信任。

3.2 單向認(rèn)證和雙向認(rèn)證

????????我們?cè)诓煌捻?xiàng)目中，與平臺(tái)之間的交互形式是不一樣的。有單向認(rèn)證和雙向認(rèn)證。

3.2.1 單向認(rèn)證

????????單向認(rèn)證的過(guò)程：客戶(hù)端從服務(wù)端下載服務(wù)器端公鑰證書(shū)，依據(jù)自己本地證書(shū)鏈，進(jìn)行驗(yàn)證。若驗(yàn)證成功，則建立安全通信通道。

服務(wù)端需要保存公鑰證書(shū)和私鑰兩個(gè)文件?？蛻?hù)端只需要保存證書(shū)鏈即可。

圖五：單向認(rèn)證流程

3.2.2 雙向認(rèn)證

????????雙向認(rèn)證的過(guò)程：客戶(hù)端除了需要將服務(wù)端的公鑰證書(shū)下載，與本地證書(shū)鏈進(jìn)行驗(yàn)證外。還需要將客戶(hù)端的公鑰證書(shū)上傳到服務(wù)端，服務(wù)端用自己的根證書(shū)進(jìn)行驗(yàn)證，等雙方都認(rèn)證通過(guò)了，才開(kāi)始進(jìn)行數(shù)據(jù)傳輸。

????????服務(wù)端需要保存根證書(shū)（用于校驗(yàn)客戶(hù)端證書(shū)的合法性），服務(wù)器的公鑰證書(shū)，服務(wù)器的密鑰文件。客戶(hù)端需要保存客戶(hù)端證書(shū)文件，客戶(hù)端密鑰文件，客戶(hù)端證書(shū)鏈。

圖六：雙向認(rèn)證流程

3.2.3 牛刀小試

當(dāng)了解認(rèn)證的流程后，我們可以自己做一個(gè)自簽證書(shū)流程，以加深印象。從上面的內(nèi)容中，我們知道需要用到六個(gè)證書(shū)。

• 服務(wù)器端公鑰證書(shū)：server.crt
• 服務(wù)器端私鑰文件：server.key
• 根證書(shū)：root.crt
• 客戶(hù)端公鑰證書(shū)：client.crt
• 客戶(hù)端私鑰文件：client.key
• 客戶(hù)端集成證書(shū)鏈：client_CA.crt

圖七：證書(shū)關(guān)系圖

3.2.3.1 生成自簽名根證書(shū)

1. 創(chuàng)建根證書(shū)私鑰。openssl genrsa -out root.key 1024
2. 創(chuàng)建根證書(shū)請(qǐng)求文件。openssl req -new -out root.csr? -key root.key 。注意：在創(chuàng)建證書(shū)請(qǐng)求文件的時(shí)候需要注意以下三點(diǎn)，下面生成服務(wù)器請(qǐng)求文件和客戶(hù)端請(qǐng)求文件均要注意這三點(diǎn)：根證書(shū)的Common Name填寫(xiě)root就可以，所有客戶(hù)端和服務(wù)器端的證書(shū)這個(gè)字段需要填寫(xiě)域名，一定要注意的是，根證書(shū)的這個(gè)字段和客戶(hù)端證書(shū)、服務(wù)器端證書(shū)不能一樣。其他所有字段的填寫(xiě)，根證書(shū)、服務(wù)器端證書(shū)、客戶(hù)端證書(shū)需保持一致。最后的密碼可以直接回車(chē)跳過(guò)。
3. 創(chuàng)建根證書(shū)。openssl x509 -req -in root.csr -out root.crt -signkey root.key -CAcreateserial -days 3650

得到了有效期為10年的根證書(shū)root.crt.我們可以用這個(gè)根證書(shū)去頒發(fā)服務(wù)器證書(shū)和客戶(hù)端證書(shū)。

3.2.3.2????? 生成自簽名服務(wù)端證書(shū)

1. 生成服務(wù)器端證書(shū)私鑰。openssl genrsa -out server.key 1024
2. 生成服務(wù)器證書(shū)請(qǐng)求文件。openssl req -new -out server.csr -key server.key。證書(shū)請(qǐng)求文件中攜帶著公鑰以及用戶(hù)信息。但是證書(shū)請(qǐng)求文件是未加密的，任何人獲取到之后，都是可以解析其中內(nèi)容的。
3. 生成服務(wù)器端公鑰證書(shū)。openssl x509 -req -in server.csr -out server.crt -signkey server.key? -CA root.crt -CAkey root.key? -CAcreateserial -days 3650。使用根證書(shū)私鑰對(duì)證書(shū)請(qǐng)求文件內(nèi)容進(jìn)行加密，并在證書(shū)中添加其它參數(shù)。比如：說(shuō)明該證書(shū)的CA機(jī)構(gòu)（root.crt）。此時(shí)root.crt 文件是可以被解析的。但是獲取到的是被加密之后的服務(wù)器公鑰+服務(wù)器信息。以及簽發(fā)的CA機(jī)構(gòu)（root）。

3.2.3.3????? 生成自簽名客戶(hù)端證書(shū)

1. 生成客戶(hù)端的證書(shū)密鑰。openssl genrsa -out client.key 1024
2. 生成客戶(hù)端證書(shū)請(qǐng)求文件。openssl req -new -out client.crs -key client.key
3. 生成客戶(hù)端證書(shū)。openssl x509 -req -in client.crs -out client.crt -signkey client.key -CA root.crt -CAkey root.key -CAcreateserial -days 3650

3.3?? 握手過(guò)程（單向?yàn)槔?#xff09;

通過(guò)上面的單向認(rèn)證以及雙向認(rèn)證的圖解，我們已經(jīng)有了初步的理解?，F(xiàn)在加深一下理解。

1. 客戶(hù)端向服務(wù)器發(fā)起握手請(qǐng)求。該請(qǐng)求中包含了以下內(nèi)容：
   1. 客戶(hù)端 SSL 協(xié)議的版本號(hào)，
   2. 加密算法的種類(lèi)，
   3. ?以及其他服務(wù)器和客戶(hù)端之間通訊所需要的各種信息。
2. ?服務(wù)端進(jìn)行響應(yīng)，其中包含了：
   1. SSL 協(xié)議的版本號(hào)，
   2. 加密算法的種類(lèi)，
   3. 以及其他相關(guān)信息，
   4. ?同時(shí)服務(wù)器還將向客戶(hù)端傳送自己的證書(shū)。
3. 客戶(hù)端接收到服務(wù)端的消息及證書(shū)之后，數(shù)字證書(shū)就要進(jìn)行驗(yàn)證了。流程大致如下：
   1. 首先將證書(shū)進(jìn)行解密，獲取證書(shū)相關(guān)信息。
   2. 判斷證書(shū)是否過(guò)期；
   3. 發(fā)行服務(wù)器的證書(shū)CA是否可靠；（主要查看該CA是否在客戶(hù)端的信任列表中）
   4. 使用發(fā)行者的公鑰機(jī)密服務(wù)器的數(shù)字簽名。
   5. 判斷證書(shū)上的域名是否和服務(wù)器的實(shí)際域名相匹配。
   6. 若以上都通過(guò)，則證書(shū)合法。并獲取證書(shū)中的公鑰。
4. 客戶(hù)端隨機(jī)產(chǎn)生一個(gè)用于后面通訊的“對(duì)稱(chēng)密鑰”R，然后用服務(wù)器的公鑰對(duì)其加密，再發(fā)送給服務(wù)器。
5. 客戶(hù)端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟 4 中的主密碼為對(duì)稱(chēng)密鑰，同時(shí)通知服務(wù)器客戶(hù)端的握手過(guò)程結(jié)束。
6. 服務(wù)器向客戶(hù)端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟 4 中的主密碼為對(duì)稱(chēng)密鑰，同時(shí)通知客戶(hù)端服務(wù)器端的握手過(guò)程結(jié)束。
7. SSL 的握手部分結(jié)束，SSL 安全通道的數(shù)據(jù)通訊開(kāi)始，客戶(hù)和服務(wù)器開(kāi)始使用相同的對(duì)稱(chēng)密鑰進(jìn)行數(shù)據(jù)通訊，同時(shí)進(jìn)行通訊完整性的檢驗(yàn)。

4. 思考

若遇上本次問(wèn)題時(shí)，我已掌握上述知識(shí)點(diǎn)，我會(huì)有什么不同呢？分析：

1. 由圖一可知：curl 返回51 錯(cuò)誤碼。表示客戶(hù)對(duì)服務(wù)器的證書(shū)沒(méi)有認(rèn)證通過(guò)。
2. 其實(shí)已經(jīng)將這個(gè)排查點(diǎn)通知客戶(hù)：客戶(hù)端驗(yàn)證服務(wù)器端證書(shū)失敗，請(qǐng)問(wèn)你們是修改服務(wù)器證書(shū)了嗎？（最初可以直接對(duì)客戶(hù)拋出這樣的問(wèn)題，但是由于我們自身不自信，若客戶(hù)不理睬，我們也不會(huì)去催促他們）。到此，可以將問(wèn)題拋給客戶(hù)了。若更加專(zhuān)業(yè)點(diǎn)，可以進(jìn)行步驟三。
3. 獲取服務(wù)器證書(shū)內(nèi)容，將crt 進(jìn)行解析:openssl x509 -in clientcert.crt -noout -text。分析證書(shū)中的內(nèi)容，找出認(rèn)證失敗的原因。這樣客戶(hù)就沒(méi)有理由不理睬了。

后面也遇到了一個(gè)證書(shū)問(wèn)題：下載階段，車(chē)端無(wú)法下載固件包，但是通過(guò)瀏覽器進(jìn)行下載，就可以將固件包下載。

圖8. 車(chē)端無(wú)法下載固件包

了解了上述的知識(shí)點(diǎn)后，我們就可以這樣分析：

瀏覽器訪問(wèn)是單向認(rèn)證，并且可以正常下載。（沒(méi)有彈出警告），但是我們車(chē)端和云端之間采用的是自簽證書(shū)。理應(yīng)服務(wù)器的CA不在電腦的信任列表中的。因此，我們可以懷疑客戶(hù)采用的證書(shū)是商用證書(shū)。結(jié)果也是如此。

圖9. 客戶(hù)的回答：CDN證書(shū)錯(cuò)誤

總結(jié)

經(jīng)過(guò)此次問(wèn)題，我由兩點(diǎn)感觸：

1. 知識(shí)面的提高，對(duì)于我們交付組成員而言是比較重要的。
2. 對(duì)于前線兄弟的支持，目前做的不到位。當(dāng)問(wèn)題不清晰，責(zé)任不明確時(shí)，技術(shù)人員不會(huì)主動(dòng)去協(xié)助，導(dǎo)致項(xiàng)目經(jīng)理和測(cè)試人員很被動(dòng)。因此項(xiàng)目中的技術(shù)負(fù)責(zé)人，還是很有必要的。