HTTPS 常見部署問題及解決方案

在最近幾年裏，我寫了不少有關 HTTPS 和 HTTP/2 的文章，涵蓋了證書申請、Nginx 編譯及配置、性能優化等方方面面。在這些文章的評論中，很多讀者提出了各類各樣的問題，個人郵箱也常常收到相似的郵件。本文用來羅列其中有表明性、且我知道解決方案的問題。

爲了控制篇幅，本文儘可能只給出結論和引用連接，不展開討論，若有疑問或不一樣意見，歡迎留言討論。本文會持續更新，歡迎你們貢獻本身遇到的問題和解決方案。

實際上，遇到任何有關部署 HTTPS 或 HTTP/2 的問題，都推薦先用 Qualys SSL Labs's SSL Server Test 跑個測試，大部分問題都能被診斷出來。

申請 Let's Encrypt 證書時，一直沒法驗證經過

這類問題通常是由於 Let's Encrypt 沒法訪問你的服務器，推薦嘗試 acme.sh 的 DNS 驗證模式，通常都能解決。

網站沒法訪問，提示 ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

使用 Chrome 53 訪問使用 Symantec 證書的網站，極可能會出現這個錯誤提示。這個問題由 Chrome 的某個 Bug 引發，目前最好的解決方案是升級到 Chrome 最新版。相關連接：

• Out of date Chrome results in ERR_CERTIFICATE_TRANSPARENCY_REQUIRED for Symantec operated sites；
• Warning | Certificate Transparency error with Chrome 53；

瀏覽器提示證書有錯誤

檢查證書鏈是否完整

首先確保網站使用的是合法 CA 簽發的有效證書，其次檢查 Web Server 配置中證書的完整性（必定要包含站點證書及全部中間證書）。若是缺失了中間證書，部分瀏覽器可以自動獲取但嚴重影響 TLS 握手性能；部分瀏覽器直接報證書錯誤。

What's My Chain Cert? 這個網站能夠用來檢查證書鏈是否完整，它還能夠用來生成正確的證書鏈。

檢查瀏覽器是否支持 SNI

若是隻有老舊瀏覽器（例如 IE8 on Windows XP）提示這個錯誤，多半是由於你的服務器同時部署了使用不一樣證書的多個 HTTPS 站點，這樣，不支持 SNI（Server Name Indication）的瀏覽器一般會得到錯誤的證書，從而沒法訪問。

要解決瀏覽器不支持 SNI 帶來的問題，能夠將使用不一樣證書的 HTTPS 站點部署在不一樣服務器上；還能夠利用 SAN（Subject Alternative Name）機制將多個域名放入同一張證書；固然你也能夠直接無視這些老舊瀏覽器。特別地，使用不支持 SNI 的瀏覽器訪問商業 HTTPS CDN，基本都會由於證書錯誤而沒法使用。

有關 SNI 的更多說明，請看「 關於啓用 HTTPS 的一些經驗分享（二）」。

檢查系統時間

若是用戶電腦時間不對，也會致使瀏覽器提示證書有問題，這時瀏覽器通常都會有明確的提示，例如 Chrome 的 ERR_CERT_DATE_INVALID。

啓用 HTTP/2 後網站沒法訪問，提示 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

這個問題通常是因爲 CipherSuite 配置有誤形成的。建議對照「Mozilla 的推薦配置、CloudFlare 使用的配置」等權威配置修改 Nginx 的 ssl_ciphers 配置項。

有關這個問題的具體緣由，請看「 從啓用 HTTP/2 致使網站沒法訪問提及」。

網站沒法訪問，提示 ERR_SSL_VERSION_OR_CIPHER_MISMATCH

出現這種錯誤，一般都是配置了不安全的 SSL 版本或者 CipherSuite —— 例如服務器只支持 SSLv3，或者 CipherSuite 只配置了 RC4 系列，使用 Chrome 訪問就會獲得這個提示。解決方案跟上一節同樣。

還有一種狀況會出現這種錯誤 —— 使用不支持 ECC 的瀏覽器訪問只提供 ECC 證書的網站。例如在 Windows XP 中，使用 ECC 證書的網站只有 Firefox 能訪問（Firefox 的 TLS 本身實現，不依賴操做系統）；Android 平臺中，也須要 Android 4+ 才支持 ECC 證書。

針對不支持 ECC 證書的瀏覽器，有一個完美的解決方案，請看「 開始使用 ECC 證書」。

在 Nginx 啓用 HTTP/2 後，瀏覽器依然使用 HTTP/1.1

Chrome 51+ 移除了對 NPN 的支持，只支持 ALPN，而瀏覽器和服務端都支持 NPN 或 ALPN，是用上 HTTP/2 的大前提。換句話說，若是服務端不支持 ALPN，Chrome 51+ 沒法使用 HTTP/2。

OpenSSL 1.0.2 纔開始支持 ALPN —— 不少主流服務器系統自帶的 OpenSSL 都低於這個版本，因此推薦在編譯 Web Server 時本身指定 OpenSSL 的位置。

詳見「 爲何咱們應該儘快支持 ALPN」。

升級到 HTTPS 後，網站部分資源不加載或提示不安全

記住一個原則：HTTPS 網站的全部外鏈資源（CSS、JS、圖片、音頻、字體文件、異步接口、表單 action 地址等等）都須要升級爲 HTTPS，就不會遇到這個問題了。

詳見「 關於啓用 HTTPS 的一些經驗分享（三）」。

僅 Safari、iOS 各類瀏覽器沒法訪問

若是你的 HTTPS 網站用 PC Chrome 和 Firefox 訪問一切正常，但 macOS Safari 和 iOS 各類瀏覽器沒法訪問，有多是 Certificate Transparency 配置有誤。固然，若是你以前沒有經過 TLS 擴展啓用 Certificate Transparency，請跳過本小節。

具體症狀是：經過 Wireshark 抓包分析，一般能看到名爲 Illegal Parameter 的 Alert 信息；經過 curl -v 排查，通常能看到 Unknown SSL protocol error in connection 錯誤提示。

這時候，請進入 Nginx ssl_ct_static_scts 配置指定的目錄，檢查 SCT 文件大小是否正常，尤爲要關注是否存在空文件。

須要注意的是：根據 官方公告，從 2016 年 12 月 1 日開始，Google 的 Aviator CT log 服務將再也不接受新的證書請求。用 ct-submit 等工具手動獲取 SCT 文件時，不要再使用 Aviator 服務，不然就會獲得空文件。

更新：nginx-ct 的做者已經發布了 v1.3.2，針對零字節的 SCT 文件作了處理，再也不發送。

將 OpenSSL 升級到 1.1.0+，IE8 沒法訪問

形成這個問題的根本緣由是 OpenSSL 1.1.0+ 默認禁用了 3DES 系列的 Cipher Suites：

For the 1.1.0 release, which we expect to release tomorrow, we will treat triple-DES just like we are treating RC4. It is not compiled by default; you have to use 「enable-weak-ssl-ciphers」 as a config option. via

升級到 OpenSSL 1.1.0+ 以後，要麼選擇不支持 Windows XP + IE8；要麼在編譯時加上 enable-weak-ssl-ciphers 參數。例如這是個人 Nginx 編譯參數：

./configure --add-module=../ngx_brotli --add-module=../nginx-ct-1.3.2 --with-openssl=../openssl --with-openssl-opt='enable-tls1_3 enable-weak-ssl-ciphers' --with-http_v2_module --with-http_ssl_module --with-http_gzip_static_module