要让 ssl_stapling_verify on 真正增强 OCSP 装订安全性，必须同时配置 ssl_stapling on、ssl_trusted_certificate（含顺序正确的中间+根证书）、resolver（带 valid 缓存时间）及可达合规的 OCSP 响应源，缺一不可，否则 TLS 握手将失败。
要让 ssl_stapling_verify on 真正增强 OCSP 装订安全性，不能只加这一行。它本质是“强校验开关”，一旦启用，Nginx 就会拒绝任何未通过签名、有效期、签发者链三重验证的 OCSP 响应——但前提是整个验证链必须完整可靠，否则 TLS 握手直接失败。
必须同时配齐四项核心指令
单独开启 ssl_stapling_verify on 不仅无效，还会导致 502 或 handshake failed。以下四条必须共存于 server 块中，且位置合理（通常放在 ssl_certificate 之后）：
-
ssl_stapling on;—— 启用 OCSP Stapling 机制本身，不开启则无响应可验证 -
ssl_stapling_verify on;—— 强制本地校验 OCSP 响应的签名与时间有效性 -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 指向专用于验签的信任链文件（非ssl_certificate） -
resolver 1.1.1.1 8.8.8.8 valid=300s;—— 显式配置 DNS 解析器并设定缓存时间，Nginx 不读系统 resolv.conf
正确生成并验证 ssl\_trusted\_certificate 文件
这个文件不是证书链副本，而是 OCSP 响应验签专用的“信任锚”。常见错误是复用 fullchain.pem（含终端证书）或只放根证书。它必须满足：
- 仅包含中间 CA 证书 + 根证书（不含域名证书）
- 顺序严格：中间证书在前，根证书在后
- 推荐生成方式：
cat intermediate.crt root.crt > full-chain-trusted.pem - 验证命令：
openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.int-x3.letsencrypt.org -CAfile full-chain-trusted.pem -text，输出含 Response verify OK 才算通过
确保 OCSP 响应源可达且响应合规
Nginx 在 reload 或首次握手时会主动访问证书 AIA 扩展中的 OCSP URL。若该环节失败，ssl_stapling_verify on 会立即中断连接：
- 用
openssl x509 -in example.com.crt -noout -text | grep -A1 "OCSP"查看内嵌地址 - 手动测试连通性：
curl -v https://ocsp.int-x3.letsencrypt.org或openssl s_client -connect ocsp.int-x3.letsencrypt.org:443 -servername ocsp.int-x3.letsencrypt.org - 注意部分 CA 要求 HTTP/1.1、特定 TLS 版本或 Host 头，Nginx 默认行为可能不兼容
- 服务器时间偏差超过 ±5 分钟会导致 OCSP 响应被拒绝，需用
ntpd或chrony同步
快速验证是否生效
配置完成后，用客户端工具确认 stapled 响应已实际返回：
- 命令：
openssl s_client -connect example.com:443 -status -servername example.com &1 | grep -i "OCSP response" - 成功时输出类似：OCSP Response Status: successful (0x0)，且含 Response verify OK
- 若报错或无输出，优先查 Nginx error log，搜索关键词：
ocsp: response verification failed、SSL_do_handshake() failed或no issuer cert matches OCSP responder
