上次更新時間： | 查看所有文件
如果您是託管服務供應商或大型網站整合 Let's Encrypt，或是您正在為 Let's Encrypt 編寫用戶端軟體，本文件包含實用的建議。
規劃變更
Let's Encrypt 和 Web PKI 都會隨著時間持續演進。您應該確保自己有能力輕鬆更新所有使用 Let's Encrypt 的服務。如果您也部署了依賴 Let's Encrypt 憑證的用戶端，請特別確保這些用戶端定期接收更新。
在未來，這些事項可能會變更：
- 我們發放憑證所依據的根憑證和中繼憑證
- 我們在簽署憑證時使用的雜湊演算法
- 我們願意簽署終端實體憑證的金鑰類型和金鑰強度檢查
- 以及 ACME 協議
我們將始終盡可能提前發出這些變更的通知，但如果發現某些組件中存在嚴重的安全漏洞，我們可能需要在短期內或立即進行變更。特別是對於中繼變更，您不應該硬式編碼要使用的中繼，而應該使用 Link: rel="up" ACME 協定中的標頭，因為中繼可能會變更。
同樣地，當我們更新服務條款 (ToS) 時，我們可能會變更 ToS 的 URL。請避免硬式編碼 ToS URL，而是依賴 Link: rel="terms-of-service" 標頭來判斷要使用哪個 ToS URL。
您也會需要一種方法，在發現密碼套件或協議版本的新攻擊時，保持 TLS 設定在最新狀態。
取得更新
若要接收關於重要變更（例如上述變更）的低頻率更新，請訂閱我們的 API 公告群組。這對用戶端開發人員和託管服務供應商都很有用。
若要接收關於維護和中斷的高頻率更新，請造訪我們的 狀態頁面，然後點擊右上角的「訂閱」。這對託管服務供應商最有用。
此外，請確保您為 ACME 帳戶使用有效的電子郵件地址。我們將使用該電子郵件向您發送到期通知，並就您帳戶的任何特定問題進行溝通。
誰是訂閱者
我們的 CPS 和訂閱者協議指出，訂閱者是持有憑證私密金鑰的任何人。對於託管服務供應商而言，是供應商，而不是供應商的客戶。如果您正在編寫人們自行部署的軟體，則就是部署軟體的任何人。
建立帳戶（又稱註冊）時提供的聯絡電子郵件應發送給訂閱者。我們將向該地址發送電子郵件，以警告憑證即將到期，並通知我們的 隱私權政策變更。如果您是託管服務供應商，這些通知應發送給您，而不是客戶。理想情況下，請設定郵寄清單或別名，以便多人可以回覆通知，以防您休假。
這樣做的結果是，如果您是託管服務供應商，您不需要向我們發送客戶的電子郵件地址，或讓他們同意我們的訂閱者協議。您可以簡單地為您控制的網域發放憑證，然後開始使用它們。
一個帳戶還是多個帳戶？
在 ACME 中，可以建立一個帳戶並將其用於所有授權和發行，或為每個客戶建立一個帳戶。這種彈性可能很有價值。例如，某些託管服務供應商可能想要為每個客戶使用一個帳戶，並將帳戶金鑰儲存在不同的內容中，這樣帳戶金鑰洩露就不會允許為其所有客戶發行憑證。
然而，對於大多數大型託管服務供應商，我們建議使用單一帳戶並妥善保護對應的帳戶金鑰。這使得識別屬於同一實體的憑證更容易、保持聯絡資訊更新更容易，並且在需要時更容易提供速率限制調整。如果使用許多不同的帳戶，我們將無法有效調整速率限制。
多網域 (SAN) 憑證
我們的 發行政策允許每個憑證最多 100 個名稱。無論您是為每個主機名稱使用單獨的憑證，還是將多個主機名稱群組在少數憑證上，都取決於您。
每個主機名稱使用單獨的憑證表示，在邏輯上新增和移除網域（因為它們已佈建和停用）所需的移動部件較少。單獨的憑證還能最大限度地減少憑證大小，這可以加快低頻寬網路上的 HTTPS 交握。
另一方面，使用具有許多主機名稱的大型憑證可讓您整體管理較少的憑證。如果您需要支援不支援 TLS 伺服器名稱指示 (SNI) 的舊用戶端（例如 Windows XP），您將需要每個憑證的唯一 IP 地址，因此在每個憑證上放置更多名稱會減少您需要的 IP 地址數量。
對於大多數部署，這兩種選擇都提供相同的安全性。
儲存和重複使用憑證和金鑰
Let's Encrypt 的一大價值在於，它能在新網站佈建時啟用自動發行。然而，如果您有基礎架構可能會重複為同一網站建立新的前端，這些前端應先嘗試使用來自持久儲存的憑證和私密金鑰，只有在沒有憑證可用或所有現有憑證都已過期的情況下，才發行新的憑證。
對於 Let's Encrypt 而言，這有助於我們盡可能有效地向更多人提供服務。對於您而言，這可確保您能夠在需要時部署您的網站，而無論 Let's Encrypt 的狀態如何。
舉例來說，許多網站開始使用 Docker 依需求佈建新的前端執行個體。如果您設定 Docker 容器在啟動時發行，而且您沒有持久地儲存憑證和金鑰，如果您一次啟動太多執行個體，您很可能會達到速率限制。在最糟糕的情況下，如果您必須一次銷毀並重新建立所有執行個體，您可能會陷入無法讓任何執行個體取得憑證的情況，並且您的網站將中斷數天，直到速率限制過期為止。這種問題並非速率限制獨有。如果 Let's Encrypt 在您需要啟動前端時因任何原因而無法使用，您也會遇到相同的問題。
請注意，某些部署哲學指出，加密金鑰永遠不應離開產生它們的實體機器。這種模型可以使用 Let's Encrypt 正常運作，只要您確保機器及其資料是長期存在的，並且您仔細管理速率限制即可。
選擇挑戰類型
如果您使用的是 http-01 ACME 挑戰，您需要在通知 Let's Encrypt 您已準備好完成挑戰之前，將挑戰回應佈建到您的每個前端。如果您有大量前端，這可能會很具挑戰性。在這種情況下，使用 dns-01 挑戰可能會更容易。當然，如果您有許多地理分散的 DNS 回應器，您必須確保 TXT 記錄在每個回應器上都可用。
此外，當使用 dns-01 挑戰時，請務必清除舊的 TXT 記錄，以便對 Let's Encrypt 查詢的回應不會變得太大。
如果您想使用 http-01 挑戰，您可能需要利用 HTTP 重新導向。您可以設定每個前端將所有 XYZ 的 /.well-known/acme-validation/XYZ 重新導向到 validation-server.example.com/XYZ。這會將發行責任委派給 validation-server，因此您應妥善保護該伺服器。
中央驗證伺服器
與以上兩點相關，如果您有很多前端，使用較小的伺服器子集來管理發行可能會有意義。這使得更容易將重新導向用於 http-01 驗證，並提供一個持久儲存憑證和金鑰的位置。
實作 OCSP Stapling
許多瀏覽器會在載入您的網站時從 Let's Encrypt 擷取 OCSP。這是一個 效能和隱私權問題。理想情況下，您網站的連線不應等待與 Let's Encrypt 的次要連線。此外，OCSP 請求會告訴 Let's Encrypt 人們正在造訪哪些網站。我們有良好的隱私權政策，不會記錄 OCSP 請求中的個別識別詳細資料，我們寧願一開始就不要收到這些資料。此外，我們預期每次瀏覽器第一次造訪 Let's Encrypt 網站時，我們為 OCSP 提供服務的頻寬成本將是我們基礎架構支出的很大一部分。
透過開啟 OCSP Stapling，您可以改善網站效能、為使用者提供更好的隱私權保護，並協助 Let's Encrypt 有效率地為盡可能多的人提供服務。
防火牆設定
若要使用 Let's Encrypt，您需要允許從執行 ACME 用戶端的機器傳出的連接埠 443 流量。我們不發佈 ACME 服務的 IP 範圍，它們可能會在沒有通知的情況下變更。
對於「http-01」ACME 挑戰，您需要允許傳入的連接埠 80 流量。我們不發佈執行驗證的 IP 範圍，它們可能會在沒有通知的情況下變更。
注意：我們建議始終允許以純 HTTP 存取您的 Web 伺服器，並重新導向至 HTTPS。這提供了比拒絕或捨棄連接埠 80 連線的 Web 伺服器更好的使用者體驗，並且提供了相同層級的安全性。
對於所有挑戰，您都需要允許傳入的連接埠 53 流量（TCP 和 UDP）到您的授權 DNS 伺服器。
支援的金鑰演算法
Let’s Encrypt 接受長度為 2048、3072 或 4096 位元的 RSA 金鑰，以及 P-256 或 P-384 ECDSA 金鑰。這適用於帳戶金鑰和憑證金鑰。您不能將帳戶金鑰重複用作憑證金鑰。
我們的建議是提供雙憑證配置，預設提供 RSA 憑證，並向支援的客戶端提供（更小的）ECDSA 憑證。
預設使用 HTTPS
對於託管服務提供商，我們的建議是自動為您控制的所有主機名稱頒發憑證並配置 HTTPS，並提供一個使用者可配置的設定，用於是否將 HTTP URL 重定向到其 HTTPS 對應項。我們建議對於現有帳戶，此設定預設為停用，但對於新帳戶，此設定預設為啟用。
理由：現有網站很可能包含一些 HTTP 子資源（腳本、CSS 和圖像）。如果這些網站自動重定向到其 HTTPS 版本，瀏覽器會由於混合內容阻止而封鎖部分子資源。這可能會破壞網站的功能。然而，建立新網站並發現它重定向到 HTTPS 的人，很可能會只包含 HTTPS 子資源，因為如果他們嘗試包含 HTTP 子資源，他們會立即注意到它無法運作。
我們建議允許客戶設定一個 HTTP Strict-Transport-Security (HSTS) 標頭，預設的 max-age 為 60 天。然而，此設定應附帶警告，如果客戶需要遷移到不提供 HTTPS 的託管服務提供商，瀏覽器中快取的 HSTS 設定將會使他們的網站無法使用。此外，客戶和託管服務提供商都應注意，HSTS 標頭會將憑證錯誤變成硬性故障。例如，雖然人們通常可以點擊瀏覽器關於名稱不符或憑證過期的警告，但對於具有有效 HSTS 標頭的主機名稱，瀏覽器不允許這種點擊瀏覽。
何時續簽
我們建議在憑證剩餘總壽命的三分之一時自動續簽。對於 Let’s Encrypt 目前的 90 天憑證，這表示在到期前 30 天續簽。
如果您要為超過 10,000 個主機名稱頒發憑證，我們也建議以小批量的方式自動續簽，而不是將續簽打包成大塊。這可以降低風險：如果 Let’s Encrypt 在您需要續簽時發生故障，或您的續簽系統中出現暫時性故障，則只會影響您的一小部分憑證，而不是全部。這也讓我們更容易進行容量規劃。
您可能想要批量頒發所有網域的憑證以快速入門，這是可以的。然後，您可以通過一次性的方式來分散續簽時間，將一些憑證提前 1 天續簽，一些提前 2 天續簽，依此類推。
如果您提供自動配置定期批次作業的客戶端軟體，請務必在一天中的隨機秒數執行，而不是始終在特定時間執行。這確保 Let’s Encrypt 不會在每個小時或每分鐘的開頭收到任意的流量峰值。由於 Let’s Encrypt 需要提供容量以滿足峰值負載，因此減少流量峰值有助於降低我們的成本。
重試失敗
續簽失敗不應被視為致命錯誤。您應使用指數退避模式在您的頒發服務中實施優雅的重試邏輯，每個憑證每天最多重試一次。例如，合理的退避計畫可以是：第一次重試在一分鐘後，第二次重試在十分鐘後，第三次重試在 100 分鐘後，第四次及後續重試在一天後。您當然應該讓管理員能夠請求針對每個網域或全域提前重試。
重試的退避意味著您的頒發軟體應追蹤失敗和成功，並在嘗試重新頒發之前檢查最近是否有失敗。每小時嘗試頒發數百次是沒有意義的，因為重複失敗很可能是持續性的。
所有錯誤都應發送給負責的管理員，以便查看是否有特定的問題需要修復。