nginx证书链问题主因是中间证书缺失或过期，须将域名证书与有效中间证书严格按序拼入fullchain.pem供ssl_certificate指向，不可依赖ssl_trusted_certificate；验证需用openssl s_client检查输出是否含至少两段证书，安卓用户需清hsts缓存。
证书链配置出问题，往往不是域名证书过期，而是中间证书（Intermediate CA）失效或缺失。Nginx 本身不校验中间证书有效期，但客户端（尤其是 Android、旧版 iOS 和部分企业内网环境）会严格验证整条信任链。一旦中间证书过期或被 CA 撤回，即使你的域名证书还有效，用户仍会看到“NET::ERR_CERT_AUTHORITY_INVALID”等错误——这和单纯域名证书过期表现不同，也更难排查。
确认是否是中间证书导致的问题
不要凭感觉判断。用以下命令直接提取并检查你当前 ssl_certificate 文件中包含的所有证书（包括中间证书）：
- 运行：
openssl crl2pkcs7 -nocrl -certfile /etc/nginx/ssl/fullchain.pem | openssl pkcs7 -print_certs -noout - 观察输出中每段证书的 Not After 时间，特别关注第二段（通常是中间证书）是否已过期
- 对比权威链：访问 crt.sh，查你域名当前有效证书的完整链，看实际签发用的是哪一级中间 CA
清理过期中间证书的正确做法
中间证书不能“单独删除”，必须用完整、新鲜的信任链替代。常见错误是把 cert.pem + privkey.pem 直接当 fullchain.pem 用，漏掉中间层。
- 从证书颁发机构重新下载标准 Nginx 包（如 Let’s Encrypt 的
fullchain.pem、阿里云控制台的“Nginx 版证书压缩包”），确保它含：域名证书 → 中间证书 → 根证书（根证书通常可省略，但中间证书必须存在且有效） - 用
openssl x509 -in fullchain.pem -noout -text | grep "Issuer\|Subject"确认顺序：第一段 Subject 是你的域名，Issuer 是中间 CA；第二段 Subject 应与第一段 Issuer 一致，Issuer 是根 CA - 严禁手动编辑或拼接 PEM 文件——换行、空行、多余空格都会导致 Nginx 加载失败或客户端解析异常
更新后必须验证的三个关键点
只改文件、reload 不够。中间证书问题常在 reload 后“看似正常”，实则部分设备已无法握手。
-
服务端验证：执行
curl -I --insecure https://yoursite.com看是否返回 200；再用openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates确认返回的是新链中的首张证书 - 客户端兼容性验证：用真实 Android 10–12 设备、iOS 15–16 Safari 打开，或使用 SSL Labs 测试页，重点看 “Chain issues” 是否为 “None”
-
权限与路径一致性：确保
fullchain.pem权限为 644，且 Nginx 配置中ssl_certificate指向它（不是cert.pem），ssl_certificate_key单独指向私钥
长效预防：避免重复踩坑
中间证书过期比域名证书更隐蔽，因为很多 CA（如 Sectigo、DigiCert）会在证书生命周期中途更换中间 CA，而旧链不会自动失效，只是新签发的证书默认用新链。
- 每次续费或重签证书，都应重新下载完整 Nginx 包，不要复用旧
fullchain.pem - 若用 Certbot，确保启用
--force-renewal或定期certbot renew --dry-run，它会自动拉取最新中间证书 - 在自动化脚本中加入链完整性检查：比如用
openssl verify -untrusted fullchain.pem cert.pem，返回 OK 才允许 reload
