开启 ssl_stapling_verify on 是让 nginx 本地严格验签 ocsp 响应，确认其由可信 ca 签发、未被篡改且时间有效；必须与 ssl_stapling on、ssl_trusted_certificate、resolver 四项共存于同一 server 块，缺一则 tls 握手失败。
开启 ssl_stapling_verify on 不是为了“传输防护”，而是让 Nginx 在发出 OCSP 响应前，本地完成一次严格验签——确认该响应确实由可信 CA 签发、未被篡改、且时间有效。它不加密、不代理、不干预网络层，但能直接堵住伪造 OCSP 响应导致的证书欺骗漏洞。
必须同时配置四项指令
单独写 ssl_stapling_verify on 会导致 TLS 握手失败（常见报错：502 或 SSL_do_handshake() failed）。以下四条必须共存于同一个 server 块中：
-
ssl_stapling on;—— 启用 OCSP 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;—— 显式声明 DNS 解析器及缓存时长，Nginx 不读系统配置
正确构造 ssl\_trusted\_certificate 文件
这个文件不是服务器证书链，也不复用 ssl_certificate；它是 Nginx 验证 OCSP 响应签名的唯一信任锚点：
- 必须包含签发你域名证书的中间 CA 证书（如 Let’s Encrypt R3）
- 紧接着追加该中间 CA 所属的根证书（如 ISRG Root X1）
- 顺序不能颠倒：中间证书在前，根证书在后
- 不能混入域名证书（
example.com.crt），也不能只放根证书 - 推荐生成方式：
cat intermediate.crt root.crt > /etc/nginx/ssl/full-chain-trusted.pem
验证 OCSP 响应源是否真实可用
Nginx 在 reload 或首次握手时会主动访问证书 AIA 扩展中声明的 OCSP URL。若不可达，ssl_stapling_verify on 会直接中断连接：
- 提前测试连通性：
curl -v http://ocsp.int-x3.letsencrypt.org（多数 CA 使用 HTTP） - 确保防火墙允许出站 HTTP 请求（非 HTTPS）
- 系统时间偏差不能超过 ±5 分钟，否则 OCSP 响应会被视为过期
- 部分 CA 对 TLS 版本或 SNI 有要求，可用
openssl s_client -connect ocsp.your-ca.com:443 -servername ocsp.your-ca.com检查兼容性
用 OpenSSL 提前验证配置有效性
无需重启 Nginx，即可确认整套逻辑是否就绪：
- 运行命令：
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 和 cert status: good
- 失败常见原因：
unable to get local issuer certificate（证书顺序错）、signature verification failed（中间证书缺失或损坏）
