ssl_trusted_certificate指令用于指定Nginx验证客户端证书时所依赖的可信CA证书链文件，仅含根证书及中间证书（PEM格式），不包含私钥或服务器证书，专用于双向TLS中精准控制信任锚。
ssl_trusted_certificate 指令不是用来“信任”某个证书的开关，而是明确告诉 Nginx：当验证客户端证书（比如在双向 TLS 场景中）时，只允许使用你指定的这份证书文件里所包含的根证书和中间证书来完成信任链校验。
它解决的核心问题：精准控制信任锚
企业内网常部署私有 CA，例如自建的 “Industrial Root CA” 或 “Manufacturing CA”。如果直接把整个系统信任库（如 /etc/ssl/certs/ca-certificates.crt）丢给 Nginx，就等于让服务器无差别信任所有已知公共 CA —— 这会削弱安全边界，也违背零信任原则。ssl_trusted_certificate 的作用，就是划出一条清晰的信任红线：只认我认可的那几级 CA，其余一概不验。
这个文件必须是 PEM 格式，且只含证书（不能含私钥），内容通常是：
- 企业根 CA 证书（最顶层）
- 可选的中间 CA 证书（按从上到下的顺序排列）
注意：它不包含服务器自己的证书，也不参与服务器向客户端出示的身份证明，只用于反向验证客户端身份。
典型配置场景：双向认证中的设备准入控制
在工业上位机与 PLC、MES 系统通信时，要求终端设备（如现场工控机、移动巡检终端）必须持有由企业 CA 签发的客户端证书。此时需在 Nginx 或反向代理层启用 client certificate verification，并用 ssl_trusted_certificate 锁定信任源。
- 启用客户端证书验证：
ssl_verify_client on; - 指定可信 CA 集合：
ssl_trusted_certificate /etc/nginx/ssl/internal-ca-chain.pem; - 设置验证深度（防止过长链攻击）：
ssl_verify_depth 2;（通常根 + 中间 = 2 层）
这样，当一台未授权设备尝试用公网 CA 签发的证书连接时，Nginx 会在握手阶段直接拒绝，日志中显示 SSL_do_handshake() failed 或 unable to get local issuer certificate，而不是放行后由应用层再做判断。
如何生成和维护 trusted_certificate 文件
该文件不是自动生成的，需要人工构建并定期更新：
- 从企业根 CA 导出根证书（.crt 或 .pem），确保其为 Base64 编码、以
-----BEGIN CERTIFICATE-----开头 - 若使用了中间 CA，将其证书追加在根证书之后（顺序不能颠倒）
- 避免混入服务器证书或私钥；可用
openssl x509 -in file.pem -text -noout检查内容是否仅为证书 - 更新后需重载 Nginx：
nginx -s reload，无需重启
建议将此文件纳入配置管理工具（如 Ansible、SaltStack），与 CA 证书生命周期同步更新，尤其在根证书轮换时及时替换。
审计视角：它是信任链可视化的关键落点
在安全审计中，ssl_trusted_certificate 是验证企业是否真正实现“信任可控”的第一道检查项。审计人员会核对：
- 该文件是否存在，路径是否在配置中被正确引用
- 文件内容是否真实对应企业内部 CA 的根与中间证书（比对指纹或 Subject）
- 是否与客户端证书签发体系一致（例如：PLC 使用的客户端证书确由该文件中列出的 CA 签发）
- 是否有定期更新机制，避免因根证书过期导致全链失效
它把抽象的“信任链”具象为一个可读、可审、可版本控制的文件，让信任不再依赖浏览器预置或运维记忆，而是成为基础设施代码的一部分。
