Linux openssl CN/Hostname 針對 SSL 證書驗證

帶有 openssl 1.0.1+ 的 Enterprise Linux 系統如何驗證CN=hostname證書中的值是否與它所在的伺服器匹配？它是否對正在偵聽該 SSL Web 應用程序的適配器的 IP 地址使用普通的舊反向 DNS 查找？它是否使用一些 gethostname 庫函式？它會讀取 /etc/hosts 文件嗎？nsswitch.conf 是否起作用？

更新： 與其他人交談後，似乎這一切都是在瀏覽器/客戶端完成的。只要 URL 的主機部分與為該應用程序安裝的證書中的 C​​N 值匹配，瀏覽器就很高興，對嗎？

是的，您所描述的在技術上是正確的，但還有更多的事情要做。瀏覽器根據幾個指標判斷主機的 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=...包含的層次結構。

SNI

過去的情況是，您必須為要通過 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: 標頭類型的交換來解決此問題。

參考

• 將 OpenSSL 的 s_client 命令與使用伺服器名稱指示 (SNI) 的 Web 伺服器一起使用
• 傳輸層安全 - 維基百科

引用自：https://unix.stackexchange.com/questions/128370