☰

拥有与 SSL 证书 CN 不匹配的 CNAME 是不是不好的做法？

tag-icon • tag-icon domain-name-system ssl-certificate cname-record
拥有与 SSL 证书 CN 不匹配的 CNAME 是不是不好的做法？

场景是这样的...

$ openssl x509 -subject -noout -in cert.crt
subject= /CN=example.org

$ curl -I "https://example.org"
HTTP/1.1 200 OK

$ dig example.org
example.org.           60      IN      A       192.0.2.1

$ dig foo.example.org
foo.example.org.       60      IN      CNAME   example.example2.com.
example.example2.com.  60      IN      A       192.0.2.1

$ curl -I "https://foo.example.org"
HTTP/1.1 200 OK

$ curl -I "https://example.example2.com"
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

当使用别名时，foo.example.org我看不到 CNAME example.example2.com。因此，CNAME 与证书名称不匹配并不重要。

但有人问我这三个名字中的哪一个应该可以使用。我的答案是，除了 SSL 之外，这三种都可以使用example.example2.com。

从最终用户的角度来看，这对我来说似乎很奇怪。证书告诉我example.org是受信任的名称，但组织在域中的记录example.org告诉我，另一个域中不受信任的名称是规范（官方）名称。

此外，example.org还有example2.comSOA 记录。带有子域的名称不会有 SOA 记录。我不确定 SOA 记录是否与应被视为合理的规范名称有关。

答案1

首先，为了确保证书验证本身不会造成混淆，DNS 不是证书主题名称验证过程的一个因素。

HTTPS 客户端无需知道或关心CNAME名称解析过程中是否遇到记录。它仅使用 URL 主机名对应的 IP 地址来建立连接，然后在验证服务器提供的证书是否有效时直接比较 URL 主机名和主题名称。


至于“应该使用这三个名称中的哪一个？”的问题，如果服务/站点的所有者只决定应该使用一个名称并让每个人都清楚地使用该名称，他们将省去一些麻烦。

如果这是关于一个网站，通常为任何对备用名称的请求设置 HTTP 重定向，将这些请求重定向到首选名称（这将清楚地说明哪个名称是首选的）。

如果这是关于 API 或其他重定向实际上不起作用的服务，则首选名称可能至少在服务描述/文档中提供。

人们还可以合理地预期首选名称具有有效的证书，以便客户端可以使用 HTTPS（非常常态）。

我刻意避免使用“规范名称”这个术语，以便将这种推理与CNAME记录类型明确区分开来。

如果没有其他信息，CNAME您看到的任何记录实际上只能被假定为对域所有者希望解析器遵循以完成查找的不同名称的引用。由于记录被广泛用作提供通用间接寻址的黑客手段（通常在理论上有意义但客户端无法感知的地方，例如普通 HTTP/HTTPS 客户端），因此
“规范名称”方面已基本消失。CNAMESRVSRV

相关内容