在 TLS 證書和 MacOS 上尋求基本事實 - 比較瀏覽器、curl、openssl
在 Mac，High Sierra 10.13.5 上，我發現 TLS 認證驗證有所不同。訪問https://www.visitflorida.com時，Chrome 和 Safari 對 TLS 驗證感到滿意。此外，curl 沒有任何抱怨，我沒有使用“-k”。但是，openssl 抱怨它在嘗試 this 時找不到中間證書
openssl s_client -connect www.visitflorida.com:443 < /dev/null | openssl x509 -subject -noout。我已經使用了基本的 openssl 和 brew-installed 一個。我試圖添加 -CAfile intermediate.pem（我從 TrustWave 下載了中間證書）。即使中間證書沒有出現在我的 KeyChain 中的任何位置，我也已將我的 KeyChain System Roots 導出到一個文件中，並通過 -CAfile 進行了嘗試。沒有任何工作。我看到證書的唯一文件系統位置是 /etc/ssl/cert.pem，當我通過 -CAfile 指定它時，它仍然失敗。
有人建議我的瀏覽器和 curl 對 TLS 驗證的要求比 openssl 更寬鬆。真的是這樣嗎？我很難相信。誰能幫我解釋這種行為？
順便說一句，我知道這可以通過在 www.visitflorida.com 的 TLS 端點上包含中間證書和端點證書來解決。現在，如果我們能找到那個失去的密鑰文件！
瀏覽器快樂：
捲曲日誌：
瀏覽器，如 Internet Explorer/Edge、Chrome 和 Safari，將查看 AIA 擴展的 caIssuer 欄位以獲取 URL，如果在 TLS 握手期間伺服器未提供高級 CA 證書，它可以從該 URL 下載高級 CA 證書。
您網站的證書有一個 caIssuer 欄位設置為
http://ssl.trustwave.com/issuers/OVCA2_L1.crt因此上述所有瀏覽器將從該 URL 下載它並使用它來建構鏈。OpenSSL 等命令行工具
s_client不會使用 caIssuer 下載此附加證書，因此您目睹了這種情況。如果您要嘗試 Mozilla Firefox，您也會注意到同樣的情況，因為 Mozilla 拒絕使用此擴展程序。caIssuer 欄位最終掩蓋了真正的問題，即糟糕的伺服器管理員。 RFC 5246 第 7.4.2 節規定伺服器必鬚髮送
certificate_list由其自己的證書和任何中間 CA 證書組成的證書。