Nginx需fullchain.pem以提供完整信任链，因其包含域名证书和中间证书；若仅用cert.pem，客户端无法构建信任链，导致“证书不可信”错误。
证书链自动合并不是独立步骤，而是 ACME 客户端在部署阶段的默认行为——关键在于你用对了参数、选对了文件类型，并让 Nginx 加载的是 fullchain.pem 而非单独的 cert.pem。
为什么 Nginx 需要 fullchain.pem，而不是只放域名证书？
Nginx 的 ssl_certificate 指令实际加载的是“证书 + 中间证书”的组合体。如果只放域名证书（cert.pem），客户端（如 Chrome、iOS）可能因无法构建完整信任链而报“证书不可信”或“NET::ERR_CERT_AUTHORITY_INVALID”。Let’s Encrypt 的中间证书会随 CA 根证书轮换而更新，acme.sh 或 Certbot 在签发时已内置该逻辑，但必须通过正确路径交付给 Nginx。
acme.sh 自动合并并落盘 fullchain 的实操方式
acme.sh 默认生成三类文件：cert.pem（仅域名证书）、ca.pem（中间证书）、fullchain.pem（cert.pem + ca.pem 拼接）。你无需手动 cat 合并，只需在 --install-cert 中明确指定 --fullchain-file：
- ✅ 正确做法：使用
--fullchain-file /etc/nginx/ssl/example.com/fullchain.pem，Nginx 配置中写ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem; - ❌ 错误做法：用
--cert-file单独复制 cert.pem，再另起一行加ssl_trusted_certificate——该指令不参与 TLS 握手中的证书链发送，仅用于 OCSP Stapling 验证 - ⚠️ 注意：不要用
cat cert.pem ca.pem > fullchain.pem手动拼接 —— acme.sh 的 fullchain.pem 已按正确顺序包含根兼容性处理，手动拼接易出错且无法跟随 CA 更新
Certbot 场景下如何确保链完整？
Certbot 默认将证书存放在 /etc/letsencrypt/live/example.com/ 目录，其中 fullchain.pem 是硬链接或符号链接，指向最新续期生成的完整链文件。只要你在 Nginx 配置中始终引用这个路径：
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
每次 certbot renew 成功后，这些链接会自动指向新证书，Nginx reload 即可生效。无需任何额外合并动作。
验证证书链是否真正生效
部署后别只看浏览器小锁图标，用命令行确认链完整性：
-
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep "Issuer:"—— 应显示为 “Let’s Encrypt R*”，而非 “DST Root CA X3”（旧根已停用） -
curl -I https://example.com看响应头是否含Strict-Transport-Security，间接说明 TLS 握手成功完成 - 在线工具如 SSL Labs Test 可直观展示链路径、是否缺失中间证书、是否启用 OCSP Stapling
