OpenSSL 返回的 SSL 證書與 Chrome 顯示的證書不同
使用以下命令使用 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 轉發有其自身的嚴重挑戰（超出本文件的範圍），遠遠超過了增加的轉發困難。
CloudFront 使用 SNI，這是一種能夠在單個 IP 上使用多個證書的方式。所有現代瀏覽器都支持這一點，openssl 的 s_client 命令也是如此，但 s_client 並沒有神奇地做到這一點。你必須告訴它使用它：
openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts
Chrome 支持SNI，告訴伺服器要發送哪個證書。該
s_client命令沒有。這裡有更多關於 CloudFront 使用 SNI 的詳細資訊。
當您使用 SNI 自定義 SSL 時，某些使用者可能無法訪問您的內容，因為某些舊版瀏覽器不支持 SNI，並且無法與 CloudFront 建立連接以載入您的內容的 HTTPS 版本。有關 SNI 的更多資訊，包括支持的瀏覽器列表，請訪問我們的常見問題頁面。
和：
SNI 自定義 SSL 依賴於傳輸層安全協議的 SNI 擴展，該協議允許多個域通過包含查看器嘗試連接的主機名來通過同一 IP 地址提供 SSL 流量。與專用 IP 自定義 SSL 一樣，CloudFront 從每個 Amazon CloudFront 邊緣站點傳遞內容，並具有與專用 IP 自定義 SSL 功能相同的安全性。SNI Custom SSL 適用於大多數現代瀏覽器，包括 Chrome 版本 6 及更高版本（在 Windows XP 及更高版本或 OS X 10.5.7 及更高版本上執行）、Safari 版本 3 及更高版本（在 Windows Vista 及更高版本或 Mac OS X 10.5 上執行。 6. 及更高版本）、Firefox 2.0 及更高版本以及 Internet Explorer 7 及更高版本（在 Windows Vista 及更高版本上執行）。不支持 SNI 的舊版瀏覽器無法與 CloudFront 建立連接以載入您的內容的 HTTPS 版本。