OpenSSL 傳回與 Chrome 顯示的不同的 SSL 憑證

OpenSSL 傳回與 Chrome 顯示的不同的 SSL 憑證

使用 OpenSSL 查詢 Sparkfun 的 CDN url 時,請使用以下命令:

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

憑證中傳回的通用名稱為*.sparkfun.com,無法驗證,但如果在 Chrome 中載入主機,顯示的通用名稱為*.cloudfront.net

這裡發生了什麼事?

這會導致問題,因為我所在的環境透過 Squid SSL_Bump 代理 SSL,它會產生由我本地信任的網域 CA 簽署的憑證。這適用於除上述網域之外的所有網域,因為 CN 不匹配,因為新憑證是使用 OpenSSL 產生的。

編輯- 我已經驗證了遠端資料中心的伺服器上的 OpenSSL 也發生了同樣的情況,該伺服器直接連接到互聯網,不涉及代理或過濾。

編輯- 該問題是由於 SNI 造成的,已接受,但要填寫有關為何會導致 Squid 和 SSL_Bump 問題的資訊:

該專案將不支援將 SSL 伺服器名稱指示 (SNI) 資訊轉送至來源伺服器,並使此類支援變得更加困難。然而,SNI 轉送有其自身嚴峻的挑戰(超出了本文檔的範圍),遠遠超過了增加的轉送困難。

取自:http://wiki.squid-cache.org/Features/BumpSslServerFirst

答案1

CloudFront 使用 SNI,這是一種能夠在單一 IP 上使用多個憑證的方式。所有現代瀏覽器都支援這一點,openssl 的 s_client 指令也是如此,但 s_client 並沒有神奇地做到這一點。你必須告訴它使用它:

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

答案2

Chrome 支援神經網路研究所,告訴伺服器要傳送哪個憑證。該s_client命令沒有。

有關 CloudFront 使用 SNI 的更多詳細信息這裡

當您使用 SNI 自訂 SSL 時,某些使用者可能無法存取您的內容,因為某些較舊的瀏覽器不支援 SNI,且無法與 CloudFront 建立連線以載入 HTTPS 版本的內容。有關 SNI 的更多信息,包括支援的瀏覽器列表,請訪問我們的常問問題頁。

和:

SNI 自訂 SSL 依賴傳輸層安全協定的 SNI 擴展,該協定允許多個網域透過包含檢視器嘗試連線的主機名稱來透過相同 IP 位址提供 SSL 流量。與專用 IP 自訂 SSL 一樣,CloudFront 從每個 Amazon CloudFront 邊緣網站交付內容,並具有與專用 IP 自訂 SSL 功能相同的安全性。 SNI 自訂SSL 適用於大多數現代瀏覽器,包括Chrome 版本6 及更高版本(在Windows XP 及更高版本或OS X 10.5.7 及更高版本上運行)、Safari 版本3 及更高版本(在Windows Vista 及更高版本或Mac OS X 10.5 上執行)。不支援 SNI 的舊版瀏覽器無法與 CloudFront 建立連線來載入 HTTPS 版本的內容。除了標準 CloudFront 資料傳輸和請求費用之外,SNI 自訂 SSL 無需額外付費。

相關內容