如何修复常见的LetsEncrypt错误

2 年 ago
科, 雅
2 minutes

引言

当您配置域名或HTTPS支持时，可能会遇到许多常见错误。域名系统（DNS）可能很难进行故障排除，并且很难确定错误是否归因于DNS，因为它们可能是由堆栈的其他部分引起的。

一个臭名昭著的“系统管理员俳句”如下所示：

It's not DNS
There's no way it's DNS
It was DNS

在服务器配置SSL/HTTPS支持时，最常遇到DNS问题的时间是当你尝试使用Let’s Encrypt时。本教程将回顾一些在处理DNS、HTTPS或特定于Let’s Encrypt时可能遇到的常见错误。这些建议无论你使用Silicon Cloud DNS还是其他提供商都适用。

域名解析记录

DNS是一种系统，它使用域名（例如your_domain.com）而不是需要在任何地方使用IP地址来分配和引导流量到Web服务器。所有的域名注册商（包括Silicon Cloud）都会提供自己的界面来管理DNS记录，尽管它们在语法和规则上大致相似。

想要对DNS记录类型有一个完整的概述，请参考《DNS术语、组件和概念介绍》一文。

来自域名到服务器地址的主要链接是最常见的DNS记录，称为A记录。在本教程中，以及为服务器IP地址分配规范的域名，您主要关注的是A记录。

如果您正在使用Silicon Cloud的DNS，配置的A记录将如下所示：

Required A records

更新或迁移DNS记录

对DNS进行更新可能需要一段时间才能生效。通常情况下，这应该不会超过半个小时，但因为您无法立即在更改后测试DNS，所以错误可能会误导您。只有在DNS更改已传播到大多数或所有全球名称服务器之后，您才能为您的域配置LetsEncrypt。

你可以使用像whatsmydns.net这样的网站来测试DNS更改是否已传播到用于DNS查找的大多数或所有全球名称服务器。如果DNS在本地无法解析，你可以验证它是否应该在大多数位置工作。你的ISP可能在更新方面比一些这些服务器慢一些，但在大多数情况下，这只需要几分钟。

如果您在您的DNS更改已经传播到一些服务器但未传播到其他服务器的短窗口内进行测试，那么从您的远程服务器和本地网络浏览器接收到不同的结果是有可能的，这更加令人困惑。如果您的远程服务器或小型服务器在您的ISP之前更新DNS，这种情况可能发生。为了排除这些错误，您还可以使用nslookup命令测试特定域名解析为哪个IP地址。

  1. nslookup digitalocean.com

 

Output

… Name: digitalocean.com Addresses: 2606:4700::6810:b50f 2606:4700::6810:b60f 104.16.181.15 104.16.182.15

通过这种方式，你可以确认你的本地结果是否与全局DNS解析器匹配。

将您的DNS配置为更长的TTL，即Time-To-Live值，也会使更新时间变长。大多数域名注册商配置的默认TTL值为3600秒，即1小时。这通常会在您的A记录旁边列出。较长的TTL值有助于更高效地缓存请求，但可能导致DNS更改需要更长时间传播。如果您计划进行或测试DNS更改，您可能希望将TTL临时设置为较低值。

浏览器错误和HTTPS配置问题

浏览器出现错误以及HTTPS配置问题

有时候，你可能会认为你已经正确配置了HTTPS和DNS，但是你或者你的用户在尝试访问你的网站时仍然会在浏览器中收到错误提示。

有关HTTP错误码的一般指南，请参阅《如何解决常见的HTTP错误码》。其中大部分不会直接指示HTTPS错误，但仍可能是由于配置不当导致的。例如，如果您正在使用Nginx反向代理为服务器上运行的其他应用程序提供HTTPS网关，并且该网关配置错误，您可能会收到502错误。

你可能会遇到的另一个错误是过期证书。与商业HTTPS证书不同，LetEncrypt的证书只有三个月的有效期。如果在证书到期前不及时续订，任何试图访问你的网站的人都会遇到错误。

通常情况下，这会产生一个ERR_CERT_DATE_INVALID错误。在Chrome中，可能会看起来像这样：

An expired certificate browser warning

当您最初配置Let’s Encrypt时，它应该设置一个后台进程来自动更新您的证书。Let’s Encrypt通常会在您的证书即将过期时给您发送一封电子邮件。

然而，如果此过程配置错误，或者未能触发，您可以通过使用renew参数重新运行certbot来手动更新您的证书。

  1. sudo certbot renew –nginx -d example.com -d www.example.com

 

在更新证书后，您可能需要重新启动您的Web服务器。如果您没有对Web服务器的配置做出任何其他更改，您可以安全地自动化此过程（例如，将其添加到计划的cron中），在您的证书更新后运行systemctl restart nginx。

混合内容

如果你正在从HTTP迁移到HTTPS的复杂堆栈，你可能会注意到一些图片或其他网站资源无法显示。如果你打开浏览器的开发者控制台，你会发现这些错误是由“混合内容”引起的。

Mixed content browser errors

这是由于默认网络策略的原因，即不应将HTTP内容包含在通过HTTPS提供的网站上。当一个网站从两个不同的Web服务器加载内容时，或者当Web应用程序在Nginx网关的后面提供服务时，但SSL转发没有正常工作时，就可能会发生这种情况。

如果你正在使用Nginx，并且你将流量转发到运行在你的Web服务器后面的另一个应用程序，并且你遇到了混合内容警告，你可以尝试在位置块中添加一些额外的SSL转发配置。

你的网站的目录是在”/etc/nginx/sites-available/”下。
…
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

除此之外，确保您提供服务的每个网站都配置了HTTPS。您还可以参考MDN关于混合内容错误的文档。

运行LetsEncrypt的Certbot脚本时出现错误

您可能也会遇到运行Let’sEncrypt的certbot脚本时出现错误。有时这些错误会有详细的输出，您可以直接按照它们进行处理。其他错误可能不那么清楚。如果脚本“超时”，很可能是防火墙问题，并会显示如此。

  1. certbot –nginx -d example.com -d www.example.com

 

Output

Press Enter to Continue Waiting for verification… Cleaning up challenges Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: 93 Timeout during connect (likely firewall problem)

通常，超时是由于连接无法获得任何响应，但没有收到确认，原因是防火墙有意丢弃所有流量。在尝试运行 certbot 之前，请验证您的防火墙是否未阻止端口 80 或 443。一些文档可能会建议您只需打开其中一个端口 80 或 443，但为排除任何错误，您应尝试同时打开两个端口。如果您使用 UFW 与 Nginx，可以通过启用 Nginx 全部配置来实现此操作。

  1. sudo ufw allow ‘Nginx Full’

 

在更改防火墙设置后尝试重新运行 Certbot。如果您连续多次重新运行 Certbot 以尝试排除错误，可能会收到类似于“验证失败限制”的消息。

Output

too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

在这种情况下，你将需要等待最多一个小时，直到你的帐户不再受到速率限制。有关验证限制和其他Certbot错误的更多信息，请参阅Certbot文档。

如果你收到与DNS、超时或连接问题无关的其他Certbot错误，那么它们很可能是由Certbot在首次配置运行的服务器上的Python环境引起的问题。

这些问题几乎总是可以通过删除Certbot并从头开始重新安装来解决。要做到这一点，请按照在Ubuntu 22.04上如何使用Let’s Encrypt保护Nginx的第1步操作。这将不会影响现有的HTTPS配置，只会影响用于维护和更新配置的工具。

HTTPS无法正常工作，且没有明显的错误提示。

如果您已验证Certbot和DNS均正常工作，但您的网站似乎仍然未从使用HTTP切换到使用HTTPS，这通常是由于您的Web服务器配置出现问题。Certbot在首次运行时会尝试自动更新您的Web服务器配置文件。这也是为什么您通常会在Certbot命令中指定nginx，以便在检索到证书后，它知道要更新什么类型的Web服务器配置。然而，如果您现有的Web服务器配置非常复杂，Certbot可能无法更新它以反映HTTPS，并且您需要进行自己的更改。

首先，在Ubuntu 20.04 上如何使用Let’s Encrypt安全地配置Nginx的第2步中，请确保您在Web服务器配置文件中已包含server_name块。如果没有这个块，certbot将不知道要更新哪个配置文件。如果在这之后仍然遇到问题，您可能需要以独立模式运行certbot仅检索证书，然后手动配置您的Web服务器以使用HTTPS。

一个基本的Nginx HTTPS配置将包括listen 443 ssl以及SSL证书和密钥的路径，如下所示：

请把下面这个句子用中文本地化重述，只需要一种选择：
/etc/nginx/sites-available/sample样例网站的路径为/etc/nginx/sites-available/sample。

…
    listen 443 ssl;
    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
…

如果你正在配置Nginx，请记住在重新启动Web服务器之前，可以通过运行nginx -t来验证对Nginx配置的任何更改。当你完成所有更改后，可以通过运行systemctl restart nginx来重新启动具有新配置的Nginx。

  1. sudo systemctl restart nginx

 

结论

LetsEncrypt的目标是为每个人提供免费的HTTPS服务，不受地域限制。当它能够自动运行时，非常有用，但当它无法正常工作时，可能会令人困惑，尤其是对于那些对SSL或DNS配置有限经验的人来说。在本教程中，您将审查了LetsEncrypt的几种常见错误场景以及故障排除步骤。

接下来，您可以了解更多关于SSL证书颁发机构的信息。

发表回复 0

Your email address will not be published. Required fields are marked *

✖
广告
将在 10 秒后关闭
bannerAds