上次更新時間：2023 年 2 月 13 日 | 查看所有文件

當您從 Let's Encrypt 取得憑證時，我們的伺服器會使用 ACME 標準定義的「挑戰」來驗證您是否控制該憑證中的網域名稱。大多數情況下，此驗證由您的 ACME 客戶端自動處理，但如果您需要做出一些更複雜的配置決策，了解更多相關資訊會很有幫助。如果您不確定，請使用客戶端的預設值或 HTTP-01。

HTTP-01 挑戰

這是目前最常見的挑戰類型。Let's Encrypt 會將一個權杖提供給您的 ACME 客戶端，而您的 ACME 客戶端會將一個檔案放置在您網頁伺服器的 http://<您的網域>/.well-known/acme-challenge/<權杖> 位置。該檔案包含權杖，以及您帳戶金鑰的指紋。一旦您的 ACME 客戶端告知 Let's Encrypt 該檔案已準備就緒，Let's Encrypt 會嘗試擷取該檔案（可能會從多個有利位置多次擷取）。如果我們的驗證檢查從您的網頁伺服器取得正確的回應，則驗證會被視為成功，您可以繼續發行您的憑證。如果驗證檢查失敗，您必須使用新的憑證再次嘗試。

我們對 HTTP-01 挑戰的實作會追蹤重新導向，最多 10 次重新導向。它只接受重新導向至「http:」或「https:」，並且只接受連接埠 80 或 443。它不接受重新導向至 IP 位址。當重新導向至 HTTPS URL 時，它不會驗證憑證（因為此挑戰旨在引導有效的憑證，它可能會遇到自我簽署或過期的憑證）。

HTTP-01 挑戰只能在連接埠 80 上進行。允許客戶端指定任意連接埠會降低挑戰的安全性，因此 ACME 標準不允許這樣做。

優點

在不具備有關網域配置的額外知識的情況下，很容易自動化。
它允許主機提供者為 CNAMEd 到他們的網域發行憑證。
它可以與現成的網頁伺服器搭配使用。

缺點

如果您的 ISP 封鎖連接埠 80，則無法使用（這種情況很少見，但一些住宅 ISP 會這樣做）。
Let's Encrypt 不允許您使用此挑戰來發行萬用字元憑證。
如果您有多個網頁伺服器，您必須確保該檔案在所有網頁伺服器上都可用。

DNS-01 挑戰

此挑戰要求您將特定值放入該網域名稱下的 TXT 記錄中，以證明您控制網域名稱的 DNS。它比 HTTP-01 更難配置，但可以在 HTTP-01 無法使用的情況下運作。它也允許您發行萬用字元憑證。在 Let's Encrypt 將權杖提供給您的 ACME 客戶端後，您的客戶端會建立一個從該權杖和您的帳戶金鑰衍生的 TXT 記錄，並將該記錄放置在 _acme-challenge.<您的網域>。然後，Let's Encrypt 會查詢 DNS 系統以尋找該記錄。如果找到相符項，您可以繼續發行憑證！

由於發行和更新的自動化非常重要，因此只有在您的 DNS 提供者具有可用於自動化更新的 API 時，才適合使用 DNS-01 挑戰。我們的社群已開始在此處列出此類 DNS 提供者。您的 DNS 提供者可能與您的註冊商（您從其購買網域名稱的公司）相同，或者可能不同。如果您想變更您的 DNS 提供者，您只需在您的註冊商處進行一些小變更。您無需等到您的網域快要到期才能執行此操作。

請注意，將您的完整 DNS API 憑證放在您的網頁伺服器上會顯著增加該網頁伺服器被駭客入侵時的影響。最佳做法是使用範圍更窄的 API 憑證，或從單獨的伺服器執行 DNS 驗證並自動將憑證複製到您的網頁伺服器。

由於 Let's Encrypt 在查詢 DNS-01 驗證的 TXT 記錄時遵循 DNS 標準，因此您可以使用 CNAME 記錄或 NS 記錄將挑戰的回答委派給其他 DNS 區域。這可用於將 _acme-challenge 子網域委派給特定於驗證的伺服器或區域。如果您的 DNS 提供者更新速度很慢，並且您想要委派給更新速度更快的伺服器，也可以使用此方法。

大多數 DNS 提供者都有「傳播時間」，該時間決定了您更新 DNS 記錄到其所有伺服器上可用的時間。這很難衡量，因為它們通常也使用任播，這表示多個伺服器可以具有相同的 IP 位址，並且根據您在世界上的位置，您可能會與不同的伺服器交談（並獲得不同的回應），而不是 Let's Encrypt。最佳 DNS API 提供了一種自動檢查更新是否完全傳播的方式。如果您的 DNS 提供者沒有此功能，您只需將您的客戶端設定為等待足夠長的時間（通常長達一小時），以確保更新已傳播，然後再觸發驗證。

您可以為同一名稱放置多個 TXT 記錄。例如，如果您同時驗證萬用字元和非萬用字元憑證的挑戰，則可能會發生這種情況。但是，您應該確保清除舊的 TXT 記錄，因為如果回應大小變得太大，Let's Encrypt 將會開始拒絕它。

優點

您可以使用此挑戰來發行包含萬用字元網域名稱的憑證。
即使您有多個網頁伺服器，它也能正常運作。

缺點

將 API 憑證保留在您的網頁伺服器上是有風險的。
您的 DNS 提供者可能不提供 API。
您的 DNS API 可能不提供有關傳播時間的資訊。

TLS-SNI-01

此挑戰在 ACME 的草稿版本中定義。它在連接埠 443 上執行 TLS 交握並傳送特定的 SNI 標頭，尋找包含權杖的憑證。它於 2019 年 3 月停用，因為它的安全性不足。

TLS-ALPN-01

此挑戰是在 TLS-SNI-01 遭棄用後開發的，並且正在作為單獨的標準開發。與 TLS-SNI-01 類似，它透過連接埠 443 上的 TLS 執行。但是，它使用自訂 ALPN 通訊協定來確保只有知道此挑戰類型的伺服器才會回應驗證請求。這也允許此挑戰類型的驗證請求使用與正在驗證的網域名稱相符的 SNI 欄位，使其更安全。

此挑戰不適合大多數人。它最適合想要執行類似 HTTP-01 的基於主機驗證，但想要完全在 TLS 層執行以分離關注點的 TLS 終止反向 Proxy 的作者。目前這主要意味著大型主機提供者，但像 Apache 和 Nginx 這樣的熱門網頁伺服器有一天可能會實作此功能（而且 Caddy 已經這樣做了）。

優點

如果連接埠 80 對您不可用，它也能正常運作。
它可以在 TLS 層純粹執行。

缺點

Apache、Nginx 或 Certbot 不支援它，而且可能很快也不會支援。
與 HTTP-01 類似，如果您有多個伺服器，它們都需要以相同的內容回應。
此方法不能用於驗證萬用字元網域。