公鑰管理 — 證書和PKI

先回答這些問題：

證書是什么？
證書解決能解決什么問題？
證書和CA機構的關系？

數字證書

數字證書的定義：
公開密鑰認證（英語：Public key certificate），又稱數字證書（digital certificate）或身份證書（identity certificate），就類似人的身份證。

它用于公開密鑰基礎建設的電子文件，用來證明公開密鑰擁有者的身份。 此文件包含了公鑰信息、擁有者身份信息（主體）、以及數字證書認證機構（發行者）對這份文件的數字簽名，以保證這個文件的整體內容正確無誤。

簡而言之，認證機構用自己的私鑰對需要認證的人（或組織機構）的公鑰施加數字簽名并生成證書，即證書的本質就是對公鑰施加數字簽名。

證書格式

證書有不同格式類似，不同格式記錄的信息，記錄的格式有所不一樣，下面舉例X.509格式:
X.509 標準規定了證書可以包含什么信息，并說明了記錄信息的方法（數據格式）。除了簽名外，所有 X.509 證書都包含以下數據：

證書具體的樣子：

證書的工作流程

要了解證書的工作流程，需要先了解一下CA機構的作用，以及一些配套密碼算法，HASH、非對稱加密、數字簽名，因為證書是CA機構生成的，只有CA機構生成的證書，才能驗證身份。

PKI的引入

CA機構+證書+用戶這一套整管理流程和認證服務的結合，這就是PKI公鑰基礎設施（PKI —— Public Key Infrastructure）。

PKI 的核心功能是：解決了誰是誰的鑒權問題，它提供網絡上的身份證發行與身份證驗證服務。
他發的身份證就是數字證書，他提供的身份驗證服務就是簽名、驗簽機制。

PKI 的鑒權是通過建立了一個信任鏈，去解決在不安全的網絡環境中如何確認和驗證身份的問題，PKI也是現代網絡安全的基礎。

PKI是如何實現身份認證的？

怎么防止身份冒充：防止攻擊者假冒合法實體？
怎么防止中間人攻擊：確保通信雙方直接相連，沒有惡意中介？
怎么做到不可否認性：證明某個操作確實是由特定實體執行的？

為了解決這些問題，PKI都做了些什么？

需要了解一下構成PKI的一些要素：

CA (Certificate Authority，證書授權機構，就類似公安部門，可以查詢驗證人的身份證)
申請人（被驗證身份方）
用戶（對于用戶來說，證書和CA都是透明無感的，因為系統自動幫忙用戶去做校驗了。）

PKI所涉及的技術：

非對稱加密
Hash
數字簽名

CA提供的服務

CSR（Certificate Signing Request，證書簽名請求）
是由申請人生成的包含其公鑰和身份信息等內容的文件。它被發送給 CA，用于申請數字證書。CA 會根據 CSR 中的信息來創建數字證書，并使用自己的私鑰對證書進行簽名。
證書格式
PKI 中常用的證書格式有 X.509 等，這由 申請人（被驗證身份方） 在申請的時候選擇一個證書格式。X.509 證書包含了證書版本、序列號、簽名算法標識、頒發者名稱、有效期、主體名稱、主體公鑰信息等多個字段，以一種標準化的方式來存儲和傳輸證書信息，確保不同的系統和應用能夠正確地解析和驗證證書。
預制證書
通常是指在某些特定場景下，提前生成并頒發好的數字證書。例如，一些設備制造商可能會在設備出廠前就為設備預裝證書，以便設備在接入網絡時能夠快速進行身份認證和安全通信。這些預制證書一般是由設備制造商或相關的 CA 按照一定的規則和流程進行生成和頒發的。
預制證書就是幫CA做了一半工作的證書，只是還沒有加簽名而已。
證書創建
CA 根據申請人提交的 CSR 或預制證書等信息，按照一定的規則和算法，將申請人的身份信息與公鑰進行綁定，并使用自己的私鑰對證書進行簽名，從而創建出數字證書。（如下圖）
證書發布
CA 將創建好的證書發送給申請人，或者將證書發布到證書庫等公開的存儲位置，以便用戶或設備能夠獲取到證書并進行使用。
證書作廢（Certificate Revocation List，證書吊銷列表）：
當出現證書不再有效或需要撤銷的情況時，如用戶身份信息變更、私鑰泄露等，CA 會將證書標記為作廢狀態，并通過發布證書吊銷列表（CRL）或在線證書狀態協議（OCSP）等方式，讓其他實體能夠查詢到證書的作廢信息，從而不再信任該證書。

證書的工作流程（細講）

對CA提供的服務有了解之后，現在可以來談談證書的工作流程了。

在公鑰基礎設施（PKI）中，Bob（服務提供者）、Alice（用戶）和CA（證書頒發機構）的角色及證書工作流程如下：

角色定義

Bob：需要向外界證明身份的服務提供者（如網站服務器），持有由CA簽發的數字證書。
Alice：需要驗證Bob身份的用戶（如客戶端）。
CA：受信任的第三方機構，負責審核Bob身份并簽發數字證書。

證書工作流程

步驟1：Bob生成密鑰對
- Bob生成自己的公私鑰對（公鑰公開，私鑰嚴格保密）。
步驟2：Bob向CA申請證書
- Bob將公鑰、身份信息（如域名、組織信息）提交給CA，請求證書。
步驟3：CA驗證Bob身份
- CA通過線下驗證（如域名所有權、企業注冊信息）確認Bob的身份真實性。
步驟4：CA簽發證書
- CA將Bob的公鑰、身份信息、有效期、頒發者信息等打包，使用CA的私鑰生成數字簽名，形成證書。
- 證書格式通常為X.509，包含以下關鍵信息：
  - Bob的公鑰
  - Bob的身份信息
  - 證書有效期
  - CA的名稱
  - 數字簽名（由CA私鑰加密的哈希值）。
步驟5：Bob使用證書
- Bob將證書部署到服務器，在與Alice通信時（如建立HTTPS連接）發送該證書。

Alice如何驗證證書？
當Alice收到Bob的證書后，需完成以下驗證：

步驟1. 檢查證書基本信息
- 有效期：確保證書未過期。
- 域名匹配：證書中的域名是否與Bob的實際域名一致（如訪問example.com時證書是否包含該域名）。
步驟2. 驗證證書頒發者（CA）的信任鏈
- Alice的設備（如瀏覽器/操作系統）內置了受信任的根CA證書列表。
- 檢查Bob的證書是否由其中某個CA直接簽發，或通過中間CA（Intermediate CA）簽發。若存在中間CA，需驗證整個證書鏈的簽名有效性。
步驟3. 驗證數字簽名
1. 提取CA的公鑰：從CA的證書（或信任鏈中的上級證書）中獲取公鑰。
2. 解密簽名：用CA的公鑰解密證書中的數字簽名，得到原始哈希值（Hash1）。
3. 重新計算哈希：對證書中Bob的公鑰、身份信息等明文內容計算哈希值（Hash2）。
4. 對比哈希值：若Hash1 = Hash2，則證明證書未被篡改，且確實由CA簽發。
步驟4. 檢查證書吊銷狀態（可選但重要）
- 通過以下方式確認證書未被CA吊銷：
  - CRL（證書吊銷列表）：下載CA發布的吊銷列表，檢查證書是否在其中。
  - OCSP（在線證書狀態協議）：實時向CA查詢證書狀態。

最終信任建立

若所有驗證通過，Alice確認：
1. 證書中的公鑰確實屬于Bob。
2. Bob的身份經過CA嚴格驗證。
3. 通信內容可通過Bob的公鑰加密（或驗證其簽名），確保安全通信。

Alice無需直接信任Bob，而是通過信任CA間接建立對Bob的信任，這是PKI的核心思想。

證書鏈

瀏覽器上訪問一個網站，然后查看一下對方站點的證書，會發現有證書鏈（證書層次結構） 信息，上面的流程也講到了證書鏈，那么這個證書鏈是干嘛的？怎么運作的呢？

（可以使用證書在線解析工具查看：https://myssl.com/cert_decode.html ）

一般是三階結構，或多階結構（如果存在多個中間證書交叉鏈，會導致SSL證書文件變大，加載速度變慢）。

證書鏈：
證書鏈就是一個信任體系，是一個循環驗證的過程，比如我收到你csdn的證書，你說你是GeoTrust機構認證過的，那我接著懷疑GeoTrust機構的證書有沒有問題？GeoTrust機構說我是通過 DigCert機構認證過的，那我接著問 DigCert機構的證書就沒有問題？

DigCert機構已經在系統初始化的時候就預制了一個根證書在系統證書庫了，基本上PKI的流程只能信任到這里了。

你在問，系統預制的證書就牛逼了？就安全了？確實沒辦法保證哈，畢竟已經出現過預制的證書也會有問題的案例，但是基于成本問題，基本到這里就打住了。

如果無限追溯“誰認證了CA的根證書”，會導致邏輯死循環。因此，PKI的設計必須預設一個信任錨點（Trust Anchor），這是整個體系的基礎。用現實世界類比：就像我們默認信任政府簽發的身份證，而不需要追溯“誰認證了政府”一樣。

驗證機制：
當你在瀏覽器中訪問一個網站（例如 *.csdn.net）并查看其證書層次結構時，瀏覽器會通過以下步驟驗證證書鏈的完整性和合法性。以下以你提供的證書鏈為例，具體說明瀏覽器的驗證過程：

證書層次結構示例

根證書：DigiCert Global Root CA
- 中間證書：GeoTrust CN RSA CA G1
  - 葉證書（終端實體證書）：*.csdn.net

瀏覽器的驗證流程：

接收服務器發送的證書鏈

當訪問 *.csdn.net 時，服務器會發送自己的證書（*.csdn.net）以及中間證書（GeoTrust CN RSA CA G1），但不會發送根證書（DigiCert Global Root CA）。
根證書通常預置在瀏覽器或操作系統的受信任根證書存儲中。

構建證書鏈
瀏覽器需要驗證從葉證書到根證書的完整信任鏈：

根證書（DigiCert Global Root CA）是瀏覽器本地預置的受信任根證書。
- 中間證書（GeoTrust CN RSA CA G1）的頒發者是 DigiCert Global Root CA。
  - 葉證書（*.csdn.net）的頒發者是 GeoTrust CN RSA CA G1。
構建證書鏈流程圖：

逐級驗證簽名
瀏覽器會從葉證書開始，逐級向上驗證每一級證書的簽名：
3.1. 驗證葉證書（*.csdn.net）的簽名：
- 使用中間證書 GeoTrust CN RSA CA G1 的公鑰，解密葉證書的數字簽名，得到哈希值（Hash1）。
- 重新計算葉證書明文內容（公鑰、域名、有效期等）的哈希值（Hash2）。
- 如果 Hash1 = Hash2，則葉證書未被篡改，且由 GeoTrust CN RSA CA G1 簽發。
3.2. 驗證中間證書（GeoTrust CN RSA CA G1）的簽名：
- 找到根證書 DigiCert Global Root CA（從本地受信任根證書庫中提?。?/li>
- 使用根證書的公鑰，解密中間證書的數字簽名，得到哈希值（Hash3）。
- 重新計算中間證書明文內容的哈希值（Hash4）。
- 如果 Hash3 = Hash4，則中間證書未被篡改，且由 DigiCert Global Root CA 簽發。
驗證證書鏈流程圖：

驗證證書有效性
每一級證書均需檢查以下內容：
- 有效期： 確保證書未過期（葉證書、中間證書、根證書均需有效）。
- 用途匹配：
  - 葉證書的用途必須包含 Server Authentication（服務器身份驗證）。
  - 中間證書的用途必須包含 Certificate Authority（證書頒發機構）。
- 域名匹配： 葉證書中的 *.csdn.net 是否覆蓋用戶訪問的域名（如 www.csdn.net）。

檢查根證書的信任狀態

根證書 DigiCert Global Root CA 是否在瀏覽器的受信任根證書列表中？
- 是：信任鏈成立。
- 否：瀏覽器會提示證書不受信任（例如顯示紅色警告）。

檢查證書吊銷狀態（可選但推薦）
瀏覽器可能通過以下方式檢查證書是否被吊銷：
6.1. OCSP（在線證書狀態協議）：
- 向證書中指定的 OCSP 服務器（由 CA 提供）發送查詢請求，確認葉證書和中間證書未被吊銷。
6.2. CRL（證書吊銷列表）：
- 下載 CA 發布的吊銷列表，檢查證書是否在其中。

關鍵驗證點總結

信任鏈完整性：葉證書 → 中間證書 → 根證書必須完整且可追溯。
簽名合法性：每一級證書的簽名必須由其上級證書的公鑰驗證通過。
有效期和用途：所有證書必須有效且用途匹配。
根證書預置：根證書必須被瀏覽器或操作系統信任。

用戶可見的結果

如果所有驗證通過：
- 瀏覽器地址欄顯示鎖形圖標，點擊可查看證書詳情。
- 用戶與網站建立加密連接（如 HTTPS）。
如果驗證失?。?
- 瀏覽器顯示警告（如 此連接不是私密連接），阻止用戶繼續訪問。

技術細節補充

中間證書的必要性：
- 根證書通常離線保存，不直接簽發終端證書。中間證書用于日常簽發，降低根證書泄露風險。
證書鏈傳遞：
- 服務器需在 TLS 握手時發送葉證書和中間證書，否則瀏覽器可能無法構建完整鏈（導致警告）。
預置根證書的管理：
- 瀏覽器和操作系統定期更新受信任的根證書列表（例如通過系統更新）。

通過以上流程，瀏覽器確保 *.csdn.net 的證書是由可信的 CA（DigiCert）簽發的，且證書鏈未被篡改，拿出公鑰進行加密使用，最終建立用戶對網站身份的信任。

證書運營機構（CA）

DigiCert
Global Sign
Encrypt
Let's Encrypt (免費)

總結

證書就類似是一張實體身份證，這個身份證不光只存身份信息，還存這個實體相關的公鑰。并且還對公鑰和身份信息做了數字簽名。

誰為這個公鑰和身份信息做簽名？
答：CA，CA就像現實的派出所、它對公鑰和信息做了簽名，就等于發了身份證(數字證書)，它還負責幫助其他人去校驗這個身份證（證書）是不是屬于某個實體。

Reference

《圖解密碼學技術》

數字證書常見格式整理
https://blog.csdn.net/zhulianhai0927/article/details/106452521

posted on 2024-12-09 16:18 Mysticbinary 閱讀(358) 評論(0) 收藏舉報

刷新頁面返回頂部