使用 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: 標頭類型來修復此問題。