OpenSSL verify报error 20：CAfile、fullchain与本地信任链分层排查

先看懂 error 20 到底在说什么看到unable to get local issuer certificate很多人先想到证书过期。其实 OpenSSL 的verify是在当前信任材料里找不到能继续向上构链的签发者。常见场景是叶子证书已换新服务端能完成 TLS 握手但客户端拿不到中间证书于是报error 20 at 0 depth lookup。四个文件先分角色叶子、根、untrusted 与 fullchain叶子证书是给域名用的终端证书根证书是客户端信任的锚点中间证书负责把叶子连接到根。对openssl verify来说-CAfile表示信任锚点-untrusted表示“可以拿来拼链、但不因此直接信任”的中间证书。Nginx 的ssl_certificate文件则有另一个交付语义主证书在前中间证书紧随其后也就是常说的fullchain.pem。因此“把中间证书放进 CAfile”不是服务器链配置的替代方案“本机 verify 成功”也不等于客户端从 HTTPS 服务端收到了完整链。第一步确认 PEM 对象和 issuer 没拿错不要只看文件名。先把证书的主题、签发者、序列号和 SAN 读出来再比较叶子证书的issuer是否对应中间 CA 的subject。如果 issuer 对不上继续补证书只是在错误链上堆文件。set -eu for f in leaf.pem intermediate.pem root.pem; do echo --- $f --- openssl x509 -in $f -noout -subject -issuer -serial -dates openssl x509 -in $f -noout -text | grep -A1 -E Subject Alternative Name|Basic Constraints done openssl x509 -in leaf.pem -noout -checkend 0-checkend 0只回答“当前是否已经过期”不能证明签发者可达更不能替代整条链验证。证书格式能被x509读出来也不代表 Nginx 发送的顺序正确。第二步用 CAfile 与 untrusted 重现 error 20下面是最小的验证对照。根证书放在信任锚点中间证书先故意不提供再通过-untrusted提供。我的隔离实验在 OpenSSL 1.1.1k FIPS 上复现了原文缺中间证书时为error 20 at 0 depth lookup: unable to get local issuer certificate补上中间证书后输出leaf.pem: OK临时目录随后删除。# 只信任根故意缺中间证书 openssl verify -CAfile root.pem leaf.pem # 根是信任锚点中间证书只用于构链 openssl verify -CAfile root.pem \ -untrusted intermediate.pem leaf.pem # 显示实际构造出的链支持时使用 openssl verify -show_chain -CAfile root.pem \ -untrusted intermediate.pem leaf.pem命令失败时请保留完整 stderr 和退出码。此次实验的缺中间证书退出码为 2它说明当前材料不足不直接说明线上一定没发中间证书。反过来命令成功也只说明本地材料能构链。第三步区分 CAfile、CApath 与服务端 fullchain如果团队使用目录信任库CApath里的证书文件名必须按主题哈希建立链接不能把“目录里有一个 pem 文件”当作已加载。先用显式-CAfile排除目录索引问题再决定是否执行openssl rehash。不要直接把业务证书放进全局系统信任目录来“修好”验证。# 先用显式 CAfile 做基线 openssl verify -CAfile root.pem \ -untrusted intermediate.pem leaf.pem # 独立目录测试 CApath 的索引 mkdir -p ca-path cp root.pem ca-path/root.pem openssl rehash ca-path openssl verify -CApath ca-path \ -untrusted intermediate.pem leaf.pem对 Nginx 来说证书文件应按“叶子在前、中间在后”拼接根证书由客户端信任库提供。server { listen 443 ssl; server_name app.example.test; ssl_certificate /etc/nginx/tls/fullchain.pem; ssl_certificate_key /etc/nginx/tls/leaf.key; } # fullchain.pem 的顺序leaf.pem然后 intermediate.pem第四步从 HTTPS 实际发出的链反查本地文件通过而浏览器仍报错通常要看网络端点实际发出的证书。使用测试域名或明确的回环地址不要对生产站点反复 reload。-servername用来固定 SNI-showcerts用来观察服务端发送的证书集合两者都不能把“服务端发了链”变成“客户端一定信任这条链”。# 仅对测试端点读取服务端证书集合 openssl s_client -connect 127.0.0.1:8443 \ -servername app.example.test -showcerts如果输出只有叶子证书优先修复 fullchain链完整仍失败时检查 CAfile、CApath、容器信任库和代理层。不要把缓存和信任问题混成重新申请证书。故障对照表看到哪一层就修哪一层现象更可能的层先做什么error 20 at 0 depth本地缺 issuer 或未提供 untrusted核对 issuer/subject补正确中间证书本地 OK线上仍 error 20服务端未发送 fullchain或终点不同用 SNI showcerts 读取实际端点CApath 失败CAfile 成功目录哈希索引或权限独立目录执行 rehash 后复测证书能读Nginx -t 失败顺序、权限、密钥或链接库差异先看完整错误不把它归为 error 20链完整仍不受信任客户端根库、代理或策略确认实际 CAfile/容器信任库与终点验收清单把“能读”变成“可交付”记录 CLI 的openssl version本机实测为 1.1.1k FIPS。单独读取叶子、中间和根的 subject、issuer、SAN、有效期。用根 CAfile 中间 untrusted 做正例并保留 error 20 负例原文。按需验证 CApath 哈希不把系统信任目录当临时修复点。检查 fullchain 顺序叶子在前中间在后不把根硬塞进发送链。用固定 SNI 从测试端点读取实际证书集合避免只看本地文件。记录 Nginx 构建库与 CLI 版本差异本机分别为 1.1.1w 与 1.1.1k。确认没有把 CRL、EKU、私钥配对或域名 SAN 的错误误写成 error 20。官方依据与边界依据 OpenSSL verify 文档-CAfile、-CApath与-untrusted分别承担信任库、目录库与构链材料角色Nginx 文档要求主证书在前、中间证书随后。本文未把 1.1.1k 退出码推广到 OpenSSL 3.x也未声称验证生产环境。