Certificates
CA 創建證書的最佳實踐
我想我有這種情況：
- 根 CA
- 中級 CA
練習一：
- 根CA生成自己的 $ PK_r $ 和 $ PB_r $ 鑰匙，在它使她的證書之後 $ Cert_r $ .
- 中間CA生成她自己的 $ PK_i $ 和 $ PB_i $ 密鑰，並在生成證書籤名請求(CSR) 後，將其發送給根 CA 以獲取證書 $ Cert_i $ .
練習二：
- 根CA生成自己的 $ PK_r $ 和 $ PB_r $ 鑰匙，在它使她的證書之後 $ Cert_r $ .
- 中間CA請求證書 $ Cert_i $ 到根 CA，最後創建一個密鑰對（ $ PK_r $ 和 $ PB_r $ 密鑰）並將請求的證書發送給*中間 CA。*在第二個時刻，根 CA將密鑰對發送（即通過電子郵件）到中間 CA。
我正在使用xca來測試和了解什麼是最佳實踐。
毫無疑問，實踐 1 是優越的。
首先最明顯的問題是：
在練習 2 中，您需要一個通道來傳輸機密和經過身份驗證的數據，這比僅在練習 1 中經過身份驗證的傳輸資訊（CSR）更難。
現在還有其他幾個原因在實踐中使用第一種做法：
- 在實際的 CA 中，私鑰儲存在HSM中。如果您要將密鑰從根 CA HSM 傳輸到中間 CA HSM，則這兩個必須以某種形式連結/以相同的方式進行初始化，這是不必要的過程和不必要的風險，畢竟如果有人設法說服根- HSM 為您提供根密鑰的包裝密鑰，現在攻擊者可以在強化的根 HSM 上使用此密鑰，也可以在強化程度較低的中間 HSM 上使用它。請注意，儘管實際的 CA 很可能確實執行多個可以解開根密鑰的 HSM，但它們都是離線的、在保險庫中且高度強化的，而中間 HSM 有時甚至使用面向 Internet 的 API 完全自動執行/ 服務。
- 在其他時候，中間 CA 可能不是由與根 CA 相同的公司運營。在這些情況下，我非常懷疑客戶端（中間 CA）是否希望信任根 CA 在密鑰生成和包裝以及安全傳輸方法方面的安全措施，因為他們可能只是自己生成密鑰並使用 CSR。
- 它引入了不必要的協議。考慮最終使用者如何獲得證書：他們自己生成密鑰、發送 CSR 並獲得證書。沒有理智的 CA 會提議為客戶端生成密鑰對並讓他們下載。這同樣適用於 CA-CA 通信：頒發證書的協議工作得很好，為什麼要讓它變得更難呢？