ssl_trusted_certificate用于Nginx验证客户端证书（mTLS），指定可信CA根/中间证书；而ssl_certificate用于向客户端发送服务端证书及完整证书链（不含根证书），二者用途、加载时机和内容要求均不同。
ssl_trusted_certificate 是干啥的，和 ssl_certificate 有啥区别
ssl_trusted_certificate 不是用来给客户端发证书的，而是告诉 Nginx “哪些 CA 根/中间证书是可信的”，主要用在需要验证客户端证书（mTLS）的场景。但很多人误把它当 ssl_certificate 的“补链工具”来用，结果配置了也没效果——因为 Nginx 发送服务端证书时，**只从 ssl_certificate 文件里读取并发送证书链**，完全不看 ssl_trusted_certificate。
所以如果你遇到浏览器报“证书链不完整”（比如 Chrome 显示 NET::ERR_CERT_AUTHORITY_INVALID），问题一定出在 ssl_certificate 文件内容不对，而不是没配 ssl_trusted_certificate。
修复证书链不完整的正确操作：合并证书到 ssl_certificate 文件
你需要把「域名证书」+「所有中间证书」按顺序拼成一个 PEM 文件，作为 ssl_certificate 的值。顺序必须是：域名证书在最上面，然后是直接签发它的中间 CA，再往上是更上一级中间 CA，根证书**不能放进去**（浏览器自带，加了反而可能触发兼容性问题）。
- 用
openssl x509 -in cert.pem -text -noout | grep "Issuer\|Subject"确认每张证书的 Issuer 和 Subject，判断层级关系 - 典型顺序示例：
your-domain.crt→AlphaSSL_G2.crt→DigiCert_CA.crt（不含 DigiCert Root） - 合并命令：
cat your-domain.crt AlphaSSL_G2.crt DigiCert_CA.crt > fullchain.pem - Nginx 配置中必须指向这个合并后的文件：
ssl_certificate /path/to/fullchain.pem
什么时候才真需要 ssl_trusted_certificate
只有开启双向 TLS（client certificate verification）时才用得上 ssl_trusted_certificate。比如你用 ssl_client_certificate + ssl_verify_client on 要求用户上传证书，那 Nginx 就得靠 ssl_trusted_certificate 里提供的根/中间证书去验证对方证书是否可信。
- 它必须是 PEM 格式，且只包含 CA 证书（不能含私钥，也不能含你的域名证书）
- 通常可复用系统 CA 包：
ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt - 如果自建 CA，就放你自己的根证书或根+中间证书（顺序不限，Nginx 会自己遍历）
- 注意：它和
ssl_certificate完全无关，配错或不配都不会导致“证书链不完整”告警
验证链是否真的完整
别只信浏览器刷新，用命令行快速确认：
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep "Issuer:"
看输出里有没有出现多段 Issuer（说明服务器返回了多张证书）；更可靠的是：
curl -Iv https://example.com 2>&1 | grep "SSL certificate verify ok"
如果提示 verify failed 或显示 only one certificate，说明链还是断的。另外，SSL Labs 测试页 会明确标出“Chain issues”和缺失的中间证书名，比本地调试更准。
最容易被忽略的一点：CDN 或反向代理（如 Cloudflare、AWS ALB）可能覆盖你 Nginx 的证书链发送逻辑——它们会用自己的链重签，此时修 Nginx 配置毫无意义，得去对应平台上传完整链。
