Nginx 中 ssl_stapling_verify 对证书验证完整性的作用

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

它不解决分布式节点间状态同步问题，但确保每个节点各自校验可靠——这是多实例部署下维持整体证书验证完整性的实际路径。