在我的网络上，我配置了 DNS 域搜索，这样resolv.conf如果您调用getaddrinfo简单主机名，它将返回其 FQDN 的结果。
$ host wiki
wiki.example.com has address 10.0.0.2
$ dig +short wiki
$ dig +short wiki.example.com
10.0.0.2
（DNS 服务器不会响应不合格的名称，这一切都是在 中完成的libc。）
我已经在监听的 Web 服务器上配置了 TLS 证书https://wiki.example.com，该 TLS 证书是由 CN 的公共 CA 颁发的wiki.example.com。
在配置 HTTPS 之前，浏览器中可以使用非限定名称。因此输入wiki/chromium (eg) 即可。但是，现在已配置 TLS，浏览器会抱怨证书上的常见名称不匹配，因为它们对 / 进行了 DNS 查找，wiki但提供的 TLS 证书是针对 的wiki.example.com。
这很不幸，因为这是安全性与可用性之间的权衡之一，其实并不需要存在。传递AI_CANONNAME到getaddrinfo将对解析为 的地址进行反向 DNS 查找wiki，并将（至少在某些情况下）返回wiki.example.com。除此之外，可能还有其他机制getaddrinfo可以以更强大的方式公开域搜索。
我的问题是，是否有办法设置操作系统/浏览器，使它们知道域搜索？理想情况下，如果 Chromium 发现输入了不合格的主机名，它会在继续执行任何进一步的逻辑之前附加域。然后 TLS 证书就会匹配，一切都会好起来。
我可以想到一些次优的方法来实现我想要的目标：
- 检测
HostHTTP 连接上的标头是否具有不合格名称，并通过 HTTPS 将 HTTP 重定向到 FQDN。 - 在 TLS 证书上将非限定名称作为 SAN 颁发。
- 使用浏览器书签并停止使用不合格的名称。
- 使用 FQDN 的“跳转页面”（即充满链接的页面，托管在令人难忘的位置）。
第一种方法有几个问题。首先，它只在初始连接是 HTTP 时才有效，而由于 HSTS 之类的东西，HTTP 正在走向灭绝。其次，它需要对服务器进行严格控制，而这并不总是可行的（例如，具有 Web 界面的低功耗 IoT 设备）。
如果证书是由公共 CA 颁发的（这是通过重要他人/客人测试的必要条件），则第二种情况是不可能的。
第三个没有用，因为也没有通过“重要他人/客人”测试。
第四种方法可能有效，这取决于传达跳转页面地址的难易程度。这与传达 WiFi 名称和密码的难度是同一个数量级。