HTTPS 握手中的证书链验证：从浏览器到服务端的完整排查路径

HTTPS 握手的核心目标之一，是让客户端确认“我正在通信的服务端，确实持有该域名对应的合法证书与私钥”。而证书链验证，正是这个确认过程的关键环节。很多看似玄学的 HTTPS 报错，比如 NET::ERR_CERT_AUTHORITY_INVALID、unable to get local issuer certificate、certificate verify failed，本质上都和证书链是否完整、是否可被正确构建有关。

这篇文章会沿着一次 TLS 握手的真实路径，从浏览器到服务端，再到常见工具链，梳理证书链验证的完整排查思路。

一、证书链验证到底在验证什么

证书链验证不是“只看服务器发来的那张证书”，而是要做几件事：

1. 构建链：从站点证书出发，逐级找到签发它的中间 CA，再找到根 CA。
2. 验证签名：每一级证书的签名必须能被上一级公钥验证通过。
3. 检查有效期：所有证书都必须在有效期内。
4. 检查用途：CA 证书必须允许签发下级证书，站点证书必须匹配域名。
5. 检查吊销状态：通过 CRL 或 OCSP 判断证书是否被吊销。
6. 信任锚点：最终必须落到客户端本地信任的根证书库中。

其中最容易出问题的，是第 1 步和第 6 步。服务端如果只发送站点证书，不发送中间 CA 证书，浏览器可能通过 AIA 自动补全，但很多命令行工具、Java 客户端、移动端 SDK 不会自动补全，于是直接失败。

二、从浏览器侧看：为什么浏览器有时正常，有时报错

浏览器通常内置了较完整的根证书库，并且支持 AIA Fetching。也就是说，如果服务端没有发送中间证书，浏览器可能自己去下载缺失的中间证书，然后完成验证。这会造成一种假象：浏览器访问正常，但服务端配置其实不完整。

排查浏览器侧问题时，可以重点看：

• 点击地址栏锁图标，查看证书路径是否完整。
• 在开发者工具 Security 面板中确认协议、密钥交换和证书链。
• 如果出现 ERR_CERT_AUTHORITY_INVALID，优先怀疑根证书不受信任或中间证书缺失。
• 如果出现 ERR_CERT_DATE_INVALID，检查系统时间与证书有效期。
• 如果只有部分客户端报错，往往是链不完整或 SNI 配置问题。

浏览器正常不代表证书链没有问题，只代表浏览器帮你兜底了。

三、从服务端侧看：链不完整是最常见根因

服务端在 TLS 握手中发送的证书消息，应该包含“站点证书 + 所有中间 CA 证书”，通常不包括根证书。根证书由客户端本地信任库提供。

常见错误配置包括：

• Nginx 中 ssl_certificate 只配置了站点证书，没有拼接中间证书。
• Apache 中 SSLCertificateChainFile 缺失或路径错误。
• 负载均衡器只上传了站点证书，未上传中间证书。
• 证书链顺序错误，站点证书不在最前面。
• 使用了交叉签名证书，但只发送了其中一条链。

正确的 Nginx 配置通常是：

ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/private.key;

其中 fullchain.pem 应包含站点证书和中间 CA 证书，顺序为：

站点证书
中间 CA 证书
根 CA 证书（可选，通常不需要）

可以用以下命令快速检查服务端实际发送的链：

openssl s_client -connect example.com:443 -servername example.com -showcerts

如果输出中只有一张证书，基本可以确定链不完整。

四、从命令行工具看：不同客户端的信任策略差异

不同客户端对证书链的处理差异很大：

• OpenSSL：默认不会自动补全中间证书，链不完整时容易报 unable to get local issuer certificate。
• curl：基于 OpenSSL 或系统 TLS 库，行为取决于编译选项。
• Java：使用自己的 truststore，不读取系统根证书库，容易报 PKIX path building failed。
• Python requests：使用 certifi 根证书包，和系统库可能不一致。
• Go：使用系统根证书库，但对中间证书缺失较敏感。
• Android / iOS：各自有信任策略，Android 7 以后对用户证书信任更严格。

排查时不要只用一个工具验证。推荐组合使用：

openssl s_client -connect example.com:443 -servername example.com
curl -vI https://example.com

如果 OpenSSL 报错而浏览器正常，优先检查中间证书是否缺失。

五、一条完整的排查路径

遇到证书链验证问题时，可以按以下顺序排查：

1. 确认现象：是浏览器报错，还是命令行报错，还是特定客户端报错。
2. 检查服务端发送的链：用 openssl s_client -showcerts 查看实际发送了几张证书。
3. 检查链顺序：站点证书必须在前，中间证书在后。
4. 检查中间证书是否缺失：对比 CA 提供的 fullchain 文件。
5. 检查根证书信任：确认客户端信任库是否包含对应根证书。
6. 检查 SNI：多域名场景下，确认是否返回了正确证书。
7. 检查有效期与吊销状态：确认没有过期或被吊销。
8. 检查客户端差异：用不同工具交叉验证，定位是服务端问题还是客户端信任问题。
9. 修复后复验：重启服务后再次用 OpenSSL 和浏览器验证。
10. 监控与告警：对证书到期时间、链完整性做持续监控。

六、常见误区与建议

• 误区一：浏览器正常就说明配置正确。 浏览器会补全链，不能作为唯一标准。
• 误区二：根证书也要发给客户端。 通常不需要，客户端本地已有信任根。
• 误区三：只要证书没过期就没问题。 链不完整、顺序错误、SNI 错误都会导致验证失败。
• 误区四：所有客户端行为一致。 Java、OpenSSL、浏览器差异很大，必须交叉验证。

建议在证书部署流程中固定加入两步：一是用 openssl s_client 检查链完整性，二是用至少两种不同客户端做验证。对于多域名、多 CDN、多负载均衡场景，还要确认每个入口都配置了完整链。

结语

证书链验证看似只是 TLS 握手中的一小步，但它连接了服务端配置、CA 签发体系、客户端信任库和网络中间设备。排查时，关键不是盲目重启或重新签发，而是沿着“服务端发送了什么链、客户端如何构建链、最终信任锚点在哪里”这条路径逐层定位。只要把链完整性和客户端差异这两件事查清楚，绝大多数 HTTPS 证书报错都能迎刃而解。

未经允许不得转载：任鹏个人博客 » HTTPS 握手中的证书链验证：从浏览器到服务端的完整排查路径