ssl_trusted_certificate不向浏览器发送证书链，仅供Nginx验证OCSP响应或客户端证书；修复HTTPS报错需确保ssl_certificate指向拼接了域名证书和中间证书的fullchain.pem文件。
不能通过 ssl_trusted_certificate 手动修复因中间证书缺失导致的 HTTPS 报错。
它根本不是用来发给浏览器的
ssl_trusted_certificate 文件只供 Nginx 自身使用，比如验证 OCSP 响应签名、或校验客户端证书（mTLS 场景）。它不会出现在 TLS 握手时发送给浏览器的证书列表里。所以无论你把中间证书放得多全、多正确，只要 ssl_certificate 指向的文件里没包含中间证书，浏览器就收不到，也就无法构建完整信任链。
真正起作用的是 ssl_certificate 文件内容
要让 Chrome、安卓、微信 WebView 等正常信任你的站点，必须确保：
- ssl_certificate 指向的 PEM 文件是拼接好的：先写你的域名证书（如 example.com.crt），紧接着换行后写中间证书（如 intermediate.crt）
- 顺序不能错——从服务器证书开始，逐级向上，到最靠近根的那个中间 CA 为止
- 不要把根证书（Root CA）加进去，浏览器自带根库，加了反而可能引发兼容问题
- 合并命令示例：cat example.com.crt intermediate.crt > /etc/nginx/ssl/fullchain.crt
- Nginx 配置中必须明确使用这个合并后的文件：ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_trusted_certificate 的合理用法
虽然它不解决“证书链不完整”警告，但在以下两个场景建议配置：
- 启用 OCSP stapling 时：ssl_stapling on; ssl_stapling_verify on;，此时需要 ssl_trusted_certificate 提供中间+根证书来验证 OCSP 响应是否真实有效
- 开启双向 TLS（mTLS）时，Nginx 用它来校验客户端证书是否由你认可的 CA 签发
验证是否修好了
别只看浏览器缓存或宝塔提示，直接在服务器上执行：
openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts 2>/dev/null | grep "subject="
输出中应看到至少两行 subject：一行是你自己的域名，另一行是中间 CA 的名称（例如 “CN=Let’s Encrypt R3” 或 “CN=GlobalSign RSA OV SSL CA 2022”）。只有这样，才说明客户端能收到完整链。
