提醒：本文最後更新於 536 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

在最近幾年裡，我寫了很多有關 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 最新版。相關連結：

瀏覽器提示證書有錯誤

檢查證書鏈是否完整

首先確保網站使用的是合法 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，基本都會因為證書錯誤而無法使用。

檢查系統時間

如果使用者電腦時間不對，也會導致瀏覽器提示證書有問題，這時瀏覽器一般都會有明確的提示，例如 Chrome 的 ERR_CERT_DATE_INVALID。

啟用 HTTP/2 後網站無法訪問，提示 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

這個問題一般是由於 CipherSuite 配置有誤造成的。建議對照「Mozilla 的推薦配置、CloudFlare 使用的配置」等權威配置修改 Nginx 的 ssl_ciphers 配置項。

網站無法訪問，提示 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 的位置。

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

記住一個原則：HTTPS 網站的所有外鏈資源（CSS、JS、圖片、音訊、字型檔案、非同步介面、表單 action 地址等等）都需要升級為 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

--EOF--

發表於 2016-12-12 23:50:26 ，並被新增「 Nginx 、 HTTPS 、 HTTP2 」標籤 ，最後修改於 2017-06-17 09:19:51 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 536 天前，文中所描述的資訊可能已發生改變，請謹慎使用。