Let’s Encrypt 是 Cloudflare 用於簽發 TLS 憑證的公眾信任的憑證授權單位 (CA)，它一直依賴於兩個不同的憑證鏈。一個是與 IdenTrust（自 2000 年以來一直存在的全球可信 CA）進行交叉簽署，另一個是 Let’s Encrypt 自己的根 CA，ISRG Root X1。自從 Let’s Encrypt 推出以來，ISRG Root X1 一直在穩步獲得自己的裝置相容性。
2024 年 9 月 30 日，Let’s Encrypt 與 IdenTrust 交叉簽署的憑證鏈將會到期。交叉簽署過期後，伺服器將無法再提供交叉簽署鏈結簽署的憑證，而是所有 Let’s Encrypt 憑證都將使用 ISRG Root X1 CA。
2016 年之後發布的大多數裝置和瀏覽器版本不會因此變更而遇到任何問題，因為 ISRG Root X1 已安裝在這些用戶端的信任存放區中。這是因為這些現代瀏覽器和作業系統在構建時具有敏捷性和靈活性，具有可升級的信任存放區，可以更新以包含新的憑證授權單位。
憑證鏈的變化將影響舊版裝置和系統，例如執行 Android v7.1.1（2016 年發布）或更早版本的裝置，因為這些裝置完全依賴交叉簽署鏈結並且在其信任存放區中缺少 ISRG Root X1。這些用戶端在存取受 Let’s Encrypt 憑證保護的網域時將遇到 TLS 錯誤或警告。我們自己查看了資料，發現在所有 Android 請求中，2.96% 的請求來自將受到此變更影響的裝置。這將導致很大一部分流量無法存取網際網路。我們致力於讓這些使用者保持上線，並將修改我們的憑證管道，以便我們可以繼續為舊版裝置上的使用者提供服務，而無需客戶進行任何手動修改。
為每個人提供更好的網際網路
過去，我們為「No Browsers Left Behind（不落下任何瀏覽器）」之類的目標而付出努力，以幫助確保在基於 SHA-1 的演算法被棄用時，我們能夠繼續為客戶提供支援。現在，我們正在為即將到來的 Let’s Encrypt 變更套用相同的方法。
我們決定從 Cloudflare 指定 CA 的所有流程中移除 Let’s Encrypt 作為憑證授權單位，這會影響 Universal SSL 客戶以及透過「預設 CA」選擇使用 SSL for SaaS 的客戶。
從 2024 年 6 月（即在交叉簽署鏈結到期的一個憑證生命週期（90 天）前）開始，我們將開始遷移需要續訂的 Let's Encrypt 憑證以使用其他 CA，確保與受變更影響的舊版裝置的相容性。這意味著，今後，客戶只有明確要求 Let’s Encrypt 作為 CA，才會收到 Let’s Encrypt 憑證。
Let's Encrypt 所做的變更是必要的。為了在支援新標準和通訊協定方面取得進展，我們需要使公開金鑰基礎架構 (PKI) 生態系統更加敏捷。Let’s Encrypt 透過淘汰交叉簽署鏈結，推動裝置、瀏覽器和用戶端支援適應性強的信任存放區。
然而，我們過去觀察到類似的變更，雖然它們推動了新標準的採用，但它們對經濟落後地區的使用者產生了不成比例的影響，因為這些地區獲得新技術的機會有限。
我們的使命是幫助建立一個更好的網際網路，這意味著支援全世界的使用者。我們之前發布了一篇有關 Let’s Encrypt 變更的部落格文章，要求客戶在預計會產生任何影響時切換其憑證授權單位。然而，確定變更的影響具有挑戰性。由於信任存放區不相容而導致的錯誤率主要發生在用戶端登入上，從而降低了網域擁有者的可見性。此外，即使今天可能沒有來自不相容裝置的請求，也並不能保證使用者明天的存取不會中斷。
Cloudflare 的憑證管道多年來不斷發展，變得具有彈性和靈活性，使我們能夠無縫適應此類變更，而不會對我們的客戶產生任何負面影響。
Cloudflare 如何建立強大的 TLS 憑證管道
如今，Cloudflare 代表客戶管理數千萬個憑證。對我們而言，成功的管道意味著：
- 客戶始終可以為其網域獲取 TLS 憑證
- CA 相關問題不會對我們客戶獲取憑證的能力產生影響
- 採用了最佳安全做法和現代標準
- 針對未來規模進行最佳化
- 支援廣泛的用戶端和裝置
每一年，我們都會在憑證管道中引入新的最佳化措施以維持最高水準的服務。以下是我們的做法…
確保客戶始終可以為其網域獲取 TLS 憑證
自 2014 年推出 Universal SSL 以來，Cloudflare 一直負責為我們網路保護的每個網域簽發和提供 TLS 憑證。這可能看起來微不足道，但為了讓網域收到憑證，必須成功執行幾個步驟：
- 網域擁有者需要針對每次憑證簽發和續訂完成網域控制驗證。
- 憑證授權單位需要驗證網域控制驗證權杖才能簽發憑證。
- 需要檢查 CAA 記錄（用於指示哪些 CA 可用於網域）以確保只有授權方才能簽發憑證。
- 憑證授權單位必須可用來簽發憑證。
其中每個步驟都需要多方（網域擁有者、CDN 和憑證授權單位）之間的協調。在 Cloudflare，我們希望能夠掌控我們平台的成功。因此我們以確保能夠完成每個步驟為工作。
我們確保每次憑證簽發和續訂都只需客戶付出最少的努力。要獲得憑證，網域擁有者必須完成網域控制驗證 (DCV) 以證明其確實擁有該網域。發起憑證要求後，CA 將傳回 DCV 權杖，網域擁有者需要將其放入 DNS 記錄或 HTTP 權杖中。如果您使用 Cloudflare 作為 DNS 提供者，Cloudflare 會自動將從 CA 傳回的 TXT 權杖放入您的 DNS 記錄中，代表您完成 DCV。或者，如果您使用外部 DNS 提供者，我們提供將 DCV 委託給 Cloudflare 進行自動續訂的選項，無需任何客戶幹預。
放置 DCV 權杖後，憑證授權單位 (CA) 就會對其進行驗證。CA 從多個有利位置進行此驗證，以防止欺騙嘗試。但是，由於這些檢查是從多個國家/地區和 ASN（自發系統）完成的，因此它們可能會觸發 Cloudflare WAF 規則，導致 DCV 檢查被封鎖。我們確保更新 WAF 和安全引擎，以識別這些請求來自 CA，確保它們永遠不會被封鎖，以便 DCV 能夠成功完成。
由於內部要求或合規性規定，某些客戶有 CA 偏好。為了防止未經授權的 CA 為網域簽發憑證，網域擁有者可以建立憑證授權單位授權 (CAA) DNS 記錄，指定允許哪些 CA 為該網域簽發憑證。為了確保客戶始終能夠獲得憑證，我們在申請憑證之前會檢查 CAA 記錄，以瞭解應該使用哪些 CA。如果 CAA 記錄阻止了 Cloudflare 管道中可用的所有 CA，而客戶尚未從他們選擇的 CA 上傳憑證，那麼我們會代表客戶新增 CAA 記錄，以確保他們可以獲得簽發的憑證。我們會盡可能根據偏好進行最佳化。如若不成，我們將透過確保網域始終有可用的 TLS 憑證（即使它不是來自偏好 CA）來防止中斷。
如今，Cloudflare 不是公眾信任的憑證授權單位，因此我們依賴我們使用的 CA 來實現高可用性。但是，100% 正常運作時間是不切實際的期望。我們的管道需要做好準備，以防我們的 CA 不可用。
確保 CA 相關問題不會對我們客戶獲取憑證的能力產生影響
在 Cloudflare，我們喜歡未雨綢繆，這意味著在事件發生之前進行預防。CA 不可用的情況並不罕見——有時這種情況是由於服務中斷而發生的，但更常見的是，CA 經常有維護期，導致在一段時間內不可用。
確保 CA 備援是我們的工作，這就是為什麼我們總是有多個 CA 準備簽發憑證，從而始終確保高可用性。如果您發現有不同的 CA 正在簽發您的 Universal SSL 憑證，那是故意為之。我們在 CA 之間均勻分配負載，以避免任何單一故障點。此外，我們密切注意延遲和錯誤率，以偵測任何問題並自動切換到可用且高效能的其他 CA。您可能不知道，我們的一個 CA 每月大約有 4 個計劃維護期。當這種情況發生時，我們的自動化系統會無縫啟動，保持一切順利執行。這非常有效，我們的內部團隊不會再接到各種電話，因為一切都正常運作。
採用最佳安全做法和現代標準
從過去到將來，安全性一直是 Cloudflare 的首要任務，因此維持最高的安全標準以保護客戶的資料和私密金鑰至關重要。
在過去的十年中，CA/瀏覽器論壇一直主張將憑證生命週期從 5 年縮短到 90 天，作為行業規範。這種轉變有助於最大限度地降低金鑰洩漏的風險。當憑證每 90 天更新一次時，其私密金鑰僅在該期限內保持有效，從而減少了不良行為者利用外洩資料的時間視窗。
我們完全接受這一變更並將 90 天定為預設的憑證有效期。這透過確保定期輪換金鑰來增強我們的安全狀態，並促使我們開發 DCV 委託等工具，以促進頻繁憑證續訂的自動化，而無需增加開銷。利用此工具，我們能夠為那些希望高頻率輪換私密金鑰的客戶提供有效期低至兩週的憑證，而不必擔心這會導致憑證續訂失敗。
Cloudflare 始終處於新通訊協定和標準的前沿。眾所周知，當我們支援一個新通訊協定時，其採用率就會飆升。本月，我們將為 Google Trust Services 簽發的憑證新增 ECDSA 支援。使用 ECDSA，您可以獲得與 RSA 相同層級的安全性，但金鑰更小。更小的金鑰意味著更小的憑證以及傳遞更少的資料來建立 TLS 連線，從而實現更快的連線和更快的載入時間。
針對未來規模進行最佳化
如今，Cloudflare 每天簽發近 100 萬個憑證。隨著最近憑證有效期的轉變，我們繼續改進我們的管道，使其更加強大。但即使我們的管道可以處理大量負載，我們仍然需要依賴我們的 CA 來與我們一起擴展。每整合一個 CA，我們立即就會成為他們最大的消費者之一。我們對 CA 實施高標準，並推動他們改善基礎架構以實現規模化。這不僅有利於 Cloudflare 的客戶，還透過要求 CA 處理更高數量的簽發來幫助網際網路。
現在，隨著 Let’s Encrypt 縮短了他們的信任鏈，我們將為我們的管道新增一項額外的改進——這將確保所有人都能獲得最佳的裝置相容性。
支援所有用戶端——舊版和現代
即將推出的 Let’s Encrypt 變更將阻止舊版裝置向受 Let’s Encrypt 憑證保護的網域或應用程式發出請求。我們不想切斷世界任何地方的網際網路存取，這意味著儘管發生這一變更，我們仍將繼續為客戶提供最佳的裝置相容性。
由於最近的所有增強功能，我們能夠減少對 Let’s Encrypt 的依賴，而不會影響我們憑證管道的可靠性或服務品質。在變更進行的一個憑證生命週期（90 天）前，我們將開始轉移憑證，以使用與受影響裝置相容的其他 CA。這樣，無需客戶採取任何動作，我們就能消減變更帶來的任何影響。只有專門選擇 Let’s Encrypt 作為 CA 的客戶將繼續使用 Let’s Encrypt。
即將發生的 Let's Encrypt 變更可能帶來什麼
Let’s Encrypt 的交叉簽署鏈結將於 2024 年 9 月 30 日到期。雖然 Let’s Encrypt 計劃在 2024 年 6 月 6 日停止從該鏈結簽發憑證，但 Cloudflare 將繼續為所有 Let’s Encrypt 憑證提供交叉簽署鏈結服務，直到 2024 年 9 月 9 日。
在變更進行的一個憑證生命週期（90 天）前，我們會開始將 Let’s Encrypt 憑證轉變為使用其他憑證授權單位。我們將對由 Cloudflare 負責 CA 選擇的所有產品進行此變更，這意味著對於使用 Universal SSL 和 SSL for SaaS 並選擇「預設 CA」的客戶，這將自動完成。
任何專門選擇 Let’s Encrypt 作為其 CA 的客戶都將收到一封電子郵件通知，其中包含其 Let’s Encrypt 憑證清單，以及告知我們是否看到從舊版裝置對這些主機名稱的請求。
2024 年 9 月 9 日之後，Cloudflare 將使用 ISRG Root X1 鏈提供所有 Let’s Encrypt 憑證。根據您使用的憑證產品，可能發生以下情況：
Universal SSL
對於使用 Universal SSL 的客戶，由 Cloudflare 來選擇用於網域憑證的 CA。這讓我們能夠為客戶選擇最好的憑證。如果您使用 Universal SSL，您無需採取任何動作即可為此變更做好準備。Cloudflare 會自動轉移您的憑證以使用更相容的 CA。
進階憑證
使用 Advanced Certificate Manager 的客戶可以專門選擇他們想要使用的 CA。如果客戶專門選擇 Let’s Encrypt 作為憑證的 CA，我們將尊重該選擇，因為客戶可能由於內部要求而專門選擇了該 CA，或者因為他們已經實施了鎖定憑證（我們強烈建議不要這樣做）。
如果我們發現，使用 Let's Encrypt 簽發之進階憑證的網域將受到此變更的影響，那麼我們將傳送電子郵件通知，告知這些客戶哪些憑證正在使用 Let's Encrypt 作為其 CA，以及這些網域是否收到來自受此變更影響之用戶端的請求。如果客戶選擇將 CA 變更為其他提供者，則由其自己負責此過程。
SSL for SaaS
對於 SSL for SaaS，客戶有兩種選擇：使用預設 CA（這表示 Cloudflare 將選擇簽發單位）或指定要使用的 CA。
如果您讓 Cloudflare 來選擇 CA，則我們將自動使用裝置相容性更高的 CA。
如果您為自訂主機名稱指定某個 CA，那麼我們將尊重該選擇。我們將向 SaaS 提供者和平台傳送電子郵件，通知他們哪些自訂主機名稱正在接收來自舊版裝置的請求。如果客戶選擇將 CA 變更為其他提供者，則由其自己負責此過程。
自訂憑證
如果您直接與 Let's Encrypt 整合並使用自訂憑證將 Let's Encrypt 憑證上傳到 Cloudflare，那麼您的憑證將與交叉簽署鏈結捆綁在一起，您只需選擇捆綁方法「相容」或「現代」，並在 2024 年 9 月 9 日之前上傳這些憑證即可。透過「使用者定義」捆綁方法，我們始終為上傳到 Cloudflare 的鏈結提供服務。如果您使用此方法上傳 Let’s Encrypt 憑證，則需要確保在 2024 年 9 月 30 日（CA 過期日期）之後上傳的憑證包含正確的憑證鏈。
此外，如果您控制連接到應用程式的用戶端，我們建議更新信任存放區以包含 ISRG Root X1。如果您使用鎖定憑證，請移除或更新您的鎖定。一般來說，我們不鼓勵任何客戶鎖定其憑證，因為這通常會導致憑證續約或 CA 變更期間出現問題。
結論
網際網路標準將不斷發展和改進。在我們支援和接納這些變化的同時，也需要認識到，我們有責任讓使用者保持上線，並在世界上尚未掌握新技術的地區維持網際網路存取。透過使用 Cloudflare，您始終可以選擇最適合您的應用程式的設定。
有關此變更的更多資訊，請參閱我們的開發人員文件。