HTTPS 证书已部署，为什么部分设备仍打不开？证书链、SNI 与 TLS 兼容性排查指南

HTTPS 证书已经签发，浏览器地址栏也能显示锁形图标，但客服仍收到部分手机打不开、旧电脑提示证书错误、接入 CDN 后偶发 502 的反馈。这类问题往往不是证书有没有安装，而是不同访问路径拿到的证书、证书链和 TLS 策略并不一致。

排查时不要只用自己的浏览器刷新一次。浏览器可能缓存过中间证书，也可能始终命中同一个 CDN 节点。更有效的做法是先判断故障发生在客户端到 CDN，还是 CDN 到源站，再检查证书链、SNI、域名覆盖范围和 TLS 版本。

Table of Contents

Toggle

• 先根据现象缩小范围
• 第一步：确认客户端实际拿到了哪张证书
• 第二步：检查证书链是否完整
• 第三步：排查 SNI 和域名绑定
• 第四步：核对 TLS 版本和安全策略
• 第五步：检查 DNS、IPv4/IPv6 和多节点配置
• 第六步：区分边缘握手失败和回源握手失败
• 修复后如何验证
• 参考资料

先根据现象缩小范围

先记录失败设备、网络、时间、域名和完整错误信息。只有打不开三个字，很难判断是 DNS、TCP、TLS 还是 HTTP 层的问题。

第一步：确认客户端实际拿到了哪张证书

在可复现问题的网络中执行：

curl -Iv https://www.example.com/

重点查看连接 IP、TLS 版本、证书主题、签发者、有效期、校验报错和最终 HTTP 状态码。

再用 OpenSSL 查看服务端返回的证书链：

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com \
  -showcerts \
  -verify_return_error </dev/null

-servername 会发送 SNI，-showcerts 会显示服务器实际发送的证书列表。不要只看第一张证书的日期，还要确认叶子证书之后是否包含正确的中间证书。

可以继续提取常用字段：

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName

如果 subjectAltName 中没有当前访问域名，即使证书尚未过期，客户端仍会判定域名不匹配。

第二步：检查证书链是否完整

服务器通常需要发送叶子证书和中间证书，不应把根证书作为普通链路证书依赖客户端接收。若只配置了站点证书而没有中间证书，一些桌面浏览器可能因为缓存或自动补链而正常，证书库较旧的设备、Java 程序或命令行客户端却可能失败。

常见修复方式是使用证书服务商提供的完整链文件。例如 Nginx 的 ssl_certificate 文件应先放站点证书，再按签发关系追加中间证书：

server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
}

修改前备份原配置和证书文件，然后执行：

sudo nginx -t
sudo systemctl reload nginx

nginx -t 通过后再平滑重载。不要把私钥内容上传到在线检测工具，也不要在工单或聊天记录中粘贴私钥。

如果站点使用 CDN，需要分别确认两套证书链：访问者连接 CDN 边缘节点时收到的证书链，以及 CDN 通过 HTTPS 回源时源站返回的证书链。边缘证书正常，不代表源站证书也正常。

第三步：排查 SNI 和域名绑定

一台服务器或一个 CDN 节点可以承载多个 HTTPS 域名。客户端在 TLS 握手时通过 SNI 告诉服务器要访问哪个域名，服务器据此选择证书。域名没有绑定到正确的虚拟主机、CDN 配置未部署完成，或程序直接使用 IP 建立 HTTPS 连接时，都可能拿到默认证书。

对比带 SNI 和不带 SNI 的结果：

# 正常域名访问方式
openssl s_client -connect 203.0.113.10:443 \
  -servername www.example.com </dev/null

# 模拟未发送 SNI 的旧客户端或异常程序
openssl s_client -connect 203.0.113.10:443 \
  -noservername </dev/null

如果两次返回的证书不同，需要检查 Nginx/Apache 虚拟主机、CDN 加速域名与证书绑定、SAN 覆盖范围，以及健康检查或回源配置是否错误地使用 IP。

使用 IP 测试源站时，可以让 curl 仍携带正确的主机名和 SNI：

curl -Iv --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

这种方式比直接访问 https://203.0.113.10/ 更接近真实请求。

第四步：核对 TLS 版本和安全策略

部分旧系统不支持 TLS 1.3，甚至只能使用已经不建议启用的旧协议或旧密码套件。相反，一些新客户端会拒绝弱算法、过短密钥或不安全的签名方式。站点调整 CDN 安全策略后，故障经常集中出现在某一类设备。

可分别测试 TLS 1.2 和 TLS 1.3：

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -tls1_2 </dev/null

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -tls1_3 </dev/null

如果 TLS 1.2 失败而 TLS 1.3 正常，应检查 CDN 或服务器是否把最低版本设得过高。若业务必须支持旧终端，不要直接恢复已经淘汰的协议；先统计终端范围和安全影响，优先通过升级客户端、独立兼容域名或受限访问策略解决。

第五步：检查 DNS、IPv4/IPv6 和多节点配置

偶尔失败通常意味着访问路径不止一条。检查域名的 A、AAAA 和 CNAME 记录，并分别测试解析结果：

dig +short A www.example.com
dig +short AAAA www.example.com
dig +short CNAME www.example.com

curl -4Iv https://www.example.com/
curl -6Iv https://www.example.com/

如果 IPv4 正常、IPv6 失败，需要检查 AAAA 指向的服务是否部署了同一张证书和相同 TLS 配置。多源站或负载均衡场景还应逐个核对后端节点，避免只有部分节点使用了新证书。

CDN 配置变更后也要考虑传播时间。测试时记录实际连接 IP，并从不同网络复核，避免把单个节点的结果当成全网状态。

第六步：区分边缘握手失败和回源握手失败

访问者连不上 CDN 边缘节点时，通常会直接看到证书、协议或握手错误。访问者能完成 HTTPS 连接，但 CDN 无法与源站建立 TLS 时，前端更可能出现 502、503 或网关错误。

以 CloudFront 为例，如果回源使用 HTTPS，源站证书需要满足域名匹配、有效期、证书链和受信任 CA 等要求；源站返回的证书若与配置的 Origin Domain Name 或转发的 Host 不匹配，CloudFront 可能返回 502。

排查顺序应是：

1. 从公网检查边缘域名证书；
2. 使用正确的 SNI 和 Host 单独检查源站；
3. 核对 CDN 回源域名、端口和协议；
4. 检查源站日志是否收到请求；
5. 修复后重新测试边缘和源站两条链路。

修复后如何验证

至少完成以下检查：

• OpenSSL 校验返回成功，服务端发送完整证书链；
• 主域名、www 和业务子域名都被 SAN 覆盖；
• TLS 1.2/1.3 的支持范围符合业务预期；
• IPv4、IPv6 和主要 CDN 节点结果一致；
• 源站证书与 CDN 回源域名匹配；
• 失败设备或同版本模拟环境能够重新访问；
• 证书续期后，Web 服务和 CDN 配置会自动加载新证书。

证书排查最容易出现的误区，是看到自己的浏览器正常就认为部署完成。稳定的 HTTPS 需要域名、证书链、SNI、TLS 策略、DNS 路径和回源配置同时一致。把边缘和源站分开验证，再按设备与网络复测，通常能较快定位只有部分用户失败的原因。

参考资料

1. AWS CloudFront Developer Guide: Requirements for using SSL/TLS certificates with CloudFront

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html

1. AWS CloudFront Developer Guide: HTTP 502 status code (Bad Gateway)

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html

1. OpenSSL Documentation: openssl-s_client

https://docs.openssl.org/master/man1/openssl-s_client/

1. curl Documentation: SSL certificate verification

https://curl.se/docs/sslcerts.html

1. NGINX Documentation: Configuring HTTPS servers

https://nginx.org/en/docs/http/configuring_https_servers.html

1. Lets Encrypt: Chain of Trust

https://letsencrypt.org/certificates/

资料核查日期：2026-09-16。