Nginx要求商业CA证书链严格按“终端证书→中间证书→中间证书…”顺序拼接PEM文件，禁含根证书；顺序错位或混入根证书会导致安卓/iOS提示“证书不受信任”。
商业 CA（如 DigiCert、Sectigo、GlobalSign）签发的证书常含两级甚至三级中间证书，Nginx 要求这些中间证书必须严格按信任路径顺序拼入 ssl_certificate 指向的 PEM 文件，且不能包含根证书。顺序错位或混入根证书，会导致安卓、iOS 或部分浏览器提示“证书不受信任”。
核心拼接顺序规则
必须满足“终端 → 中间 → 中间 → …”的线性信任链顺序，每级的 Issuer 要与下一级的 Subject 匹配：
- 第一段：你的域名证书（
CN=your-domain.com），即 leaf cert - 第二段：离你最近的中间 CA（如
CN=Sectigo RSA Domain Validation Secure Server CA） - 第三段：再上一级中间 CA（如
CN=USERTrust RSA Certification Authority） - 最后一段不能是根证书（如
CN=AddTrust External CA Root或CN=ISRG Root X1）——浏览器已内置，加入反而可能引发兼容问题
典型商业CA证书包结构与处理方式
不同厂商打包习惯不同，需人工核对并重拼：
-
DigiCert：通常提供
your_domain.crt+DigiCertCA.crt（单级中间），直接cat your_domain.crt DigiCertCA.crt > bundle.pem -
Sectigo：常含三文件：
domain.crt、SectigoRSADomainValidationSecureServerCA.crt、USERTrustRSAAddTrustCA.crt；正确顺序为cat domain.crt SectigoRSADomainValidationSecureServerCA.crt USERTrustRSAAddTrustCA.crt > fullchain.pem -
GlobalSign：可能含
your_domain.crt、AlphaSSLCA-SHA256-G2.crt、GlobalSignRootCA-R3.crt；注意GlobalSignRootCA-R3.crt是根证书，不可加入，只取前两段
验证是否真正生效
别依赖浏览器图标或缓存，用 OpenSSL 实测服务器实际发送的内容：
- 运行：
openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts 2>/dev/null - 检查输出中
-----BEGIN CERTIFICATE-----块的数量和顺序：第一块 Subject 含你的域名，第二块 Issuer 应等于第一块 Subject，第三块 Issuer 应等于第二块 Subject，且最后一块不能是知名根 CA - 若只看到一块，说明链缺失；若中间证书在前、域名证书在后，就是顺序颠倒
常见踩坑点
这些操作看似微小，却高频导致链验证失败：
- 把 CA 提供的
ca-bundle.crt或root_ca.crt直接追加进 fullchain —— 根证书必须剔除 - 用文本编辑器手动复制粘贴时，意外插入空行或 Windows 换行符（
\r\n），破坏 PEM 结构 - 宝塔等面板“自动补全”功能对 Let’s Encrypt 有效，但对 Sectigo/DigiCert 多级链大概率失效，甚至覆盖原有内容
- 私钥文件误混入 PEM 链文件（
-----BEGIN RSA PRIVATE KEY-----出现在证书块里）—— Nginx 会静默加载失败
