标签: lets-encrypt

我已经在几个域上使用 Let's Encrypt 几个月了，而且它通常一直在工作。我正在更新证书，对于其中一个域，我收到以下错误消息（在返回的 JSON 对象中challenges[1].error.detail）：

DNS 问题：查找 [somedomain.com] 的 CAA 时查询超时

我尝试查找错误，但即使是 Google 也发现结果为零（在撰写本文时）。对于反对者：是的，这个域（正如错误消息中所示）是有效的，完全可以从远处访问和 ping。

然而，这里有一个重要的困境（线索），为什么会出现这种情况。当我第一次尝试更新这个特定域时，我将此域的设置设置为将所有流量重定向到 HTTPS。似乎 LE 尝试通过 HTTPS 访问服务器并失败。从那时起，我更改了服务器设置，以便域不会重定向到 acme-challenge 文件夹的 HTTPS。问题似乎是 LE 记住了先前的请求被重定向，现在它不想访问 HTTP URL。在challenges[1].validationRecord有两个条目，一个是在[0]用于HTTP和一个在[1]为HTTPS，那么清楚LE意识到该服务器可以在HTTP地址以及访问。此外，我可以在 URL 中访问验证检查文件（在相关域上），如下所示challenges[1].validationRecord[0].url 很好，没有任何问题。

我的问题是：如何让 LE 忘记我在将服务器设置为将所有流量重定向到 HTTPS 的同时尝试请求证书？因此，我如何让 LE 使用 HTTP URL？

在过去的几天里，我们在 nginx 错误日志中看到了一些与此类似的错误：

/var/log/nginx/error.log.2.gz:2017/01/30 16:11:46 [crit] 13114#13114: *139338 SSL_do_handshake() failed (SSL: error:14094459:SSL routines:SSL3_READ_BYTES:tlsv1 bad certificate status response:SSL alert number 113) while SSL handshaking, client: X.X.X.X, server: 0.0.0.0:443

我们正在为此证书使用 Let's Encrypt。我们自己无法重现这个问题，到目前为止，我们还无法从客户端获得有关可能导致此问题的任何信息。

RFC 6066说这与 OSCP 相关：

请求 OCSP 响应并在“CertificateStatus”消息中接收 OCSP 响应的客户端必须检查 OCSP 响应并中止握手，如果响应不符合 bad_certificate_status_response(113) 警报。这种警报总是致命的。

我们在我们的 nginx 配置中有这个：

# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

该域从 SSL Labs 获得 A+，我们自己无法重现。什么可能导致此错误？

编辑：对于过去几天发生的 3 次，只有一次在访问日志中留下了其 IP 地址的条目：

/var/log/nginx/access.log:X.X.X.X - - [01/Feb/2017:12:12:51 …

我们在 Azure 上运行的 Web 应用程序安装了 Azure Let's Encrypt 0.9.6 扩展。启动扩展 ( https://********-website-stage.scm.azurewebsites.net/letsencrypt/) 没有问题，我们可以使用创建证书所需的值填写表单，如附图所示：

Let's Encrypt 证书注册表单

大约 2 分钟后，请求超时。我们得到的错误是：

502 - Web 服务器在充当网关或代理服务器时收到无效响应。

您要查找的页面有问题，无法显示。当 Web 服务器（作为网关或代理）联系上游内容服务器时，它收到来自内容服务器的无效响应。

错误日志是这样说的：

IIS 错误日志

错误报告的 Web 应用程序名称 ( ******-website-stage) 存在（它用于******-website-stage.azurewebsites.net），但它看起来有点滑稽 https 前缀，波浪号字符（~1）后面的数字是 1，最后，在 https 上调用端口 80 ?

我们在我们的生产环境中做了完全相同的配置和 letencrypt 安装，它成功了，没有任何问题。

当我们的 Web 应用程序尝试再次联系 Let's Encrypt 以提供有关我们的 Azure Web 应用程序配置的信息（例如，要为其注册证书的主机名）时，似乎会出现此问题。

有什么想法下一步要看吗？

使用 LetsEncrypt 时，必须每 90 天更新一次证书。每次续订证书时，都必须再次证明证书中包含的域的所有权。

可以通过添加_acme-challengeDNS 记录来做到这一点。是否可以在第一次用于验证时设置此 DNS 记录，并在后续验证中重复使用它，这样就不必在每次需要更新证书时设置新的 DNS 记录？

据我了解，LetsEncrypt DNS 验证的工作原理是在 DNS 中设置静态 TXT 记录（基本上只是一个随机数），然后由 LetsEncrypt 服务器检查。

当我第一次听说它时，我非常兴奋并期待更复杂的东西：公钥存储在我的域的 DNS 中。然后，为了进行验证，我创建一条签名消息，并且 LetsEncrypt 服务器检查签名是否有效。由于 DNS 中的公钥和私钥是我拥有的，这证明了我控制该域。

发现它不能以这种方式工作有点令人失望：它需要手动交互，甚至需要更新新的 TXT 记录。

不使用签名方法是否存在技术原因？如果没有，LetsEncrypt没有实现的原因是什么？

我有一个带有 SSL 证书的 nginx Web 服务器，由 Let's Encrypt 提供，使用 Certbot。例如，此站点可在https://example.com 上公开访问

新服务器
我正在创建一个新服务器，一旦一切设置和部署正确，它将替换现有服务器。

我希望它在设置时可以在https://beta.example.com上使用，然后在获得批准后在https://example.com 上使用。

https://beta.example.com现在可以使用了，因为没有其他服务器为该子域的站点提供服务，但是 example.com 仅在我最终更新 DNS 记录时才有效。

我显然需要现有的 Web 服务器在新服务器准备就绪之前继续运行而不会受到影响。

如何为新服务器创建 SSL 证书以准备最终接管？

验证域的问题
当我运行 certbot 时，它尝试访问https://example.com作为验证的一部分，但是它失败了，因为该域指向现有服务器的 IP 地址。

授权程序失败。example.com (tls-sni-01): urn:acme:error:tls :: 服务器在域验证过程中遇到 TLS 错误 :: 远程错误：tls: 握手失败

重要说明：
- 服务器报告了以下错误：

域：example.com
类型：tls
详细信息：远程错误：tls：握手失败

要修复这些错误，请确保您的域名输入正确，并且该域的 DNS A/AAAA 记录包含正确的 IP 地址。此外，请检查您是否拥有允许服务器与 Certbot 客户端通信的最新 TLS 配置。

鉴于我正在尝试做的事情，是否有适当的流程来解决这个问题？

我已为我的域生成 Lets Encrypt通配符证书*.domain.com。

我认为该证书对于任何嵌套子域都有效*.*.domain.com，例如it.*.domain.com或fr.*.domain.com。但浏览器给我错误，该通配符证书是为 颁发的domain.com，而不是为*.domain.com。我尝试*.*.domain.com使用 CertBot 颁发新证书，但出现错误（不允许使用多个通配符）。

是否可以实现此目的，或者我是否必须为每个第一级子域手动颁发通配符证书？

我有一个在私有子域上运行的服务器，server.internal.example.com

example.com是公开的但internal.example.com不是。

我已使用 CertBot 生成证书，*.example.com但如果我尝试扩展此证书以包含*.internal.example.comDNS 质询，则会失败，因为 LetsEncrypt 无法访问此域。我尝试过运行两者：

sudo certbot certonly --manual --preferred-challenges=dns -d *.example.com -d *.internal.example.com
sudo certbot certonly --manual --preferred-challenges=dns -d *.example.com -d server.internal.example.com

但这都要求我进行 LetsEncrypt 无法看到的 DNS 记录更改。有没有办法解决？

看了下/etc/cron.d/certbot，我觉得不会！该文件包含以下行：

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

而且，除非我读错了，否则只有当有一个名为/usr/bin/certbot（有）的可读可执行文件并且没有一个名为/run/systemd/system（但有，即使它是空的）目录时才会发生更新。

那么我是对的，这个certbot -q renew钻头永远不会运行吗？是否还有其他地方也会触发更新？（我认为可能有一些东西，/run/systemd/system因为正在检查，但正如我所说，没有。出于好奇，为什么这个小脚本会检查 不存在/run/systemd/system？）

这是在 Ubuntu 18.04 上运行最新版本certbot（v1.18.0，昨天使用官方说明安装的）。

顺便说一句，我已经跑过：

test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot renew --dry-run

作为 root 在命令行上运行，它会立即退出，退出状态为 1。

使用 Certbot 在 nginx Web 服务器上安装 R3 Let's Encrypt 证书会导致 nginx 配置中的所有其他域都包含在证书的“主题备用名称”下。这对于我的用例来说是不可取的。

我在这里阅读了手册页，并在这里和这里阅读了其他一些 Stack Exchange 帖子。

关于替代名称的使用，手册页说（我不完全理解）：

-d DOMAIN, --domains DOMAIN, --domain DOMAIN 要应用的域名。对于多个域，您可以使用多个 -d 标志或输入逗号分隔的域列表作为参数。提供的第一个域将是证书的主题 CN，所有域将是证书上的主题备用名称。第一个域还将在某些软件用户界面中使用，并用作证书和相关材料的文件路径，除非另有指定或您已经拥有同名的证书。如果发生名称冲突，它将在文件路径名后附加一个数字（如 0001）。（默认：询问）

使用 Certbot 安装 Let's Encrypt 证书时，如何完全指定或省略主题备用名称？如果 Certbot 不能，在仍然使用 R3 Let's Encrypt 证书的同时是否有不同的方法？