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