ssl_trusted_certificate 专用于 nginx 验证客户端证书,仅在 ssl_verify_client on 时生效,加载 pem 格式可信 ca 证书(不含私钥或服务端证书),不参与服务器证书链发送;补全服务端链应使用 ssl_certificate fullchain.pem。

在 Nginx 中配置 `ssl_trusted_certificate` 并不是为了“启用 HTTPS”,而是专门用于**验证客户端证书(双向 TLS/MTLS)时,提供可信的 CA 证书链**。它和 `ssl_certificate`(服务端证书)用途完全不同,不能混用,也不能用来“补全服务器证书链”——那是 `ssl_certificate` 文件该做的事。
明确用途:ssl_trusted_certificate 是给谁用的?
这个指令只在启用客户端证书校验(即 `ssl_verify_client on`)时生效,Nginx 用它里面的 CA 证书来验证浏览器或客户端发来的证书是否由受信任的机构签发。
- 它不参与服务器 TLS 握手,不影响浏览器看到的证书链完整性
- 它必须是 PEM 格式,可包含一个或多个 CA 证书(根 + 中间),顺序无关(Nginx 会自动构建信任路径)
- 文件里不能包含私钥,也不能包含服务器证书(否则会报错或行为异常)
怎么正确补全服务器证书链(常见误解点)
如果你实际想解决的是“浏览器提示证书不完整”“NET::ERR_CERT_AUTHORITY_INVALID”,那问题出在服务端证书链没配全——这跟 `ssl_trusted_certificate` 无关,应操作:
Linux系统管理专家,覆盖12大模块:用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词:useradd、sudo、sshd_config、chmod、SEL...
- 把你的域名证书(
example.com.crt)和中间证书(如intermediate.crt)合并成一个文件,顺序为:域名证书在前,中间证书在后(根证书通常不用放) - 例如:
cat example.com.crt intermediate.crt > fullchain.pem - 然后在 Nginx 配置中使用:
ssl_certificate fullchain.pem(不是单个 crt) -
ssl_certificate_key仍指向你的私钥文件(.key)
真正需要 ssl_trusted_certificate 的场景与配置
仅当你强制要求客户端也提供有效证书(比如内网 API、管理后台)时才需设置。典型配置如下:
- 准备一个 PEM 文件(如
/etc/nginx/client-ca-bundle.pem),内容是签发客户端证书所用的 CA 根证书 + 中间证书(如有) - 确保该文件权限严格(如
600),且 Nginx 主进程可读 - 在 server 块中添加:
ssl_client_certificate /etc/nginx/client-ca-bundle.pem; ssl_verify_client on; ssl_verify_depth 2;
-
注意:这里用的是
ssl_client_certificate(旧名,兼容性好),而ssl_trusted_certificate是它的功能等效替代(Nginx ≥1.11.0),推荐新写法:ssl_trusted_certificate /etc/nginx/client-ca-bundle.pem; ssl_verify_client on;
验证与调试小技巧
配置完成后别急着 reload,先检查语法并确认证书链有效性:
-
nginx -t确保配置无语法错误 - 用 OpenSSL 模拟客户端握手验证服务端链:
openssl s_client -connect example.com:443 -showcerts,观察输出中是否包含全部预期证书 - 若开启 client cert 验证,可用带证书的 curl 测试:
curl --cert client.crt --key client.key https://example.com/api - Nginx 错误日志(
error_log)会明确记录证书验证失败原因,如 “SSL_do_handshake() failed… unable to get local issuer certificate”










