使用 openssl 1.0.1+ 的 Enterprise Linux 系统如何验证CN=hostname证书中的值是否与其所在的服务器匹配？它是否对正在侦听该 SSL Web 应用程序的适配器的 IP 地址使用普通的旧式反向 DNS 查找？它是否使用一些 gethostname 库函数？它会读取/etc/hosts 文件吗？ nsswitch.conf 起作用吗？
更新： 与其他人交谈后，看来这一切都是在浏览器/客户端完成的。只要 URL 的主机部分与为该应用程序安装的证书中的 CN 值匹配，浏览器就会满意，对吗？
答案1
是的，您所描述的在技术上是正确的，但还有更多的事情发生。浏览器根据一些指标来确定主机的 CN 是否正确。
主要指示是，为 HTTPS 流量的 SSL 证书提供服务的主机是从正确的域提供服务的，并且基于颁发和链签名证书的 CA（证书颁发机构），证书的签名链也是正确的。
您可以使用openssl'ss_client来了解浏览器也将执行的来回操作。
例子
$ openssl s_client -connect encrypted.google.com:443 < /dev/null | head -10
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
...
...
DONE
如果您使用此命令，您会注意到生成 SSL 证书时使用的 CN：
$ openssl s_client -connect encrypted.google.com:443 < /dev/null|& grep "CN.*google"
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
CN=...因此，浏览器将确认提供此证书的主机名属于证书中包含的主机名的层次结构。
神经网络研究所
过去的情况是，您必须为要通过 HTTPS 使用的每个 SSL 服务器的主机名预留一个特定的 IP 地址。然而，由于 SNI（服务器名称指示），这种情况不再是这样。
摘抄
当站点为每个 IP 地址安装一个 SSL 证书时，这种方法非常有效（这曾经是一项硬性要求）。通过服务器名称指示 (SNI)，Web 服务器可以在同一 IP 地址上安装多个 SSL 证书。支持 SNI 的浏览器将指定它们在初始握手过程中尝试访问的服务器的主机名。这允许 Web 服务器确定用于连接的正确 SSL 证书。
再次使用openssl您可以模拟浏览器在这种情况下会执行的操作：
$ openssl s_client -connect someserver:443 -servername sslsite-example.com
摘抄
SSL 协商必须在将 HTTP 请求发送到远程服务器之前进行。这意味着浏览器和服务器必须在此过程的早期进行证书交换，并且浏览器将没有机会指定它试图访问哪个站点。 SNI 通过允许在 SSL 协商过程中交换 Host: 标头类型来修复此问题。