介绍
您在配置域名或 HTTPS 支持时可能会遇到许多常见的错误。DNS,域名系统,可能难以解决问题,当它们可能由您的堆栈的不同部分引起时,很难最终归因于 DNS 的错误。
一个臭名昭着的sysadmin’s haiku是这样的:
1It's not DNS
2There's no way it's DNS
3It was DNS
最常见的 DNS 问题是试图为您的服务器配置 SSL/HTTPS 支持时。例如,当使用 Let’s Encrypt时。本教程将审查您在处理 DNS、HTTPS 或 Let’s Encrypt 时可能遇到的一些常见错误。这些建议将适用于您使用 DigitalOcean DNS或其他提供商。
◎ DNS 记录
DNS 是将流量分配和导向 Web 服务器的系统,使用域名,如 your_domain.com,而不是要求使用 IP 地址在任何地方。
有关 DNS 记录类型的完整概述,请参阅 DNS 术语,组件和概念的介绍。
最常见的DNS记录是A记录,这是一种从域名到服务器地址的主要链接。
如果您正在使用 DigitalOcean 的 DNS,配置的A记录看起来像这样:
更新或迁移DNS记录
更新您的 DNS 可能需要一段时间才能生效,通常需要不到半个小时,但由于您无法在更改后立即测试 DNS,错误可能是误导性的。
您还可以使用一个网站,如 whatsmydns.net来测试 DNS 更改是否传播到大多数或所有用于 DNS 搜索的全球名称服务器中。
如果你正在测试在一个短的窗口内,当你的DNS更改已经传播到某些服务器而不是其他服务器时,你可能会收到来自远程服务器和本地Web浏览器的不同结果,这更令人困惑。
1nslookup digitalocean.com
1[secondary_label Output]
2…
3Name: digitalocean.com
4Addresses: 2606:4700::6810:b50f
5 2606:4700::6810:b60f
6 104.16.181.15
7 104.16.182.15
通过这种方式,您可以确认您的本地结果是否匹配全球DNS解决方案。
将您的 DNS 配置为更长的 TTL 值或 Time-To-Live 值,也将使更新更长时间。大多数域名注册商配置的默认 TTL 值为 3600 秒或 1 小时。这通常会出现在您的 A 记录旁边。更长的 TTL 值有助于更有效地缓存请求,但可以使 DNS 更改更长时间传播。
浏览器错误和HTTPS配置问题
有时,您可能会认为您已正确配置 HTTPS 和 DNS,但您或您的用户在尝试使用您的网站时仍然会收到浏览器中的错误。
有关 HTTP 错误代码的一般指南,请参阅 How To Troubleshoot Common HTTP Error Codes。 其中大多数不会直接表明 HTTPS 错误,但它们仍然可能来自不当的配置。 例如,如果您使用 Nginx 反向代理为您的服务器上运行的其他应用程序提供 HTTPS 网关,并且网关配置错误,您可能会收到 502 错误。
您可能遇到的另一个错误是过期证书. 与商业 HTTPS 证书不同,LetsEncrypt 证书仅有效期为 3 个月,如果在到期日期之前未能更新证书,任何试图访问您的网站的人都会出现错误。
通常情况下,会出现ERR_CERT_DATE_INVALID错误,在 Chrome 中,此错误可能看起来像这样:
当您 初步配置 LetsEncrypt时,它应该设置一个背景流程来自动更新您的证书。
但是,如果此过程被错误配置或未能启动,您可以通过使用更新参数重新运行certbot来手动更新证书:
1sudo certbot renew --nginx -d example.com -d www.example.com
您可能需要在更新证书后重新启动 Web 服务器. 如果您没有对 Web 服务器的配置做出任何其他更改,您可以安全地自动化此操作(例如,通过将其添加到计划中的 cron),在更新证书后运行systemctl 重新启动 nginx。
混合内容
如果您正在将复杂的堆栈从 HTTP 迁移到 HTTPS,您可能会注意到某些图像或其他网站资产无法显示。
这是由于一个默认的网页策略,即HTTP内容不应包含在通过HTTPS服务的网站上,这可能发生在一个网站从两个不同的网页服务器上载内容时,或者当一个网页应用程序从 Nginx 网关后面服务,但SSL 转发无法正常工作时。
如果您正在使用 Nginx,并将流量转移到运行在您的 Web 服务器后面的另一个应用程序,并遇到混合内容警告,您可以尝试将一些额外的 SSL 转发配置添加到一个位置块:
1[label /etc/nginx/sites-available/your-website]
2…
3 location / {
4 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
5 proxy_set_header X-Real-IP $remote_addr;
6 proxy_set_header X-Forwarded-Host $host;
7 proxy_set_header X-Forwarded-Proto https;
8 }
除此之外,请确保您服务的每个网站都配置了 HTTPS,您还可以参阅 MDN 混合内容错误文档。
运行 LetsEncrypt 的 Certbot 脚本的错误
您还可能会遇到运行 Let’sEncrypt 的certbot脚本本身的错误,有时这些错误会具有描述性的输出,您可以直接跟随。其他人可能不那么清楚。
1certbot --nginx -d example.com -d www.example.com
1[secondary_label Output]
2Press Enter to Continue
3Waiting for verification…
4Cleaning up challenges
5Failed 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个端口中的一个,但为了排除任何错误,你应该尝试打开两个端口. 如果您使用Nginx的UFW,您可以通过启用Nginx Full配置来实现:
1sudo ufw allow 'Nginx Full'
在更改防火墙设置后尝试重新运行certbot。如果您连续多次重新运行certbot,以试图排除错误,您可能会收到一个未验证限制消息,如下:
1[secondary_label Output]
2too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
在这种情况下,您将被要求等待一小时,直到您的帐户不再受限。 有关验证限制和其他certbot错误的更多信息,请参阅 Certbot的文档。
如果您收到任何其他certbot错误,这些错误不涉及DNS、时限或连接问题,那么这些错误很可能与您服务器上由certbot配置的Python环境有关。
這些幾乎總是可以通過移除「certbot」並從零重新安裝來解決。 要做到這一點,請遵循 How To Secure Nginx with Let's Encrypt on Ubuntu 22.04的第 1 步)。
HTTPS 不工作没有可见错误
如果您已经核实 Certbot 和您的 DNS 都工作正确, 但您的网站似乎并没有从使用 HTTP 切换到使用 HTTPS , 这通常与您的网络服务器配置有关. Certbot 试图在首次运行时自动更新您的网络服务器配置文件 。 这就是为什么您通常会在 Certbot 命令中指定nginx , 这样它知道在获取证书后要更新什么样的网络服务器配置 。 然而,如果您现有的网络服务器配置非常复杂,Certbot可能无法更新以反映HTTPS,您需要自行修改.
首先,请确保您已在您的 Web 服务器配置文件中包含了server_name块,如在 How To Secure Nginx with Let's Encrypt on Ubuntu 20.04的第 2 步中所述)。
基线 Nginx HTTPS 配置将包括倾听 443 ssl和到 SSL 证书和密钥的路径,如下:
1[label /etc/nginx/sites-available/sample]
2…
3 listen 443 ssl;
4 # RSA certificate
5 ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
6 ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;
7
8 # Redirect non-https traffic to https
9 if ($scheme != "https") {
10 return 301 https://$host$request_uri;
11 }
12…
如果您正在配置 Nginx,请记住,您可以通过运行nginx -t来验证对您的 Nginx 配置的任何更改,以验证它们,然后重新启动 Web 服务器。
1sudo systemctl restart nginx
结论
LetsEncrypt的目标是为每个人提供HTTPS,无论在哪里,免费为他们提供。当它自动工作时,它是非常有用的,但当它没有时,它可能会令人困惑,特别是如果你有有限的经验配置SSL或DNS。
接下来,您可以阅读有关 SSL 证书权威的更多信息。