HTTPS 证书链不完整怎么排查？浏览器差异与中间证书配置
浏览器能打开网站，并不一定说明所有客户端都能完成证书验证。有的设备可能缓存过中间证书，另一台新设备却没有这些信息，因此缺链问题可能表现得不一致。本文以 Nginx HTTPS 站点和 OpenSSL 3.x 客户端为例，排查实际握手发出的证书。
先区分链问题与其他证书错误
记录失败客户端、系统时间、访问域名与完整错误。证书过期、域名不在证书覆盖范围、私有 CA 未受信任，与中间证书缺失是不同问题。若同一域名经过 CDN，客户端通常首先看到边缘证书，不一定是源站证书。
确认问题发生在根域名还是某个子域名，以及是否只在 IPv6 或某个节点出现。多节点站点可能只有一台机器仍使用旧配置；一次成功测试无法替代逐入口核验。不要仅凭本地证书文件的内容判断外部实际收到什么。
查看服务器实际发送的证书
从可信管理电脑执行，替换成自己控制的域名。以下示例适用于 Linux、macOS 等支持该命令环境的终端：
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error -verify_hostname example.com </dev/null
-servername 指定 SNI 名称，-showcerts 显示服务器发来的证书，验证参数让错误更明确。系统信任库配置也会影响结果，应在正常维护的客户端上检查，而不是临时导入来历不明的根证书。OpenSSL s_client 手册
观察证书主体、签发者、有效期和验证结果。服务器发送的列表不一定等于客户端最终建立的完整信任路径，所以还要判断中间证书之间是否能衔接。给技术支持发送输出前，保留必要域名与错误，避免附带无关内部地址。
让 Nginx 使用正确的链文件
Nginx 的证书文件通常应先包含站点证书，再依次包含所需中间证书；一般不需要把根证书一起发送。私钥是另一份敏感文件，不能混入证书链，也不应该为了让服务读取而开放给所有用户。Nginx HTTPS 链配置说明
使用自动证书客户端时，优先引用它维护的完整链路径。不要从某次申请结果复制出一份文件后就忘记更新，否则续期任务可能成功，Nginx 却一直读取旧副本。手工管理时，应从签发机构的正式渠道取得适配的中间链。
修改前确认当前站点引用哪条路径，以及同一证书是否被其他站点复用。备份配置和可恢复的现有文件，保留权限；不要删除整个证书目录，也不要覆盖其他站点仍在使用的证书。
应用配置后再检查握手
更换链文件后先执行 sudo nginx -t，检查通过再重新加载。语法检查可以发现某些证书与私钥不匹配或文件读取问题，但仍应从外部重新握手，确认实际发送的链已经变化。
至少检查计划使用的域名、IPv4 与已启用的 IPv6；有 CDN 时分别验证边缘与源站对应入口。源站使用专用受信任机制时，应按其设计测试，不能以公众浏览器直连是否通过作为唯一标准。
把修复纳入续期与回退流程
在证书自动续期演练后再次验证外部握手，确认更新路径和服务重新加载环节都正常。监控要检查真正访问入口，而不是只读取磁盘上的到期日期。服务器时间、信任库更新和备用节点也应纳入维护记录。
若新链造成异常，恢复上一个经过验证且仍有效的配置与证书组合，再重新加载并检查。如果旧证书已经失效，应继续修复或暂时限制受影响功能，不能靠关闭客户端校验维持业务。将根因写清楚，区分“服务端缺中间证书”和“客户端信任配置异常”，避免下次重复误判。