必须执行openssl s_client检查证书段数和验证码，若仅1段或返回21/20码即链断裂；再用SSL Labs确认“Incomplete”；常见原因为中间缺失、根不在信任库或OCSP异常；自建反代可临时降级校验，Cloudflare Workers需用cf.tlsVerify: false或前置代理；须部署定时探测告警。
直接看 OCSP 响应和证书链完整性，别等用户报错——Worker（如 Cloudflare Workers、Service Worker 或自建 Nginx+Lua 反代）在反代外部 HTTPS 时，若上游用的是不合规证书链，握手失败往往静默表现为 502 Bad Gateway、SSL handshake failed 或超时，而非明确错误提示。
第一步：确认失败是否真出在证书链（而非网络或协议）
在 Worker 所在环境（或同网络出口的跳板机）执行：
-
openssl s_client -connect api.thirdparty.com:443 -servername api.thirdparty.com -showcerts 2>/dev/null | grep "BEGIN CERT"—— 看返回几段证书。只有一段？大概率链缺失。 -
openssl s_client -connect api.thirdparty.com:443 -servername api.thirdparty.com 2>&1 | grep "Verify return code"—— 若返回21 (unable to verify the first certificate)或20 (unable to get local issuer certificate)，就是链断裂的铁证。 - 用 SSL Labs Test 输入第三方域名，重点看 “Certificate Chain” 栏是否标红写 Incomplete 或 Extra download required。
第二步：定位不合规点——三类高频问题
第三方证书链不合规，常见于以下三种情况，每种都有对应验证方式：
-
中间证书缺失（最常见）：上游只发了终端证书，没附中间 CA。Worker（尤其基于 Chromium 的 runtime）严格校验链，拒绝拼接。验证命令：
openssl x509 -in cert.pem -noout -text | grep "CA Issuers"，看 AIA 扩展里的 OCSP/issuer URL 是否可访问；再用curl -v https://<em>issuer-url</em>确认中间证书能否下载。 -
根证书不在信任库（尤其私有 CA 或国内新 CA）：比如对方用 CFCA 子级签发，但 Worker 运行环境（如 Cloudflare）未预置该根；或用了已弃用的 Let’s Encrypt DST Root X3（2024 年后失效）。验证方法：把第三方完整证书链保存为
chain.pem，运行openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt chain.pem，若报unable to get issuer certificate，说明系统信任库缺其根或中间。 -
OCSP 响应器不可达或签名无效：Worker 启用 OCSP stapling（如 Nginx 配了
ssl_stapling on）时，若上游未提供有效 stapled OCSP，或响应过期/签名错，会直接拒连。抓包看 TLS handshake 中是否有Certificate Status握手消息（Wireshark 过滤ssl.handshake.type == 22），再检查其内容是否为good状态。
第三步：绕过 or 修复？生产中务实选择
第三方通常无法快速改配，所以需分场景应对：
- 若 Worker 是自建（如 Nginx + Lua）：可临时禁用链强校验（仅限紧急兜底），例如 Nginx 中设
ssl_verify_depth 1、关掉ssl_stapling_verify on，但必须同步加日志告警，且限期推动上游修复。 - 若用 Cloudflare Workers：无法控制底层 TLS 校验，只能换方案——改用
fetch()的cf.tlsVerify: false（仅限 Enterprise），或前置一层可信代理（如自建反代服务，由它完成链补全+OCSP 缓存后再透传给 Worker）。 - 长期解法：要求第三方提供完整 PEM 链（终端 + 所有中间，不含根），并用
openssl ocsp -issuer intermediate.crt -cert api.crt -url <ocsp_url> -CAfile full-chain.pem -text</ocsp_url>验证响应有效性，写入 SLA 协议。
第四步：加一层主动探测，防故障扩散
别等第一个请求失败才报警。在生产中部署轻量健康检查：
- 每 5 分钟用 cron 调
openssl s_client检查第三方证书链状态，匹配关键词Verify return code: 0 (ok)；不匹配则触发企业微信/钉钉告警。 - 在 Worker 入口加
try/catch捕获TypeError: fetch failed，记录原始 error.stack 和 response.url，聚合分析是否集中于某几个第三方域名。 - 对关键第三方，保留一份“合规快照”：导出其当前可用证书链 + OCSP 响应缓存，用于故障复现比对。
