ssl_stapling_verify on 是保障 OCSP 装订响应真实有效的核心校验机制，必须与 ssl_stapling on、ssl_trusted_certificate、resolver 四项配置同时启用且正确设置，缺一不可。
ssl_stapling_verify on 不是可选优化项，而是保障 OCSP 装订响应真实、有效、未被篡改的核心校验机制。它让 Nginx 在把 OCSP 响应发给客户端前，先完成三项关键验证：响应是否由可信 CA 签发、签名是否完整、有效期是否合法。任一失败，Nginx 就拒绝 TLS 握手，避免将无效或伪造的响应透传给用户。
必须配齐四要素，缺一不可
单独开启 ssl_stapling_verify 不仅无效，反而会放大故障面——它把整个 OCSP 验证链变成强依赖路径。以下四项配置需同时存在且正确：
- ssl_stapling on; —— 启用装订功能本身
- ssl_stapling_verify on; —— 开启响应签名与时间有效性校验
- ssl_trusted_certificate /path/to/full-chain-trusted.pem; —— 指向含中间证书 + 根证书的 PEM 文件（顺序不能错；不能复用 ssl_certificate）
- resolver x.x.x.x valid=300s; —— 显式声明 DNS 解析器，确保能访问 OCSP URL
信任链文件必须严格构造
Nginx 不读系统证书库，也不从服务器证书中自动提取中间或根证书。它只认你明确指定的 PEM 文件，且该文件必须包含：
- 签发 OCSP 响应器的中间证书（不是你的域名证书）
- 对应的根证书（通常为 CA 的根）
- 二者顺序为：中间证书在前，根证书在后
推荐合并方式：cat intermediate.crt root.crt > full-chain-trusted.pem。可用命令验证是否可用：openssl ocsp -issuer intermediate.crt -cert example.com.crt -url
验证失败时优先排查网络与连通性
启用 ssl_stapling_verify 后，Nginx 会在 reload 或首次握手时主动访问证书 AIA 扩展中声明的 OCSP URL。常见中断原因包括：
- DNS 解析失败（resolver 配置缺失或不可达）
- OCSP 服务器地址不通、超时或返回非 200 响应
- 目标服务要求特定 TLS 版本（如 TLS 1.2+）或 HTTP 头，而 Nginx 默认不满足
建议提前验证：curl -v https://ocsp.your-ca.com 或 openssl s_client -connect ocsp.your-ca.com:443 -servername ocsp.your-ca.com，确认 TLS 握手成功、HTTP 可达、无重定向或证书错误。
日志是定位问题的第一线索
若出现握手失败，不要急于关闭 verify，先查 Nginx error log。重点关注以下关键词：
- SSL_do_handshake() failed
- ocsp: response verification failed
- no resolver defined to resolve
- certificate verification failed
这些提示直接对应配置缺失、信任链错误、DNS 或 OCSP 连通性问题，按顺序逐项排除即可快速恢复。
