☰

获得 LE SSL 证书后，本地 DNS 解析立即强制网站访问 https://www.

tag-icon • tag-icon networking dns
获得 LE SSL 证书后，本地 DNS 解析立即强制网站访问 https://www.

这是我见过的最奇怪的 DNS 问题。

情况：
在我的生产服务器上，所有域名在拥有自签名 SSL 证书时都可以正常工作。在我的本地计算机上，生产服务器上的所有域名都可以在我的 Web 浏览器中正确显示：（在 https://example.com 我接受有关自签名 SSL 证书的浏览器警告后）

问题：
在成功为生产服务器上的任何域获得 Let's Encrypt SSL 后，我的所有本地 Web 浏览器都无法加载https://example.com。但是，（奇怪的部分） https://www.example.com却可以正常工作。

测试：
1.) 我启动了 Windows 10 分区并确认两者https://example.com均可https://www.example.com在任何 Web 浏览器中正确加载。

2.) 他家庭网络上的一位朋友确认，https://example.com两者https://www.example.com都可以在他的本地浏览器中加载，没有任何问题。

仅在我的本地机器上的 ubuntu 20.04 中，https://example.com在获得 LE SSL 后才会拒绝在任何 Web 浏览器中加载。

独特之处：

我的 Ubuntu 20.04 设置的唯一独特之处在于我运行 vbox 测试服务器并使用 dnsmasq 进行本地 DNS 解析（这可能是不相关的信息）。减去所有额外的东西，我的/etc/dnsmasq.conf设置是：

port=53
bogus-priv
listen-address=127.0.0.1,192.168.58.1
bind-interfaces
expand-hosts
domain=example-site.test

我还在本地机器上运行远程服务器/wireguard 客户端的 wireguard 服务器（但是无论我是否连接到 wireguard，这个问题仍然存在）

如果我$nslookup prod-server-domain.com 正确使用它就会显示：

nslookup prod-server-domain.org
Server:     192.xxx.xx.xx   <--- wireguard server ip
Address:    192.xxx.xx.xx#53  <--- wireguard server ip

Name:   prod-server-domain.org
Address: xxx.xx.xxx.xxx        <--- public prod server ip

进一步简化：
在我的远程服务器域名成功获得 LE SSL 证书后，世界上每个网络浏览器都可以访问-除了-我的本地 ubuntu 网络浏览器的 URLhttps://example.com均按https://www.example.com预期正常工作，并指向完全相同的网站。

只有在我的 ubuntu 安装中才会https://example.com失败

而https://www.example.comWORKS。

当我在同一个家庭网络上的 Windows 分区上使用相同的 IP 地址打开https://example.com和Web 浏览器时，https://www.example.comhttps://example.comhttps://www.example.com 均能正常工作。

附加信息：

  1. 所有域名都指向正确的 IP 地址

  2. 如果我完全停用 UFW 和 Wireguard，也会遇到同样的问题

  3. SSL 是通过 Virtualmin 获得的，它确认了 LE SSL 分配的正确 URL 提交：

    在此处输入图片描述

    （全部说 example.org）

    在此处输入图片描述

Firefox 和所有其他浏览器都会显示此错误https://example.org 在此处输入图片描述 但这在所有浏览器中都能完美运行： 在此处输入图片描述

user@machine:~$ curl example.org
curl: (7) Failed to connect to example.org port 80: No route to host
user@machine:~$ curl https://example.org
curl: (7) Failed to connect to example.org port 443: No route to host
user@machine:~$ curl https://www.example.org
<!DOCTYPE html>
<html>
<head>
    <title>Virtualmin</title>
    <meta charset="utf-8">

根据请求：

$ ip route list
default via 192.168.0.1 dev eth0 proto dhcp metric 100 
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600 
169.254.0.0/16 dev eth0 scope link metric 1000 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.13 metric 100 
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.18 metric 600

答案1

$nslookup prod-server-domain.com比较一下和的结果$www.nslookup prod-server-domain.com，它们真的指向同一个ip吗？

答案2

我终于明白了。

我使用 dnsmasq，并且我的外部 DNS 服务器已停止工作。

我选择了新的外部 DNS 服务器，现在一切正常。

答案3

我假设您的本地自签名证书确实可以工作，方法是接受浏览器中的风险通知，将其添加到本地证书管理服务器或本地机器密钥环中。

首先要明白，Https://www.test.org 符合 www 标准，而不是像 Https://toast.test.org 这样的子域，而是直接重定向到 Https://test.org。即使在本地 DNS 中输入单独的值，该服务也会抱怨您正在尝试将同一索引重定向到两个不同的目标。

我看到的第二个问题是您的 SSL 证书使用了通配符。虽然通配符很方便，因为只需要维护一个 SSL 证书，但通配符证书会妨碍网络安全。我强烈建议您远离这些证书，并实际设置适当的本地证书管理。

虽然我不能 100% 确定，一旦服务器上有真正的证书，您的本地设置和条目很可能会停止正确的重定向。通常在服务器上设置证书会使之前指向它的任何本地自签名证书无效。通常，这会收到一条警告“oopsidaisy 此服务器更改了其证书，您真的确定要去那里吗 m8”。

您的 DNS 条目应指向的唯一位置是 Https://test.org -> xxxx，用于您的主要服务。如前所述，WWW 不会产生任何影响，因为它是指向上述内容的重定向。

尝试将客户端浏览器和操作系统密钥链从所有这些无效的自签名证书中解放出来，Web 服务应该可以正常工作。请注意，如果您的服务器不是公开主机，您需要确保外部请求从您的 Web 入口点路由到您的服务器。

相关内容