启用OCSP装订需同时满足五项前提并配置四条指令：Nginx≥1.3.7、OpenSSL≥1.0.1、可直连OCSP服务器、时间误差≤±5分钟、证书链完整；且必须在server块中启用ssl_stapling on、ssl_stapling_verify on、ssl_trusted_certificate及resolver。
直接开启 ssl_stapling on 并不能把证书校验从客户端卸载——必须让 Nginx 主动获取、验证并缓存 OCSP 响应，再在 TLS 握手时“装订”发出，客户端才无需自己查吊销状态。这本质是把原本由浏览器发起的 OCSP 查询，提前转移到服务端完成。
确认服务端具备完整执行能力
OCSP 装订不是转发动作，而是服务端独立完成的一整套操作。以下五项缺一不可：
- Nginx ≥ 1.3.7（生产环境建议 ≥ 1.11.0），旧版对错误响应处理不稳定，容易静默失败
- OpenSSL ≥ 1.0.1（推荐 1.1.1+），需支持 SHA-2 签名验证
- 服务器能直连证书中 Authority Information Access 扩展指定的 OCSP 地址，可用
openssl ocsp -url [URL] -cert your.crt -CAfile fullchain.pem -text验证是否返回responseStatus: successful - 系统时间误差 ≤ ±5 分钟，否则 OCSP 响应中
ThisUpdate/NextUpdate校验失败 - 证书链完整：Nginx 的
ssl_certificate必须是域名证书 + 中间证书合并的 PEM 文件（如 Let’s Encrypt 的fullchain.pem）
四项配置必须同时生效
只写 ssl_stapling on 是无效的。以下四条指令必须全部出现在 HTTPS 的 server 块内，路径和参数准确无误：
-
ssl_stapling on;—— 启用机制，让 Nginx 主动发起 OCSP 请求 -
ssl_stapling_verify on;—— 强制校验响应签名、颁发者和有效期，防止伪造或缓存污染 -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 这不是你的站点证书，而是专用于验签的完整信任链（中间 CA 在前、根 CA 在后） -
resolver 8.8.8.8 1.1.1.1 223.5.5.5 valid=300s;—— 显式指定 DNS，Nginx 不读/etc/resolv.conf；valid=300s防止 DNS 缓存过期导致 stapling 中断
建议追加 resolver_timeout 5s;，避免 DNS 查询卡住整个 TLS 握手。
验证是否真正卸载成功
配置重载后，不能只看 Nginx 启动日志。实测命令如下：
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -status -tlsextdebug &1 | grep -i "OCSP response"
若输出含 OCSP Response Status: successful (0x0)，说明服务端已成功获取、验证并装订响应，客户端不再发起 OCSP 查询；若显示 no response sent 或无任何 OCSP 输出，则仍由客户端自行校验，卸载未生效。
多层代理场景下的正确分工
若使用 Nginx → Nginx → 应用 的链路，OCSP 校验只能由最前端 Nginx 完成：
- 前端 Nginx：启用
ssl_stapling on和ssl_stapling_verify on，配齐ssl_trusted_certificate与resolver，确保能访问 OCSP URL - 中间 Nginx：禁用所有 stapling 相关指令，仅透传 TLS 握手中的
certificate_status扩展，不重验、不重取 - 应用服务器：完全不参与 OCSP 流程，收到的是已解密的 HTTP 请求
在该结构下，证书吊销校验逻辑彻底从客户端事件流中移除，也从后端业务流程中剥离，真正实现“卸载”。
