Let’s Encrypt 改善我們管理 OCSP 回應的方式

Let’s Encrypt 透過部署 Redis 並依需求產生回應，而非預先產生回應，改進了我們管理線上憑證狀態協議 (OCSP) 回應的方式，使我們比以往更加可靠。

關於 OCSP 回應

OCSP 用於傳達 TLS 憑證的撤銷狀態。當 ACME 代理程式簽署撤銷憑證的請求時，我們的 Let’s Encrypt 憑證授權機構 (CA) 會驗證該請求是否已授權，如果已授權，我們便開始發布該憑證的「已撤銷」OCSP 回應。每當依賴方 (例如瀏覽器) 訪問具有 Let’s Encrypt 憑證的網域時，他們可以請求有關憑證是否已被撤銷的資訊，而我們會回覆包含由我們的 CA 簽署的「良好」或「已撤銷」的回應，我們稱之為 OCSP 回應。

龐大的 OCSP 回應負載：每秒 100,000 次

Let’s Encrypt 目前為超過 3 億個網域提供服務，這表示我們收到大量的憑證撤銷狀態請求 — 每秒處理大約 100,000 個 OCSP 回應！

通常，我們 98-99% 的 OCSP 回應由我們的內容傳遞網路 (CDN) 處理。但是，有時我們的 CDN 會發生問題，導致 Let’s Encrypt 需要直接接受大量的請求。在過去，我們最多只能有效處理我們自身 6% 的 OCSP 回應流量。如果我們需要接受遠高於這個數字的請求，我們的一些系統可能會開始花費太長時間才能返回結果、返回大量錯誤，甚至停止接受新請求。這對我們或網際網路來說都不是理想的情況。

在我們的 CDN 之一發生問題時，我們無法提供 OCSP 回應可能會導致使用者瀏覽速度變慢，或者無法連線到網站 — 更糟的是，網際網路使用者可能會無意中訪問憑證已被撤銷的網域。瀏覽器對無回應的 OCSP 的反應不同，但有一點很清楚，我們的系統需要更好地處理這些情況。

提高我們的可靠性

在 2022 年的大部分時間裡，我們的工程師一直在努力，並顯著提高了我們獨立提供 OCSP 回應的能力。我們透過部署 Redis 作為記憶體快取層來實現這一點，它可以幫助保護我們的資料庫，吸收流量高峰，無論是由於 CDN 問題還是我們自己的操作 (例如清除 CDN 快取) 導致。

設計上的轉變

我們的團隊開發了一個系統架構設計，以組織/變更所有各種相互關聯的系統，這些系統需要讓 Redis 能夠信任地提供我們的 OCSP 回應。在開發此設計的熱潮中，我們的工程師找到了一種我們可以更高度依賴的資源，以簡化整體架構，並仍然實現難以置信的可靠性提升。我們沒有定期預先簽署 OCSP 狀態回應、將結果儲存在關聯式資料庫中，並要求 Redis 保留副本，而是可以在我們的資料庫中保留簡單但具有權威性的憑證狀態資訊。然後，我們可以利用 HSM 的快速並行簽署能力來即時簽署新的 OCSP 回應，將其快取在 Redis 中，然後將其返回給請求者。因此，關聯式資料庫的需求變得輕得多（尤其是表格寫入總數和寫入競爭），速度令人印象深刻，而且 Redis 沒有保留任何無法（非常快速地）重新產生的內容。

測試我們的系統

第一個測試是透過捨棄一部分 CDN 快取來直接接受 1/16 的請求。在最初的測試中，我們每秒處理了大約 12,500 個請求。後續的測試逐漸增加到捨棄 1/8 的 CDN 快取，然後是 1/4，然後是 1/2，然後是 100% 的快取捨棄。隨著每次測試負載的增加，我們都能夠監控並收集有關我們的部署如何處理流量的見解。在 100% 請求的最終測試中，我們的系統保持響應。這表示，如果我們在未來需要接受的 OCSP 回應數量出現高峰，我們已準備好處理它們，從而大大降低網際網路使用者的風險。

支持 Let's Encrypt