ssl_stapling_verify on仅验证本地OCSP响应签名、完整性和有效期，不保障公网传输安全；需配合ssl_trusted_certificate（含正确顺序的中间+根证书）、resolver（带valid缓存）及ssl_stapling on四指令共存于server块方可生效。
ssl_stapling_verify on 并不负责保障 OCSP 响应在“公网传输过程中的完整性”，它只做一件事：在 Nginx 本地对已获取的 OCSP 响应进行签名验证，确认该响应确实由可信 CA（或其授权的 OCSP 响应器）签发、未被篡改、且在有效期内。传输层的安全（如 DNS 是否被污染、HTTP 连接是否被劫持）它不管，那是 resolver、防火墙和网络策略的事。
必须配 ssl_trusted_certificate，且内容要完整准确
Nginx 不读系统信任库，也不从 ssl_certificate 文件里自动提取根或中间证书。它只认你明确指定的 PEM 文件，而且这个文件必须严格满足以下条件：
- 包含签发你域名证书的中间 CA 证书（必须）
- 紧接着是该中间 CA 的上级根证书（必须）
- 顺序不能错：中间证书在前，根证书在后
- 不能只放根证书，也不能把服务器证书混进去
推荐生成方式：cat intermediate.crt root.crt > /etc/nginx/ssl/full-chain-trusted.pem。验证是否可用：openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.int-x3.letsencrypt.org -CAfile /etc/nginx/ssl/full-chain-trusted.pem -text，输出含 Response verify OK 才算通过。
OCSP 响应源必须真实可达且返回合规响应
Nginx 在 reload 或首次握手时会主动访问证书 AIA 扩展中声明的 OCSP URL。如果这个环节失败，ssl_stapling_verify on 就会让整个 HTTPS 握手中断（502 或 handshake failed）。关键检查点包括：
- 用 curl -v http://ocsp.int-x3.letsencrypt.org 确认能返回 HTTP 200（注意：多数 CA 用 HTTP，不是 HTTPS）
- 某些 OCSP 服务对 TLS 版本、HTTP/1.1 支持或 User-Agent 有隐式要求，Nginx 默认行为可能不兼容
- 响应必须是 RFC 6960 兼容的 DER 编码格式，不能是 HTML 错误页或空响应
resolver 必须显式配置并带缓存策略
OCSP URL 是域名，Nginx 需要 DNS 解析才能发起请求。它不读 /etc/resolv.conf，必须手动写 resolver 指令：
- 写法示例：resolver 1.1.1.1 8.8.8.8 valid=300s;
- valid=300s 很关键——没有它，DNS 缓存可能过期导致后续 stapling 失败
- 建议加 resolver_timeout 5s;，避免 DNS 卡住 TLS 握手
- 内网或高安全场景可部署本地可信 DNS，规避公共 DNS 被污染风险
四项指令必须同时启用且位置正确
单独打开 ssl_stapling_verify on 不仅无效，还会让服务更脆弱。这四个指令必须共存于同一个 server 块中，缺一不可：
- ssl_stapling on; —— 启用 stapling 机制本身
- ssl_stapling_verify on; —— 开启签名与有效期校验
- ssl_trusted_certificate /path/to/full-chain-trusted.pem; —— 提供验证所需的完整信任链
- resolver 1.1.1.1 8.8.8.8 valid=300s; —— 保障 OCSP 查询路径畅通
配置完成后，用 openssl s_client -connect example.com:443 -status 观察输出中是否出现 OCSP Response Status: successful (0x0) 且无 verify error，再结合 Nginx error.log 中无 stapling 相关报错，即可确认生效。
