HTTPS 证书链不完整排查实战：有人打得开有人打不开，openssl showcerts 判读与 fullchain 修复

  1.  Home
  2. Text  
    3. Share to：

现象：浏览器打不开网站，命令行却一切正常

这类故障最有迷惑性。用 curl -I https://你的域名 一看,HTTP 200,证书也显示正常;但用户的浏览器却报"您的连接不是私密连接"或者"证书无效",而且换一个浏览器、换一台电脑,报错还不一样。有的人能打开,有的人打不开——这通常不是证书本身过期,而是证书链不完整。

证书链不完整是 HTTPS 配置里最容易被忽略、又最难自查的问题。因为大多数现代浏览器会通过 AIA(Authority Information Access)机制自动去补下载缺失的中间证书,于是"你测试正常";但部分安卓 App、老版本浏览器、Java 客户端、以及各种爬虫和 API 调用方不会自动补链,直接判定失败。这篇文章讲清楚怎么诊断、怎么修、以及怎么验证修好了。

先搞清楚:一张证书发出去,链上有三段

要理解这个问题,先得知道浏览器在握手时收到的是什么。服务器在 TLS 握手中返回的不是"一张证书",而是一条证书链:

服务器证书(你的域名证书,由中间 CA 签发)
   ↓ 由谁签的?
中间证书(Intermediate CA,由根 CA 签发)
   ↓ 由谁签的?
根证书(Root CA,预装在操作系统/浏览器里)

浏览器验证逻辑是:从你发来的链路里,一路找到自己信任库里预装的根证书。如果链路断了——比如服务器只发了"服务器证书",没发"中间证书"——浏览器就无法把这条链接到根上。

那为什么多数浏览器又能打开?因为它们发现缺少中间证书后,会去读你服务器证书里携带的 AIA 扩展字段,自动联网下载中间证书补上。这个补链行为是"尽力而为"的:有的客户端会补,有的不会;网络受限时补不了。所以证书链不完整的典型症状就是"一部分人能访问,一部分人不能"。

诊断第一步:命令行看服务器到底发了什么

排查这件事,不能只看"能连上",必须看服务器返回的完整链路。用 openssl s_client 的 -showcerts 参数:

echo | openssl s_client -connect www.你的域名:443 -servername www.你的域名 -showcerts 2>/dev/null | grep -E "s:|i:"

注意输出里每一张证书都以 s:(subject,持有者)和 i:(issuer,签发者)成对出现。关键判读规则:

  • 如果只看到一对 s:/i:,说明服务器只发了服务器证书,没发中间证书——这就是不完整。
  • 如果看到两对或三对,检查最上面一张的 issuer 是否等于最下面一张的 subject,链路能首尾相连才算完整。

-servername 参数不能省。它触发 SNI,让服务器知道你访问的是哪个域名——多域名站点上不传这个参数,服务器可能返回默认证书,得出错误结论。

还有一个更直观的办法,用 openssl 直接验证链的完整性:

echo | openssl s_client -connect www.你的域名:443 -servername www.你的域名 2>/dev/null | openssl x509 -noout -subject -issuer -dates

它会打印证书的持有者、签发者和有效期。记录下 issuer(签发者),然后确认这个签发者证书是否也被服务器一并发送了——如果 -showcerts 只返回一张,而这张的 issuer 又不是某个根 CA,那就是缺中间证书。

诊断第二步:用外部工具做交叉验证

本地命令行有时受网络和 OpenSSL 版本影响。更权威的做法是用在线 SSL 检测工具,它们会明确列出链的完整性和缺失项。几个看点:

  • 证书链是否完整:好的工具会直接标注 chain issues: incomplete。这是最直接的证据。
  • 是否有多余的根证书:另一种错误是"发多了"——把根证书也发给了客户端。这会让握手包变大,虽然多数客户端能容忍,但不规范。
  • 证书顺序:服务器证书必须在最前,中间证书在后。顺序错了,有的客户端会解析失败。

两个方向的错误都要看:少了中间证书会失败,发错顺序也可能失败。很多站长只关注"有没有发",却忽略了"发的顺序对不对"。

修复:把 fullchain 配上去,而不是单个 cert

知道问题后,修复本身很简单——让服务器发送完整的链。以 Nginx 为例,关键在于 ssl_certificate 这一行指向的文件内容:

server {
    listen 443 ssl;
    server_name www.你的域名;

    # 必须指向 fullchain(服务器证书 + 中间证书),不能只指向单张 cert
    ssl_certificate     /etc/letsencrypt/live/你的域名/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/你的域名/privkey.pem;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

这里有一个极高频的错误:很多人把 ssl_certificate 指向了 cert.pem。这两个文件的区别正是本问题的核心:

  • cert.pem:只有你的服务器证书这一张。
  • fullchain.pem:服务器证书 + 中间证书,即完整的链。

正确做法是永远用 fullchain.pem。如果你不是用 Let's Encrypt 自动签发的,就需要手动把中间证书拼接进证书文件。拼接方式是:先放服务器证书,后面紧跟中间证书,顺序不能反:

# 手动拼接:顺序必须是 服务器证书 -> 中间证书
cat 你的域名.crt intermediate.crt > fullchain.pem

中间证书要从 CA 的官方仓库下载,别从第三方站点随便拷——拿到过期或错误的中间证书,问题会更难查。

连带陷阱一:证书文件权限与 reload 没生效

改完配置不等于生效。两个常见连带问题:

一是只在主配置改了,站点配置里还是旧的。Nginx 允许在 http、server 两层分别指定 ssl_certificate,后加载的 server 块配置会覆盖上层。如果站点有独立的 server 配置文件,务必确认改的是真正生效的那一处。快速定位方法:

nginx -T 2>/dev/null | grep -n "ssl_certificate"

nginx -T 会打印合并后的完整配置,你可以看到所有生效的 ssl_certificate 行以及它们所属的 server 块。永远以 nginx -T 的输出为准,而不是你手改的那个文件。

二是证书文件权限。Let's Encrypt 的 live 目录里是符号链接,指向 archive 下的真实文件。如果 Nginx 的工作进程用户读不到这些文件,会在启动或 reload 时报权限错误。密码私钥(privkey)权限必须严格,但证书链文件只需可读即可:

chmod 644 /etc/letsencrypt/live/你的域名/fullchain.pem
ls -l /etc/letsencrypt/live/你的域名/fullchain.pem  # 确认指向的 archive 文件也在

改完执行 nginx -t 检查语法,再 nginx -s reload 平滑重载。reload 前一定先 nginx -t:配置有语法错误时 reload 会保留旧进程继续服务,但你可能误以为新配置已生效,白排查半天。

连带陷阱二:CDN 层与源站的证书是两回事

如果你的站点套了 CDN,还要分清楚"用户看到的是谁的证书"。CDN 通常有两种模式:

  • 用户 ↔ CDN 边缘:使用 CDN 自己签发的边缘证书。这一段有问题,要在 CDN 控制台配置,改源站没用。
  • CDN 边缘 ↔ 源站(回源):使用你源站上的证书。这一段有问题,表现为 CDN 报 502/526 之类的回源错误,用户看到的是"网站无法访问",而不是证书警告。

所以当用户报证书错误时,第一步要确认他连的是 CDN 边缘还是直连源站。测试源站证书要绕过 CDN,直接连源站 IP 并带上 SNI:

echo | openssl s_client -connect 你的源站IP:443 -servername www.你的域名 -showcerts 2>/dev/null | grep -E "s:|i:"

如果源站证书链完整而 CDN 边缘不完整,问题在 CDN 的证书配置里,可能是回源协议或证书上传那里缺了中间证书。

修复后如何验证:三个必须同时通过的检查

改完不能只看"我能访问",要按下面三条验证:

# 1. 链路是否完整(应看到至少两对 s:/i:)
echo | openssl s_client -connect www.你的域名:443 -servername www.你的域名 -showcerts 2>/dev/null | grep -c "i:"

# 2. 验证是否真的通过(输出应以 "Verify return code: 0 (ok)" 结尾)
echo | openssl s_client -connect www.你的域名:443 -servername www.你的域名 2>/dev/null | grep "Verify return code"

# 3. 用两个不同客户端交叉验证(浏览器 + curl,或换一台机器)
curl -sI https://www.你的域名 | head -1

三条一起看才可靠:只测一个客户端可能被 AIA 自动补链掩盖问题。这也是这类故障长期潜伏的原因——你本机测试永远正常,但总有用户报错。

最后强调一个习惯:每次续期证书、换 CDN、改服务器配置之后,都跑一遍上面的第一、二条命令。证书链完整性应该作为一个固定检查项写进你的上线流程,它只要几秒钟,却能在用户报错之前拦住一个很丢信任的问题。HTTPS 的问题用户往往不敢点"继续访问",每一个证书警告都可能直接赶走一个访客。

Last modification：September 26th, 2026 at 07:27 pm
© 允许规范转载

相关文章

Leave a Comment