OCSP 服務正式終止生命週期 （★ 100 分）
Let’s Encrypt 宣布自 2025 年 8 月 6 日起正式關閉其「線上憑證狀態協定」(OCSP, Online Certificate Status Protocol) 服務，並將全面改用「憑證撤銷清單」(CRL, Certificate Revocation List) 方式來發布憑證撤銷資訊。由於 Let’s Encrypt 在 90 天前已經停止在憑證中附上 OCSP URL，因此所有仍包含 OCSP 位址的憑證現已過期。此舉的主要理由是 OCSP 存在重大隱私風險：當使用者的瀏覽器或軟體透過 OCSP 查詢憑證狀態時，憑證簽發單位 (CA) 能立即知道該使用者正造訪哪個網站，並且能將這些造訪行為與 IP 位址綁定，若遇到法律壓力或內部失誤，就可能導致使用者隱私外洩。相比之下，CRL 沒有這項問題。
除了隱私考量，Let’s Encrypt 也強調簡化基礎設施的重要性。多年來，提供 OCSP 服務消耗了大量資源，而隨著 CRL 技術的實作與普及，OCSP 變得不再必要。在巔峰時期，該服務每月要處理約 3400 億次 OCSP 請求，相當於每秒 14 萬次的 CDN 流量與每秒 1.5 萬次的主機端查詢。Let’s Encrypt 特別感謝 Akamai 十年來捐贈 CDN 資源協助運行 OCSP 服務。
Hacker News 的討論中，許多人認為 OCSP 的設計本質上問題很多。如果 OCSP 是必要條件，它需要持續與伺服器聯線驗證，這讓憑證伺服器容易成為 DoS 攻擊目標；如果不是必要條件，攻擊者可以輕易阻斷 OCSP 回應，讓機制形同虛設。雖然 OCSP stapling（由伺服器主動附上狀態資訊）一度被視為改善隱私的方案，但它增加了複雜性，而且部署率極低。隨著憑證有效期限縮短至 90 天，甚至討論中提到未來可能縮至 47 天或更短，OCSP 的必要性也進一步下降，透過頻繁更換憑證本身就能降低撤銷問題的影響。
有參與者指出，傳統上 OCSP 的優勢在於能即時確認憑證狀態，而 CRL 可能會因清單過大、更新不及時而顯得笨重，因此瀏覽器端出現了像 Mozilla 的 CRLite 這類透過壓縮與布隆過濾器 (Bloom filter) 改良 CRL 的方案。不同瀏覽器有不同應對策略，例如 Firefox 採用 CRLite，而 Chrome 則使用自家機制「CRLSets」，這其實並不依賴 OCSP 或完整 CRL，而是定期下載 Google 事先整理好的撤銷憑證清單。這也使得在實務上，Let’s Encrypt 停止 OCSP 對 Chrome 使用者幾乎沒有影響。
部分評論對於依靠 CRL 表示保留，認為它雖然避開了隱私問題，但在更新延遲和清單龐大方面仍有缺陷。還有人認為，若憑證壽命縮短到僅幾天甚至一天，會顯著增加憑證透明度日誌 (CT, Certificate Transparency) 的負擔，可能影響追蹤效率。不過，整體討論氛圍還是認為 OCSP 走入歷史是大勢所趨，其歷史角色就像是過渡性方案，最終由短期憑證與改良版的 CRL 系統來取代。
👥 25 則討論、評論 💬
https://news.ycombinator.com/item?id=45242591