Certbot: 如何启用 ACMEv2 和检索通配符证书？

您必须使用DNS-01挑战。 这意味着您必须有一种方法可以通过您的服务器修改、发布和更新 DNS 区域。

你能告诉我这个标志吗？

它不仅仅是一个标志，而且文档中提供了所有内容。 它们是那里列出的几个 DNS 提供商的一些插件，如果你不是，你可以在这里打开一个功能请求来寻求支持（例如，已经有一些像 Gandi 这样的东西打开，所以在打开之前一定要使用搜索新的一个）。

嗯，不，实际上您需要certbot >= 0.22 ，很抱歉在您的第一篇文章中错过了它。

好的.... 我该如何安装？ 我必须从源代码编译吗？

您可以等待它在PPA 中发布，通过 pip 或类似的东西安装，或者确实从源代码构建。

我会是你吗，我宁愿等待官方包更新。 这将使您有一些时间来正确设置 DNS 质询，您已经可以在没有通配符的情况下进行尝试以检查一切正常，然后当更新可用时（应该不会花很长时间），您将准备好获取您的通配符证书。

是的，您可以使用来源中的 certbot

root<strong i="6">@cs12</strong>:~# git clone https://github.com/certbot/certbot
...
root<strong i="7">@cs12</strong>:~# DOMAIN=example.com
root<strong i="8">@cs12</strong>:~# cd certbot 
root<strong i="9">@cs12</strong>:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

添加 TXT 记录按 Enter。 你会得到另一个记录。 也加一下。

然后检查第二个终端窗口是否部署了记录：

root<strong i="15">@cs12</strong>:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

如果没问题，则返回并按 Enter

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

更新：查看Gist 的完整

感谢您如此彻底地回答@ArchangeGabriel！ 我们正在为 Ubuntu 更新我们的软件包，希望它们很快就会推出。

@ohemorang不客气！ 老实说，我担心我们会看到大量涌入的人试图获得通配符证书，而对 DNS-01 挑战一无所知，但显然这并没有发生（至少目前是这样）。

尼斯一个@talyguryn，作为上@talyguryn跟进

使用通配符在顶点上创建一个证书时，您将收到 __two__ 挑战..

使用-d "example.com, *.example.com" _给我一个顶点证书和顶点通配符_

您将受到_两次_的挑战，一次为example.com ，另一次为*.example.com

所以不要认为在第二个挑战中它失败了……而你需要改变这个值。 只需将额外的挑战添加到 dns。 等待传播并继续，

可能应该更改输出，以便更容易看到哪个域受到挑战？

文档： https :

@AubreyHewes ，我遇到了同样的问题。 我不确定如何为example.com和*.example.com颁发单个证书。 不幸的是，certbot 要求我修改 TXT 记录两次。 这会导致域之一的验证失败。 有没有解决的办法？

@nathan-alden 您需要同时设置TXT记录。 添加第二个时不要删除第一个。

@内森奥尔登
你有两个挑战..这个_似乎_像certbot希望你再次修改相同的TXT。 但是第二个值是针对第二个域的，所以为第二个域添加一个新的 TXT 记录。

IE
如果使用-d "example.com,*.example.com" ，第一个挑战是针对example.com因此请为此添加 TXT。 繁殖后继续。
第二个挑战是*.example.com所以为此添加一个 TXT。 繁殖后继续。

我使用 docker 版本有很好的体验。 作为旁注，请确保将 TXT 条目的 TTL 设置为 1 分钟，这样您就不必等待一个小时才能传播第二个条目。

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

想知道。 为什么我们需要dns-01 。 你不能在端口 80 上生成一个服务器（任何形式的http挑战）并通过生成 N 个随机子域并连接来探测我拥有通配符域吗？

@AubreyHewes ，我发现您只需要在 DNS 中进行一项质询/记录 - 只需猜测正确的一项即可。

我有四个域及其通配符的证书。 每个域只有一个 TXT _acme-challenge。 这是非常不一致的，因为三个域与 certbot 输出中的第一个挑战一起工作，并且每次运行时值似乎都相同。

第四个域不适用于输出中的第一条记录，但适用于第二条记录，并且每次运行 certbot 时，这个域似乎都会改变。

我使用这个命令：

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

我通过反复试验来做到这一点 - 我只是不知道您可以拥有两个具有不同值的相同 DNS 记录:-) 下次我会尝试这样做。

@robertvalik不可能对两个不同的验证使用相同的TXT记录值，包括example.com和*.example.com 。

Let's Encrypt 允许在一段时间内重复使用授权，目前为 30 天。 如果您的帐户最近验证了某些内容，它可以颁发更多证书而无需再次验证。 但是，由于 Certbot 的限制 (#5342)，Certbot 会要求您再次设置相同的TXT记录，即使不会再次检查它。

所以一定发生的事情是，其中一个名称已经获得了有效授权，因此必要的 DNS 记录不再存在这一事实并不重要。

@francoism90可能出于多种原因需要通配符域，一个可能服务于很少的静态子域，另一个可能是服务无限的子域（例如软件即服务）。 在后一种情况下（我的情况），DNS 文件中已经有一个通配符，实际上任何随机子域都应该正确解析。 我想知道是否可以为此场景提供一种形式的 http 挑战。 感谢您的辛勤工作！

我通过发行成功生成了证书

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

现在我只是想知道如何更新证书

<> certbot renew
<> certbot-renew
<> certbot-auto renew

我很困惑，我尝试了./certbot-auto renew因为我在请求时使用了相同的命令，但我只想确定它是否是正确的方法。

我们可以自动化通配符认证吗？

@ ufo911当然。 例如，使用 Certbot 的RFC 2136 插件：

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

或者acme-dns手动身份验证钩子：

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

如果您需要帮助，可以在Let's Encrypt 论坛上发布主题。

@mnordhoff
DNS TXT 记录是否有必要在每次更新时生效？

@ufo911当然，renew 只是重新使用以前的参数的证书请求。

@ArchangeGabriel Stange 它告诉我它告诉我设置新的 TXT 记录：

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

这是正常的吗？ 为什么会产生新的代币？

对不起，如果我不清楚，是的，每个请求都有一个新的 TXT 记录。 因为这是一个挑战-响应验证，重用挑战将是一个非常糟糕的主意。

因此，实际上您可以在获得证书后立即删除 TXT 记录，但是每次更新时都会发布一个新的 TXT 记录（并在成功后删除）。

@ArchangeGabriel嗯，不要认为这对我来说是一个选择。 创建新的 TXT 记录可能需要 24 小时才能完成，如果出现问题，最终会导致大量停机时间。

我将使用通用方式。 :)

当然，DNS 挑战并不是最简单的挑战。 但是对于通配符，至少目前没有其他可能性。 我不知道例如这是否可以通过将挑战发送到通配符空间中的随机子域名来代替（例如，如果您要求*.domain.com ，它会尝试读取somerandomstring.domain.com处的挑战响应*.domain.com空间）。 这样在 DNS 中进行通配符重定向就足够了。

@ArchangeGabriel这将是一个不错的选择，但在这种情况下还需要 DNS 验证吗？ 它是否提供安全通配符设置所需的东西？

不，我的想法是提供 DNS 挑战的替代方案。

对于通配符设置，您需要证明对所有子域的控制权。 唯一明显的方法是证明相应 DNS 区域的技术所有权。

现在我想知道是否还有另一种更像其他挑战类型的方式。 询问随机子域将证明您可以控制通配符重定向。 我不知道这对 IETF 来说是否足够，我猜他们已经考虑过了，肯定存在一些问题。

例如，我想知道这种情况是否可能：
– somespecificsub.domain.com 指向给定的 IP；
– *.domain.com 和 domain.com 指向另一个 IP。

在这种情况下，您可以回答对主域和除 somespecificsub.domain.com 之外的任何子域的请求。 而且我认为向您提供 *.domain.com 证书是不对的。 所以如果这是可能的，那么我们需要一些额外的设置。 就像一个永久的 TXT 记录告诉它被授权对通配符质询响应进行随机子域验证。 这样 DNS 配置就可以一劳永逸，您可以更轻松地验证通配符。

无论如何，我不知道应该与谁讨论这个问题，以及他们在什么时候考虑过这种设置，也不知道安全地提供通配符所需的确切标准是什么。 我想我应该为此阅读 RFC，但我没有时间这样做。