一、HTTPS 證書體系：信任的基石

HTTPS 證書體系是保障網絡通信安全的核心機制，其本質是一套基于公鑰基礎設施（PKI，Public Key Infrastructure）?的信任體系，通過數字證書實現通信雙方的身份驗證和數據加密，確保信息在傳輸過程中不被篡改、竊取或偽造。

證書體系全景圖

• 根證書極少更新，換根等于“換操作系統”；因此 CA 用中間證書簽名，一旦中間私鑰泄露，吊銷中間證書即可，根證書仍安全。

• 一張服務器證書里其實會帶 1~3 張中間證書，瀏覽器會自動拼鏈；如果鏈拼不齊，就會報 “證書鏈不完整”。

1. 核心角色

   • 證書持有者（服務器 / 客戶端）：通常是網站服務器，需要向權威機構申請證書，以證明自身身份的合法性。證書中包含持有者的公鑰、域名、有效期等關鍵信息。
   • 證書頒發機構（CA，Certificate Authority）：公認的權威第三方機構（如 Let’s Encrypt、DigiCert、GlobalSign 等），負責審核證書申請者的身份，并為其頒發經過數字簽名的證書。CA 自身擁有根證書（Root Certificate），是整個信任體系的 “根”。
   • 信任鏈（證書鏈）：由于根證書直接預裝在操作系統或瀏覽器中（如 Windows、macOS、Chrome 等），具有最高信任級別，而 CA 通常不會直接用根證書簽名用戶證書（避免根證書泄露風險），而是通過 “中間證書（Intermediate Certificate）” 層級簽名。最終形成 “根證書→中間證書→用戶證書” 的信任鏈，瀏覽器通過驗證鏈條的完整性確認證書有效性。
   • 證書吊銷列表（CRL，Certificate Revocation List）?與在線證書狀態協議（OCSP，Online Certificate Status Protocol）：當證書因私鑰泄露、域名變更等原因失效時，CA 會將其列入 CRL 或通過 OCSP 標記為吊銷，瀏覽器在驗證證書時會檢查狀態，避免使用無效證書。
   • 把證書當成“電子身份證”：名字、照片、有效期、發證機關、防偽水印，一個都不能少。

• Subject 里不僅放域名，還會放組織名（OV/EV 證書），瀏覽器地址欄的小鎖→點擊“證書”即可查看。

• Signature 是 CA 用自己的私鑰給證書全文做的哈希簽名，瀏覽器用 CA 公鑰驗證哈希值一致即“未被篡改”。

1. 證書的核心內容
   一份標準的 X.509 格式數字證書包含：

   • 證書持有者信息（如域名、組織名稱、國家 / 地區等）；
   • 證書持有者的公鑰（用于加密傳輸對稱密鑰）；
   • 頒發機構（CA）的信息；
   • CA 對證書的數字簽名（用 CA 的私鑰加密，可通過 CA 公鑰驗證，確保證書未被篡改）；
   • 證書的有效期（起始時間和截止時間，過期后需重新申請）；
   • 證書序列號（唯一標識，用于查詢狀態）等。

2. 證書的類型

   • 域名驗證型（DV，Domain Validated）：僅驗證域名所有權（如通過郵箱或 DNS 解析記錄），審核簡單， issuance 快，適合個人網站或小型應用，僅顯示域名信息。
   • 組織驗證型（OV，Organization Validated）：除驗證域名外，還需審核組織的合法性（如營業執照、地址等），證書中包含組織名稱，可信度更高，適合企業網站。
   • 擴展驗證型（EV，Extended Validation）：最高級別驗證，需通過嚴格的法律、運營、物理地址等多重審核，瀏覽器地址欄會顯示綠色鎖標及組織名稱（如銀行、電商平臺），安全性和可信度最強。

二、HTTPS 證書加密流程（通信流程）：從握手到加密傳輸

HTTPS 的通信安全依賴于SSL/TLS 協議（SSL 是 TLS 的前身，目前主流為 TLS 1.2/1.3），其核心是通過 “非對稱加密” 協商對稱密鑰，再用 “對稱加密” 傳輸數據，同時通過證書實現身份驗證。完整流程可分為TCP 三次握手和SSL/TLS 握手兩部分，其中 SSL/TLS 握手是證書發揮作用的核心階段。

1. 前置：TCP 三次握手

HTTPS 基于 TCP 協議，通信前需先完成 TCP 連接建立：

• 客戶端向服務器發送 “SYN” 報文，請求建立連接；
• 服務器回復 “SYN+ACK” 報文，確認請求并發起自身連接請求；
• 客戶端回復 “ACK” 報文，確認服務器的請求，TCP 連接建立。

2. SSL/TLS 握手：證書與密鑰的 “安全協商”

以 TLS 1.2 為例（TLS 1.3 流程更簡化，減少交互步驟），握手過程需客戶端與服務器交換信息，完成身份驗證、密鑰協商，最終生成用于加密數據的 “會話密鑰”。

• 步驟 1：客戶端 Hello（Client Hello）
  客戶端向服務器發送信息，包括：

  • 支持的 SSL/TLS 版本（如 TLS 1.2）；
  • 支持的加密套件列表（如 ECDHE-RSA-AES256-GCM-SHA384，包含密鑰交換算法、對稱加密算法、哈希算法）；
  • 客戶端生成的隨機數（Client Random），用于后續密鑰計算；
  • 會話 ID（若復用之前的會話，可省略部分步驟）。

• 步驟 2：服務器 Hello（Server Hello）
  服務器收到客戶端請求后，選擇雙方都支持的配置并回復：

  • 確認使用的 SSL/TLS 版本和加密套件（如選中 ECDHE-RSA-AES256-GCM-SHA384）；
  • 服務器生成的隨機數（Server Random），與客戶端隨機數共同用于密鑰計算；
  • 會話 ID（同客戶端，或新建會話）。

• 步驟 3：服務器發送證書（Certificate）
  服務器將自身的數字證書（包含公鑰、域名、有效期、CA 簽名等）發送給客戶端。若證書由中間 CA 頒發，還需附帶中間證書，形成完整的信任鏈。

• 步驟 4：客戶端驗證證書合法性
  客戶端收到證書后，需通過以下步驟驗證證書有效性（核心環節）：

  1. 檢查證書格式與完整性：驗證證書是否符合 X.509 標準，是否被篡改（通過 CA 的數字簽名，用 CA 公鑰解密簽名后與證書哈希值比對，一致則未篡改）。
  2. 驗證信任鏈：從服務器證書向上追溯，通過中間證書最終驗證到根證書（根證書預裝在客戶端，默認可信），若鏈條斷裂（如中間證書缺失或無效），則證書不被信任。
  3. 檢查證書有效期：確認證書當前時間在 “起始時間” 和 “截止時間” 之間，過期證書無效。
  4. 驗證域名匹配：證書中記錄的域名需與當前訪問的域名一致（或符合通配符規則，如 *.example.com匹配a.example.com），否則視為 “域名不匹配”，瀏覽器提示風險。
  5. 檢查證書吊銷狀態：通過 CRL 或 OCSP 查詢證書是否被吊銷（如私鑰泄露后 CA 會吊銷證書），若已吊銷則拒絕信任。

  若以上驗證均通過，客戶端確認服務器身份合法；若驗證失敗，瀏覽器會彈出警告（如 “證書無效”“連接不安全”），用戶可選擇是否繼續（存在風險）。

  

• 步驟 5：客戶端生成預主密鑰（Pre-Master Secret）并加密傳輸
  客戶端生成一個隨機數（Pre-Master Secret），用服務器證書中的公鑰（非對稱加密）?加密后發送給服務器。由于只有服務器擁有對應的私鑰，因此只有服務器能解密得到 Pre-Master Secret（防止第三方竊取）。

• 步驟 6：雙方計算會話密鑰（Master Secret）
  客戶端和服務器分別使用之前交換的 Client Random、Server Random，以及解密得到的 Pre-Master Secret，通過相同的算法（如 PRF 函數）計算出會話密鑰（對稱密鑰）。此時雙方擁有相同的會話密鑰，后續通信將使用該密鑰進行對稱加密（效率更高）。

• 步驟 7：客戶端與服務器確認加密通信就緒

  • 客戶端發送 “Change Cipher Spec” 報文，告知服務器后續數據將用會話密鑰加密；
  • 客戶端發送 “Finished” 報文（用會話密鑰加密），包含之前握手信息的哈希值，供服務器驗證。
  • 服務器接收后，同樣發送 “Change Cipher Spec” 和 “Finished” 報文（用會話密鑰加密），客戶端驗證通過后，SSL/TLS 握手完成。

3. 加密數據傳輸

握手完成后，客戶端與服務器進入加密通信階段：

• 所有數據通過會話密鑰（對稱加密，如 AES）?加密后傳輸，第三方即使截獲數據，因沒有會話密鑰也無法解密。
• 同時，通過哈希算法（如 SHA）對數據進行完整性校驗，確保傳輸過程中數據未被篡改（若篡改，哈希值不匹配，接收方會拒絕）。

4. 會話結束

通信完成后，雙方通過 “Close Notify” 報文結束會話，會話密鑰失效（若后續重連，可通過會話 ID 復用部分握手步驟，提高效率）。