本文和大家分享的主要是HTTPS常见的部署问题及相应的解决方案，希望通过本文的分享能帮助大家更好的学习https相关知识，一起来看看吧。

实际上，遇到任何有关部署 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 54+。

浏览器提示证书有错误

首先确保网站使用的是合法 CA 签发的有效证书，其次检查 Web Server 配置中证书的完整性（一定要包含站点证书及所有中间证书）。如果缺失了中间证书，部分浏览器能够自动获取但严重影响 TLS 握手性能；部分浏览器直接报证书错误。

如果只有老旧浏览器（例如 IE8 on Windows XP）提示这个错误，多半是因为你的服务器同时部署了使用不同证书的多个 HTTPS 站点，这样，不支持 SNI（Server Name Indication）的浏览器通常会获得错误的证书，从而无法访问。

要解决浏览器不支持 SNI 带来的问题，可以将使用不同证书的 HTTPS 站点部署在不同服务器上；还可以利用SAN（Subject Alternative Name）机制将多个域名放入同一张证书；当然你也可以直接无视这些老旧浏览器。特别地，使用不支持 SNI 的浏览器访问商业 HTTPS CDN，基本都会因为证书错误而无法使用。

有关 SNI 的更多说明，请看「 关于启用 HTTPS 的一些经验分享（二） 」。

启用 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 证书」。

在 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，就不会遇到这个问题了。

来源：JerryQu的小站

HTTPS部署常见的问题及解决方案详解