數字證書的基礎知識
數字證書是用來認證公鑰持有者身份合法性的電子文檔，以防止第三方冒充行爲。數字證書由 CA（Certifacate Authority） 負責簽發，關鍵內容包括 頒發s者、證書有效期、使用者組織、使用者公鑰 等信息。數字證書涉及到一個名爲 PKI（Public Key Infrastructure） 的規範體系，包含了數字證書格式定義、密鑰生命週期管理、數字簽名及驗證等多項技術說明，不在這篇筆記中詳細展開。
我們藉助下面的流程，看看 CA 是如何簽發一張證書，使用者又是如何驗證這樣證書的。這又涉及到了數字簽名技術，數字簽名技術又是基於公鑰密碼技術。
現實世界中，簽名是針對承諾的一種表現形式，手手段可以通過手寫簽字或蓋扣印章；而在數字世界中，簽名仍然是爲了表示承諾，只是手段變成了二進制。
好，我們來看看 CA 數字簽名包括兩個過程：簽發證書（Signing） 和 驗證證書（Verification）
簽發證書的過程
- 撰寫證書元數據：包括 簽發人(Issuer)、地址、簽發時間、有效期 等，還包括證書持有者(Owner)基本信息，比如 DN(DNS Name，即證書生效的域名)、 Owner 公鑰 等信息
- 使用通用的 Hash 算法（如SHA-256）對證書元數據計算生成 數字摘要
- 使用 Issuer 的私鑰對該數字摘要進行加密，生成一個加密的數字摘要，也就是Issuer的 數字簽名
- 將數字簽名附加到數字證書上，變成一個 簽過名的數字證書
- 將簽過名的數字證書與 Issuer 的公鑰，一同發給證書使用者（注意，將公鑰主動發給使用者是一個形象的說法，只是爲了表達使用者最終獲取到了 Issuer 的公鑰）
驗證證書的過程
- 證書使用者獲通過某種途徑（如瀏覽器訪問）獲取到該數字證書，解壓後分別獲得 證書元數據 和 數字簽名
- 使用同樣的Hash算法計算證書元數據的 數字摘要
- 使用 Issuer 的公鑰 對數字簽名進行解密，得到 解密後的數字摘要
- 對比 2 和 3 兩個步驟得到的數字摘要值，如果相同，則說明這個數字證書確實是被 Issuer 驗證過合法證書，證書中的信息（最主要的是 Owner 的公鑰）是可信的
上述是對數字證書的簽名和驗證過程，對普通數據的數字簽名和驗證也是利用了同樣的方法。
我們再來總結一下“簽發證書”與“驗證證書”兩個過程，Issuer（CA）使用 Issuer 的私鑰 對簽發的證書進行數字簽名，證書使用者使用 Issuser 的公鑰 對證書進行校驗，如果校驗通過，說明該證書可信。
由此看出，校驗的關鍵是 Issuer 的公鑰，使用者獲取不到 Issuer 的私鑰，只能獲取到 Issuer 的公鑰，如果 Issuer 是一個壞傢伙，誰來證明 Issuer 的身份 是可信的？
這就涉及到一個信任鏈條了，也是這篇筆記本身要講述的事情，證書鏈。
信任鏈介紹
前面的“證書之什麼是數字簽名？”簡單科普了一下爲什麼要使用證書。其實這些以及後面要科普的都是整個公鑰基礎設施PKI（Public key infrastructure）體系中一部分。下面介紹什麼是數字證書的信任鏈
證書鏈是一個有序的證書列表，包含SSL證書和證書頒發機構（CA）證書，使接收方能夠驗證發送方和所有CA是否值得信任。鏈或路徑以SSL證書開頭，鏈中的每個證書都由鏈中下一個證書標識的實體簽名。
鏈的結構
鏈終止於根CA證書。必須驗證鏈中所有證書的簽名，直至根CA證書。根CA證書始終由CA本身簽名。
下圖說明了從證書所有者到根CA的證書路徑
上圖從下往上介紹依次有
-
根證書：根證書（Root Certificate）的簽名（Root CA’s signature）是用根私鑰（Root CA‘s private key）籤的。所以驗證根證書籤名（Root CA’s signature）要用根公鑰（Root CA’s public key）才能驗證通過。這種情況就叫做自簽名（self-sign）。
-
中介證書： 中介證書（Intermediate Certificate）裏面包含了根證書的名稱（Issuer’s /root CA’s name）。中介證書裏面的簽名（Issuer’s signature）是用根私鑰（Root CA‘s private key）籤的，所以需要根公鑰（Root CA’s public key）才能驗證通過。
-
終端實體證書：終端實體證書（End-entity Certificate）裏面包含了中介證書的名稱（Issuer’s / CA’s name）。終端實體證書裏面的簽名（Issuer’s signature）是用中介私鑰（Owner‘s private key）籤的，所以需要中介公鑰（Owner’s public key）才能驗證通過。
實際場景
還是以Google爲例，在瀏覽器上訪問 “www.google.com” 域名，地址連左側有一個小鎖的標誌，點擊就能查看百度的數字證書，如下圖所示（使用的是Chrome瀏覽器）
在圖片的頂部，我們看到這樣一個層次關係：
GlobalSign Root CA -> GTS CA 101 -> *.google.com
分別對應： 根證書 -> 中介證書 -> 終端實體證書
結合實際的使用場景對證書鏈進行一個歸納：
- 爲了獲取 end-user 的公鑰，需要獲取 end-user 的證書，因爲公鑰就保存在該證書中
- 爲了證明獲取到的 end-user 證書是可信的，就要看該證書是否被 intermediate 機構認證
- 有了intermediate機構的數字簽名，需要繼續往上驗證，即查看是否存在上一級權威認證機構的數字簽名
- 信任鏈條的最終是Root CA，他採用自簽名，對他的簽名只能無條件的信任
信任鏈模型
常見有四種類型用於使用PKI實現信任模型。
A.分層信任模型（Hierarchical Trust Model）：
分層模型或樹模型是實現PKI的最常見模型。頂部的根CA提供所有信息，中間CA在層次結構中是下一個，並且它們僅信任根提供的信息。根CA還信任層次結構中其級別的中間CA.
這種安排允許在分層樹的所有級別進行高級別的控制，這可能是希望擴展其證書處理能力的大型組織中最常見的實現。分層模型允許嚴格控制基於證書的活動。
B.橋接信任模型（Bridge Trust Model）：
在橋接信任模型中，我們在Root CA之間有許多P2P關係，根CA之間可以相互通信並允許交叉證書。該實施模型允許在組織（或部門）之間建立認證過程。
在此模型中，每個中間CA僅信任其上方和下方的CA，但可以擴展CA結構，而無需創建其他CA層。組織之間的額外靈活性和互操作性是橋模型的主要優勢。
C.混合信任模型（Hybrid Trust Model）：
有時您需要在某個部分鏈接兩個或更多組織或部門，並將其他部分分開。當您需要信任兩個組織的某些部分，但您不希望在組織的其他部分中建立信任。在這些時候，混合信任模型可以是最適合您的模型。構建混合信任結構時，您可以非常靈活，此模型的靈活性還允許您去創建混合環境。
請注意，在此結構中，混合環境之外的中間CA只能信任混合環境中的根CA和中間CA，信任連接到混合環境中任何中間CA所有的根CA.
D.網格信任模型（Mesh Trust Model）：
當您想要實現具有交叉認證檢查的分層信任模型或根CA的網絡時，網格信任模型是您的最佳選擇。在其他景點中，網格模型使用多路徑和多根CA遷移橋結構的概念。
每個根CA中的認證都在所有Root CA，中間CA和葉CA以及連接到每個CA鏈的所有最終用戶中獲得授權。