ssl_stapling_verify on 是防止 OCSP Stapling 被绕过的关键防线，需配合 ssl_stapling on、ssl_trusted_certificate 指向含中间+根证书的 PEM 文件、显式配置 resolver，四者缺一不可。
开启 ssl_stapling_verify on 不是为了“锦上添花”，而是防止 OCSP Stapling 被绕过或滥用的关键防线。它强制 Nginx 在将 OCSP 响应发给客户端前，先验证该响应是否由可信 CA 签发、是否在有效期内、签名是否完整——若任一校验失败，Nginx 会直接拒绝 TLS 握手，而非返回无效或伪造的响应。
必须配合 ssl_trusted_certificate 指向完整信任链
Nginx 不读取系统证书库，也不从服务器证书中自动提取中间或根 CA。它只认你明确指定的 PEM 文件，且该文件必须包含：签发 OCSP 响应器的中间证书 + 根证书（顺序不能错）。仅放根证书、或误用 ssl_certificate 文件（通常不含根证书），都会导致验证失败并触发 502 或 handshake failed。
- 推荐合并方式：
cat intermediate.crt root.crt > full-chain-trusted.pem - 验证是否可用：
openssl ocsp -issuer intermediate.crt -cert example.com.crt -url <ocsp_url> -CAfile full-chain-trusted.pem -text，成功返回response is good才算有效
依赖 resolver 和 OCSP 响应器可达性
ssl_stapling_verify on 启动后，Nginx 会在 reload 或首次握手时主动访问证书 AIA 扩展中声明的 OCSP URL。如果 DNS 解析失败、目标地址不通、返回非 200 响应、或服务要求特定 HTTP 头/TLS 版本而 Nginx 默认不满足，验证即中断，连接被拒。
- resolver 必须显式配置，例如：
resolver 8.8.8.8 1.1.1.1 valid=300s; - 建议加
resolver_timeout 5s;防止 DNS 卡住握手 - 用
curl -v https://ocsp.your-ca.com或openssl s_client -connect ocsp.your-ca.com:443 -servername ocsp.your-ca.com提前确认连通性与 TLS 兼容性
四项配置缺一不可，否则形同未启用
单独打开 ssl_stapling_verify 不但无效，反而会让 HTTPS 服务变得脆弱——它会把所有 stapling 相关环节变成“强依赖”。以下四条必须同时存在且正确：
-
ssl_stapling on;—— 启用 stapling 机制本身 -
ssl_stapling_verify on;—— 开启响应签名与有效期校验 -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 提供可验证 OCSP 签名的完整 CA 链 -
resolver x.x.x.x ... valid=300s;—— 保障 OCSP 查询路径畅通
常见故障表现与快速定位方向
启用后出现握手失败，不要急于关掉 verify，先按顺序排查：
- 检查 Nginx error log，搜索
SSL_do_handshake() failed或ocsp: response verification failed - 确认
ssl_trusted_certificate文件是否存在、权限是否可读、内容是否为 PEM 格式且含全部必要证书 - 用
openssl x509 -in your-cert.crt -text -noout | grep -A 2 "Authority Information Access"查出实际 OCSP 地址，再手动测试连通性与响应有效性 - 注意系统时间是否准确——OCSP 响应含
nextUpdate时间戳，偏差超过 5 分钟常被拒绝
