最后更新时间：2023年2月13日 | 查看所有文档

当您从 Let's Encrypt 获取证书时，我们的服务器会使用 ACME 标准定义的“挑战”来验证您是否控制证书中的域名。大多数情况下，此验证由您的 ACME 客户端自动处理，但如果您需要进行一些更复杂的配置决策，了解它们会很有用。如果您不确定，请使用客户端的默认值或 HTTP-01。

HTTP-01 挑战

这是当今最常见的挑战类型。 Let's Encrypt 将令牌提供给您的 ACME 客户端，您的 ACME 客户端将在您的 Web 服务器上 http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> 位置放置一个文件。该文件包含令牌以及您的帐户密钥的指纹。一旦您的 ACME 客户端告知 Let's Encrypt 文件已准备就绪，Let's Encrypt 就会尝试检索它（可能从多个 vantage points 多次检索）。如果我们的验证检查从您的 Web 服务器获得了正确的响应，则验证将被视为成功，您可以继续颁发证书。如果验证检查失败，您需要使用新的证书重新尝试。

我们对 HTTP-01 挑战的实现遵循重定向，最多 10 次重定向。它只接受重定向到“http:”或“https:”，并且只接受重定向到端口 80 或 443。它不接受重定向到 IP 地址。当重定向到 HTTPS URL 时，它不会验证证书（因为此挑战旨在引导有效的证书，因此在途中可能会遇到自签名证书或已过期证书）。

HTTP-01 挑战只能在端口 80 上执行。允许客户端指定任意端口会降低挑战的安全性，因此 ACME 标准不允许这样做。

优点

无需了解域名的配置信息即可轻松自动化。
它允许托管提供商为 CNAMEd 到他们的域名颁发证书。
它适用于现成的 Web 服务器。

缺点

如果您的 ISP 阻止了端口 80，它将无法正常工作（这种情况很少见，但一些住宅 ISP 会这样做）。
Let's Encrypt 不允许您使用此挑战来颁发通配符证书。
如果您有多台 Web 服务器，您必须确保该文件在所有服务器上都可用。

DNS-01 挑战

此挑战要求您通过在该域名下的 TXT 记录中放置特定值来证明您控制该域名的 DNS。它比 HTTP-01 更难配置，但可以在 HTTP-01 无法使用的情况下工作。它还允许您颁发通配符证书。在 Let's Encrypt 将令牌提供给您的 ACME 客户端后，您的客户端将创建从该令牌和您的帐户密钥派生的 TXT 记录，并将该记录放在 _acme-challenge.<YOUR_DOMAIN> 位置。然后，Let's Encrypt 将查询 DNS 系统以获取该记录。如果它找到了匹配项，您就可以继续颁发证书！

由于颁发和续订的自动化非常重要，因此只有当您的 DNS 提供商具有可用于自动化更新的 API 时，使用 DNS-01 挑战才有意义。我们的社区已经开始了一个此类 DNS 提供商列表。您的 DNS 提供商可能是您的注册商（您从其购买域名的公司），也可能不同。如果您想更改您的 DNS 提供商，您只需要对您的注册商进行一些小的更改。您无需等到您的域名快到期时才能这样做。

请注意，在您的 Web 服务器上放置您的完整 DNS API 凭据会大大增加如果该 Web 服务器遭到黑客攻击的影响。最佳做法是使用范围更窄的 API 凭据，或从单独的服务器执行 DNS 验证并将证书自动复制到您的 Web 服务器。

由于 Let's Encrypt 在查找用于 DNS-01 验证的 TXT 记录时遵循 DNS 标准，因此您可以使用 CNAME 记录或 NS 记录将挑战的回答委托给其他 DNS 区域。这可以用来将 _acme-challenge 子域委托给特定于验证的服务器或区域。如果您的 DNS 提供商更新速度很慢，并且您希望委托给更新速度更快的服务器，也可以使用它。

大多数 DNS 提供商都有一个“传播时间”，它决定从您更新 DNS 记录到它在他们的所有服务器上可用之间的时间。很难衡量这一点，因为他们通常还使用 anycast，这意味着多台服务器可以具有相同的 IP 地址，并且根据您在世界上的位置，您可能会与 Let's Encrypt 不同的服务器对话（并获得不同的答案）。最好的 DNS API 提供了一种自动检查更新是否已完全传播的方法。如果您的 DNS 提供商没有这个功能，您只需将您的客户端配置为等待足够长的时间（通常长达一个小时），以确保更新已传播，然后才能触发验证。

您可以为同一个名称设置多个 TXT 记录。例如，如果您同时验证通配符和非通配符证书的挑战，就会发生这种情况。但是，您应该确保清理旧的 TXT 记录，因为如果响应大小过大，Let's Encrypt 将开始拒绝它。

优点

您可以使用此挑战来颁发包含通配符域名的证书。
即使您有多台 Web 服务器，它也能很好地工作。

缺点

在您的 Web 服务器上保留 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 终止反向代理的作者。现在，这主要意味着大型托管提供商，但像 Apache 和 Nginx 这样的主流 Web 服务器有一天可能会实现这一点（而且 Caddy 已经实现了）。

优点

如果您无法使用端口 80，它将可以使用。
它可以在纯 TLS 层执行。

缺点

它不受 Apache、Nginx 或 Certbot 的支持，而且可能很快也不会得到支持。
与 HTTP-01 一样，如果您有多台服务器，它们需要全部使用相同的内容进行响应。
此方法不能用于验证通配符域名。