在正常情況下，Let's Encrypt 每天發行將近 兩百萬張憑證。當我們思考網際網路的必要基礎設施需要為哪些情況做好準備時，我們並不是只考慮正常情況。我們希望能夠為可能發生的最困難情況做出最佳應對。在某些最糟的情況下，我們可能需要在 24 小時內重新發行所有憑證，以避免廣泛的中斷。這表示必須準備好在一天內發行 2 億張憑證，這是任何公開信任的憑證授權單位 (CA) 從未做過的事。

我們最近完成了在一天內發行 2 億張憑證所需的大部分工作和投資，並認為應該讓大家知道其中涉及哪些內容。所有這一切都歸功於我們的贊助商和資助者，包括 思科、泰雷斯和 飛塔 的重大硬體貢獻。

情境

安全和法規遵循事件在我們的產業中是必然發生的。我們顯然會盡力減少這些事件，但由於我們預期它們會發生，因此我們花費大量時間準備以最佳方式應對。

2020 年 2 月，影響我們法規遵循的錯誤導致我們需要撤銷並替換 300 萬張有效憑證。這大約佔所有有效憑證的 2.6%。

如果該錯誤影響我們所有的憑證呢？這表示超過 1.5 億張憑證涵蓋超過 2.4 億個網域。如果這是一個更嚴重的錯誤，需要我們在 24 小時內撤銷並替換所有憑證呢？這就是我們需要做好準備的最糟情況。

更糟的是，在發生事件時，需要一些時間來評估問題並做出決策，因此我們會在 24 小時時鐘開始後才開始撤銷和重新發行。這表示一旦做出撤銷並替換 1.5 億或更多憑證的重大決定後，我們實際上會擁有更少的時間。

基礎設施改進

在檢閱我們的系統後，我們確定有四個主要瓶頸會阻礙我們在一天內替換 2 億張憑證。資料庫效能、內部網路速度、加密簽署模組 (HSM) 效能和頻寬。

資料庫效能

Let's Encrypt 有一個主要的憑證授權單位資料庫，是我們提供服務的核心。它會追蹤憑證發行的狀態和相關聯的帳戶。它具有大量的寫入，也有大量的讀取。在任何給定時間，單一資料庫伺服器都是寫入器，有些讀取會導向具有複本的相同機器。單一寫入器非叢集策略有助於保持一致性並降低複雜性，但也表示寫入和一些讀取必須在單一機器的效能限制內運作。

我們上一代的資料庫伺服器具有雙 Intel Xeon E5-2650 v4 CPU，總共 24 個實體核心。它們有 1TB 記憶體和 24 個透過 SATA 連接的 3.8TB SSD，採 RAID 10 設定。這些對於每日發行來說運作良好，但無法在一天內處理替換我們所有憑證的情況。

我們已將它們替換為 新一代來自戴爾的資料庫伺服器，具有雙 AMD EPYC 7542 CPU，總共 64 個實體核心。這些機器具有 2TB 的更快 RAM。更快的 CPU 和雙倍的記憶體是很棒的，但這些機器真正有趣的地方在於 EPYC CPU 各提供 128 個 PCIe4 通道。這表示我們可以塞入 24 個 6.4TB NVME 硬碟，以獲得龐大的 I/O 效能。NVME 沒有可行的硬體 RAID，因此我們已改用 ZFS 來提供所需的資料保護。

內部網路

Let's Encrypt 基礎設施最初是使用 1G 銅纜網路建置的。透過綁定多個連線以獲得 2G 效能，以及使用我們交換器上非常有限的 10G 連接埠，它在 2020 年之前都運作良好。

到 2020 年，我們在內部傳輸的資料量太多，無法使用 1G 銅纜有效處理。一些正常的操作比我們想要的慢很多 (例如備份、複本)，在發生事件時，1G 網路可能會導致我們的回應時間顯著延遲。

我們最初考慮升級到 10G，但了解到升級到 25G 光纖並沒有貴多少。思科最終慷慨地捐贈了我們升級所需的大部分交換器和設備，並且在替換了許多伺服器 NIC 之後，Let's Encrypt 現在正在 25G 光纖網路上運作！

有趣的故事 - 在 2014 年，思科曾捐贈非常好的 10G 光纖交換器，用於建置最初的 Let's Encrypt 基礎設施。但當時我們的機櫃深度異常短，而 10G 交換器在物理上不適合。我們不得不將它們退回，換成物理尺寸較小的 1G 交換器。當時 1G 看起來很夠用。我們之後已搬到具有標準深度的新機櫃！

HSM 效能

每個 Let's Encrypt 資料中心都有一對 Luna HSM，用於簽署所有憑證及其 OCSP 回應。如果我們想要撤銷並重新發行 2 億張憑證，我們需要 Luna HSM 執行下列加密簽署操作

  • 2 億個用於撤銷的 OCSP 回應簽名
  • 2 億個用於替換憑證的憑證簽名
  • 2 億個用於新憑證的 OCSP 回應簽名

這表示我們需要在 24 小時或更短的時間內執行 6 億個加密簽名，並有一些效能額外負荷來考慮請求叢集。

我們需要假設在發生事件時，我們可能只有一個資料中心在線上，因此當我們考慮 HSM 效能時，我們正在考慮如何處理一對 HSM。我們先前的 HSM 每秒可以執行大約 1,100 個簽署操作，一對總共 2,200 個。這表示 24 小時內有 190,080,000 個簽名，以滿載容量運作。這還不夠。

為了達到我們需要的位置，泰雷斯慷慨地捐贈了新的 HSM，其效能約為 10 倍 - 每秒約 10,000 個簽署操作，一對總共 20,000 個。這表示我們現在可以在 24 小時內從單一資料中心執行 864,000,000 個簽署操作。

頻寬

發行憑證並不是特別頻寬密集，但在發生事件期間，我們通常會使用更多的頻寬進行系統復原和分析。我們在資料中心和雲端之間移動大量的記錄和其他檔案以進行分析和鑑識。我們可能需要同步大型資料庫。我們會建立副本和其他備份。如果我們資料中心中的連線速度很慢，則會減慢我們的回應速度。

在確定資料中心連線速度可能會顯著增加我們的回應時間後，我們相應地增加了頻寬。飛塔協助提供硬體，協助我們保護和管理這些更高容量的連線。

API 擴充功能

為了替換所有這些憑證，我們需要一種有效且自動化的方式來通知 ACME 用戶端它們應該執行提早續約。通常 ACME 用戶端會在憑證剩餘壽命的三分之一時續約，否則不會聯絡我們的伺服器。我們去年 發佈了 ACME 的草案擴充功能，其中描述了一種用戶端定期輪詢 ACME 伺服器以找出提早續約事件的方式。我們計劃潤飾該草案、實作，並與用戶端和大型整合商合作，以在用戶端實作該功能。

支援 Let's Encrypt

我們依賴來自用戶社群和支持者的貢獻，才能提供我們的服務。如果您的公司或組織想要贊助 Let's Encrypt，請傳送電子郵件至 sponsor@letsencrypt.org。我們請求您在經濟能力許可下做出個人捐款。