在 2020 年 9 月 3 日星期四，Let's Encrypt 發行了六個新的憑證：一個根憑證、四個中繼憑證和一個交叉簽章憑證。這些新憑證是我們更廣泛的計畫的一部分，旨在透過廣泛提供 ECDSA 終端實體憑證並縮小憑證的大小來改善網路上的隱私。

鑑於我們每天發行 150 萬個憑證，這些憑證有什麼特別之處？ 我們為什麼要發行它們？ 我們是如何發行它們的？ 讓我們回答這些問題，並在這個過程中瀏覽憑證授權單位如何思考和運作。

背景故事

每個公開信任的憑證授權單位（例如 Let's Encrypt）至少有一個根憑證，該憑證被納入各個瀏覽器和作業系統供應商（例如 Mozilla、Google）的受信任根儲存區中。這允許從網站收到憑證的使用者確認該憑證是由其瀏覽器信任的組織發行的。但是，由於根憑證具有廣泛的信任和長久的壽命，因此必須仔細保護其對應的私鑰並離線儲存，因此不能一直用於簽署內容。因此，每個憑證授權單位 (CA) 也會有一些「中繼憑證」，這些憑證能夠發行其他憑證，但不是根憑證，它們使用這些憑證進行日常發行。

在過去的 五年中，Let's Encrypt 有一個根憑證：ISRG 根 X1，它具有 4096 位元 RSA 金鑰，有效期至 2035 年。

在同一段時間內，我們有四個中繼憑證：Let's Encrypt 授權單位 X1、X2、X3 和 X4。前兩個是在 Let's Encrypt 於 2015 年首次開始營運時發行的，有效期為 5 年。後兩個是在大約一年後，也就是 2016 年發行的，有效期也為 5 年，大約在明年這個時候到期。所有這些中繼憑證都使用 2048 位元的 RSA 金鑰。此外，所有這些中繼憑證都由 IdenTrust 的 DST 根 CA X3 交叉簽署，這是另一個由不同憑證授權單位控制的根憑證，受到大多數根儲存區的信任。

最後，我們還有 ISRG 根 OCSP X1 憑證。這個憑證有點不同 - 它不會發行任何憑證。相反，它會簽署線上憑證狀態協定 (OCSP) 回應，表示中繼憑證尚未撤銷。這很重要，因為唯一能夠簽署此類聲明的另一件事是我們的根憑證本身，如上所述，根憑證需要保持離線並安全地保護。

新憑證

首先，我們發行了兩個新的 2048 位元 RSA 中繼憑證，我們稱之為 R3 和 R4。它們都是由 ISRG 根 X1 發行的，有效期為 5 年。它們也將由 IdenTrust 交叉簽署。它們基本上是我們目前 X3 和 X4 的直接替代品，它們將在一年內到期。我們預計今年稍後將主要發行管道切換為使用 R3，這不會對發行或續約產生任何實際影響。

其他新的憑證更有趣。首先，我們有新的 ISRG 根 X2，它具有 ECDSA P-384 金鑰而不是 RSA 金鑰，有效期至 2040 年。從此發行了兩個新的中繼憑證，E1 和 E2，它們也是 ECDSA，有效期為 5 年。

值得注意的是，這些 ECDSA 中繼憑證並未由 IdenTrust 的 DST 根 CA X3 交叉簽署。相反地，ISRG 根 X2 本身是 由我們現有的 ISRG 根 X1 交叉簽署。精明的觀察者可能也會注意到，我們沒有從 ISRG 根 X2 發行 OCSP 簽署憑證。

現在我們已經了解了技術細節，讓我們深入探討新層級結構為何看起來如此。

為何我們發行 ECDSA 根憑證和中繼憑證

您可以閱讀許多 其他文章，了解 ECDSA 的優點（相同安全等級下較小的金鑰大小；相應地更快的加密、解密、簽署和驗證操作；以及更多）。但對我們而言，最大的好處來自它們較小的憑證大小。

透過 https:// 與遠端網域的每次連線都需要 TLS 交握。每次 TLS 交握都需要伺服器提供其憑證。驗證該憑證需要憑證鏈（所有中繼憑證的清單，直到但不包括受信任的根憑證），這通常也由伺服器提供。這表示每次連線 - 而一個充滿廣告和追蹤像素的頁面可能會有數十個或數百個 - 最終都會傳輸大量的憑證資料。而且每個憑證都包含它自己的公開金鑰及其發行者提供的簽章。

雖然 2048 位元 RSA 公開金鑰長約 256 位元組，但 ECDSA P-384 公開金鑰僅約 48 位元組。同樣地，RSA 簽章將另外佔用 256 位元組，而 ECDSA 簽章僅佔用 96 位元組。考慮到一些額外的負擔，每個憑證可以節省近 400 位元組。將其乘以憑證鏈中的憑證數量以及您每天獲得的連線數量，頻寬節省將會迅速累積。

這些節省對我們的訂閱者（他們可能是每月頻寬成本可能很高的網站）和終端使用者（他們可能具有有限或計量連線）都是公眾利益。為整個網路帶來隱私不僅僅意味著提供憑證，還意味著讓憑證高效運行。

順帶一提：由於我們擔心憑證大小，我們也採取了一些其他措施來節省新憑證中的位元組。我們已將其主旨通用名稱從「Let’s Encrypt Authority X3」縮短為僅「R3」，依靠先前多餘的「組織名稱」欄位來提供「Let’s Encrypt」字詞。我們縮短了其授權單位資訊存取發行者和 CRL 發布點 URL，並完全刪除了其 CPS 和 OCSP URL。所有這些加起來，在不對憑證中的有用資訊進行任何實質性更改的情況下，又節省了約 120 個位元組。

為何我們交叉簽署 ECDSA 根憑證

交叉簽署是彌合新根憑證發行和將該根憑證納入各個信任儲存區之間差距的重要步驟。我們知道，新的 ISRG 根 X2 本身需要大約 5 年的時間才能獲得廣泛信任，因此為了讓 E1 中繼憑證發行的憑證受到信任，憑證鏈中必須有某個交叉簽章。

我們基本上有兩個選擇：我們可以從現有的 ISRG 根 X1 交叉簽署新的 ISRG 根 X2，或者我們可以從 ISRG 根 X1 交叉簽署新的 E1 和 E2 中繼憑證。讓我們檢查一下每個的優缺點。

交叉簽署新的 ISRG 根 X2 憑證表示，如果使用者在其信任儲存區中具有 ISRG 根 X2，那麼他們的完整憑證鏈將是 100% ECDSA，如上所述，可以讓他們快速驗證。在接下來的幾年中，隨著 ISRG 根 X2 被納入越來越多的信任儲存區中，ECDSA 終端實體憑證的驗證速度將會更快，而使用者或網站無需變更任何內容。但是，缺點是，只要 X2 不在信任儲存區中，使用者代理程式就必須驗證具有兩個中繼憑證的鏈：E1 和 X2 都鏈到 X1 根憑證。這在憑證驗證期間需要更多時間。

直接交叉簽署中繼憑證具有相反的缺點。一方面，我們所有的憑證鏈都將具有相同的長度，在訂閱者憑證和廣泛信任的 ISRG 根 X1 之間只有一個中繼憑證。但另一方面，當 ISRG 根 X2 確實被廣泛信任時，我們將不得不 進行另一次鏈切換，以便讓任何人都獲得全 ECDSA 鏈的好處。

最後，我們決定提供全 ECDSA 鏈的選項更重要，因此選擇了第一個選項，並交叉簽署了 ISRG 根 X2 本身。

為何我們沒有發行 OCSP 回應器

線上憑證狀態協定是使用者代理程式即時發現他們正在驗證的憑證是否已撤銷的一種方式。每當瀏覽器想知道憑證是否仍然有效時，它可以直接訪問憑證本身中包含的 URL 並獲得是或否的回應，該回應由另一個憑證簽署，並且可以類似地進行驗證。這對於終端實體憑證非常有用，因為回應很小且快速，而且任何給定的使用者可能關心（因此必須擷取）的憑證有效性差異很大，具體取決於他們訪問的網站。

但是，中繼憑證是所有現有憑證中的一小部分子集，通常是眾所周知的，並且很少被撤銷。因此，只需維護一個憑證撤銷清單 (CRL)，其中包含所有眾所周知的的中繼憑證的有效性資訊，可能會更有效率。我們所有的中繼憑證都包含一個 URL，瀏覽器可以從該 URL 擷取其 CRL，事實上，有些瀏覽器甚至將這些匯總到他們自己的 CRL 中，並隨著每次更新一起分發。這表示檢查中繼憑證的撤銷狀態不需要額外的網路來回行程，才能載入網站，從而為每個人帶來更好的體驗。

事實上，對管理 CA 的基準要求最近進行了一項變更（投票 SC31），導致不再要求中繼憑證包含 OCSP URL；它們現在可以僅透過 CRL 提供其撤銷狀態。如上所述，我們已從新的中繼憑證中刪除了 OCSP URL。因此，我們不需要發行由 ISRG 根 X2 簽署的 OCSP 回應器。

整合在一起

現在我們已經分享了我們的新憑證的外觀，還有最後一件事我們想提及：我們實際上是如何發行它們的。

由於新的根憑證和中繼憑證的內容受到嚴格規範，且其私鑰必須受到嚴密的保護，因此建立這些憑證是一件大事。重要到發行新憑證的行為被稱為「儀式」。Let's Encrypt 堅信自動化，因此我們希望我們的儀式盡可能減少人為介入。

在過去幾個月裡，我們建立了一個儀式工具，該工具在給定適當配置的情況下，可以產生所有所需的金鑰、憑證和交叉簽名的請求。我們還建立了一個儀式演示，展示我們的設定檔會是什麼樣子，並允許任何人自己執行並檢查產生的輸出。我們的網站可靠性工程師 (SRE) 架設了一個包含硬體安全模組的複本網路，並多次練習該儀式，以確保它能順利運作。我們與我們的技術顧問委員會、社群和各個郵件列表分享了這個演示，並在此過程中收到了寶貴的回饋，這些回饋實際上影響了我們上面提到的一些決策！最後，在 9 月 3 日，我們的執行長在一個安全的資料中心與 SRE 會面，執行整個儀式，並記錄下來以供未來稽核。

現在儀式已完成。我們已更新我們的憑證頁面，以包含有關我們所有新憑證的詳細資訊，並且正開始請求將我們新的根憑證納入各種信任儲存區。我們打算在未來幾週內開始使用我們新的中繼憑證進行發行，並在我們社群論壇上發布進一步的公告。

我們希望這次關於我們的憑證階層的導覽是有趣且內容豐富的，我們期待著繼續一次改進一個憑證，從而改善網際網路。我們要感謝 IdenTrust 對我們改善網路安全的願景的早期和持續支持。

我們依賴用戶和支持者社群的貢獻來提供我們的服務。如果您的公司或組織想贊助Let's Encrypt，請發送電子郵件至sponsor@letsencrypt.org。如果您的經濟狀況允許，我們懇請您個別捐款。