必须开启ssl_stapling_verify on以强制Nginx校验OCSP响应的签名、有效期及签发者链，否则拒绝使用；但需同时配置ssl_stapling on、ssl_trusted_certificate（含正确顺序的中间+根证书）、resolver（带valid缓存时间）四项，缺一则导致502或SSL握手失败。
ssl_stapling_verify on 本身不“解决”校验失败，而是强制执行校验——当它启用后，Nginx 会拒绝使用任何未通过签名、时效、签发者链三重验证的 OCSP 响应。在反向代理 HTTPS 场景中，这恰恰是提升链路可信度的关键开关，但必须配合四项硬性配置，否则反而引发 502 Bad Gateway 或 SSL handshake failed。
必须补全的证书信任链（ssl_trusted_certificate）
反代服务器不直接持有终端证书私钥，但它仍需独立验证上游返回的 OCSP 响应是否由可信 CA 签发。Nginx 完全不读系统 CA 存储，也不从 ssl_certificate 自动提取中间/根证书。
-
ssl_trusted_certificate必须是一个 PEM 文件，按顺序包含：- 上游服务器证书所对应的中间 CA 证书
- 该中间 CA 的根证书（不可省略）
- ❌ 错误做法：复用
fullchain.pem（含终端证书）、只放根证书、顺序颠倒（根在前、中间在后） - ✅ 验证命令（提前测试）：
openssl ocsp -issuer intermediate.crt -cert upstream.crt -url http://ocsp.ca.com -CAfile trusted-chain.pem -text
若返回
Response verify OK，说明链可用。
确保上游 OCSP 响应器可达且响应合规
反代场景下，Nginx 是 OCSP 查询发起方，不是客户端。它依赖上游证书 AIA 扩展中的 OCSP URL，而非自身证书。
- 查看上游证书的 OCSP 地址：
openssl x509 -in upstream.crt -noout -text | grep -A1 "OCSP"
- 手动验证连通性（注意：OCSP 使用 HTTP POST + DER 编码体，但可用 HEAD 初筛）：
curl -I -k https://ocsp.digicert.com # 检查 DNS、TLS 握手、HTTP 状态
- 常见阻断点：
- 反代服务器所在网络禁止出向 80/443 到公网 OCSP 域名（如被防火墙拦截）
- 某些 CA（如 Sectigo）要求 TLS 1.2+ 且 User-Agent 合法，Nginx 默认 UA 可能被拒
- OCSP 响应器返回非
200 OK或非 RFC 6960 格式 DER 响应（Nginx 不解析 ASN.1 错误，直接拒收）
resolver 必须带缓存策略，且 DNS 可信
OCSP URL 是域名，Nginx 需解析其 IP。若仅写 resolver 8.8.8.8，默认 valid=5s 极易因 DNS TTL 或抖动导致解析失败，进而使 stapling 初始化中断。
- 正确写法（显式设
valid）：resolver 1.1.1.1 8.8.8.8 valid=300s;
- 更稳妥做法：部署本地可信 DNS（如 CoreDNS），避免公共 DNS 被污染或劫持，导致解析到恶意 OCSP 响应器。
四项指令必须共存，缺一不可
ssl_stapling_verify on 是“校验开关”，但无 stapling 行为则无响应可验。以下四行必须同时出现在 server 块中：
ssl_stapling on; # 启用装订机制 ssl_stapling_verify on; # 启用响应签名与时效校验 ssl_trusted_certificate /path/to/trusted-chain.pem; # 提供完整验证链 resolver 1.1.1.1 8.8.8.8 valid=300s; # 提供稳定 DNS 解析
- 若任意一项缺失，Nginx 启动时可能报：
ssl_stapling ignored, issuer certificate not foundOCSP response error: ...- TLS 握手阶段直接失败，日志中出现
SSL_do_handshake() failed
不复杂但容易忽略
