ssl_stapling_verify on 的核心作用是强制 Nginx 在 TLS 握手前本地校验 OCSP 响应的签名真实性、时间有效性（thisUpdate/nextUpdate ±5 分钟）及证书 ID 匹配性，必须与 ssl_stapling on、ssl_trusted_certificate（中间+根证书、顺序严格）和 resolver（带 valid 缓存）协同生效，缺一即导致握手失败。
ssl_stapling_verify on 的核心作用，是让 Nginx 在 TLS 握手前，对即将下发给客户端的 OCSP 响应做本地可信性校验，确保其签名真实、时间有效、证书匹配、状态合法。它不增强传输安全，也不替代系统信任库，而是堵住 OCSP Stapling 机制中“缓存即转发”的信任盲区，防止无效或伪造响应误导客户端。
验证什么：三项硬性检查
启用后，Nginx 在将 OCSP 响应写入共享缓存并用于握手前，强制执行： - 使用 ssl_trusted_certificate 中提供的中间 CA + 根证书，验证 OCSP 响应的数字签名是否由可信签发者生成 - 检查响应中的 thisUpdate 和 nextUpdate 时间戳是否落在当前系统时间 ±5 分钟窗口内（需 NTP 同步） - 确认响应中声明的证书 ID（包括序列号与公钥哈希）与当前服务器证书完全一致，且 status 字段为 good
为什么必须配 ssl_trusted_certificate
Nginx 不读取操作系统证书目录，也不从 ssl_certificate 自动提取根或中间证书。它只依赖你显式指定的 PEM 文件，且该文件必须满足： - 包含签发 OCSP 响应器的中间证书（如 Let’s Encrypt R3）及其上级根证书（如 ISRG Root X1） - 顺序严格：中间证书在前，根证书在后 - 不能复用 ssl_certificate 文件（通常不含根证书），也不能仅放根证书而遗漏中间层 - 推荐合并命令：cat intermediate.crt root.crt > full-chain-trusted.pem
失效时的表现与排查重点
一旦配置缺失或错误，Nginx 不会降级处理，而是直接中断 TLS 握手，常见现象包括： - 客户端报 SSL handshake failed 或 502 Bad Gateway - Nginx error log 中出现 “no issuer cert matches OCSP responder”、“OCSP response error” 或 “verify error” - openssl s_client -connect yourdomain.com:443 -status 返回 “Response Verify Failure”
优先排查方向： - 用 openssl ocsp -issuer intermediate.crt -cert example.com.crt -url <ocsp_url> -CAfile full-chain-trusted.pem -text 验证本地验签流程是否通过 - 检查 resolver 是否显式配置（如 resolver 1.1.1.1 8.8.8.8 valid=300s;），避免 DNS 解析卡住握手 - 确认 OCSP URL 可达：curl -v https://ocsp.int-x3.letsencrypt.org 应返回 200 及合法 DER 响应
不是独立开关，而是强依赖链的一环
ssl_stapling_verify on 必须与以下三项同时存在且正确，否则功能失效或服务异常： - ssl_stapling on：启用 OCSP Stapling 机制本身 - ssl_trusted_certificate：提供完整、顺序正确的信任链 PEM 文件 - resolver：保障 OCSP 域名可解析，建议加 valid=300s 和 resolver_timeout 5s
它不解决分布式节点间状态同步问题，但确保每个节点各自校验可靠——这是多实例部署下维持整体证书验证完整性的实际路径。
