应手动配置 ssl_stapling_file 加载预生成 DER 格式 OCSP 响应文件，以解决离线或内网环境中 HTTPS 握手因 OCSP 查询超时导致的延迟问题；需满足版本、证书扩展、时间同步、证书链及信任链等前提，并通过 openssl 生成、验证及定期更新响应文件。
在负载均衡环境中，HTTPS 握手延时常源于客户端主动查询 OCSP 服务——尤其当后端服务器位于内网、私有 CA 环境或完全离线时，该查询会超时或失败，拖慢 TLS 握手达 200ms 以上。此时不能依赖自动 stapling，而应通过 ssl_stapling_file 手动加载预生成的 OCSP 响应文件，让 Nginx（或 Tengine）在无网络条件下仍能提供可信、可验证的吊销状态。
前提条件：确保基础环境就绪
该方案不是“开个开关就能用”，需先满足以下硬性要求：
- Nginx 或 Tengine 版本 ≥ 1.3.7（生产建议 ≥ 1.11.0），OpenSSL ≥ 1.0.1；
- 证书中必须包含 authorityInfoAccess 扩展（即 OCSP URL），否则无法生成合法响应；
- 系统时间误差 ≤ 5 分钟，否则 OCSP 响应中的
nextUpdate时间校验将失败； - 证书链完整：Nginx 的
ssl_certificate必须是域名证书 + 中间证书合并的 PEM 文件（如 Let’s Encrypt 的fullchain.pem）； - 已准备好用于签名验证的可信根链文件（
ssl_trusted_certificate），含签发 OCSP 响应器的中间 CA 和根 CA（顺序：中间在前，根在后）。
生成并准备 DER 格式 OCSP 响应文件
此步骤需在**临时有网环境**（如开发机、跳板机）中完成一次，结果可复用于离线集群：
- 用
openssl ocsp向证书中 AIA 扩展指定的 OCSP 地址发起请求，例如：openssl ocsp -url http://ocsp.int-x3.letsencrypt.org -cert example.com.crt -CAfile fullchain.pem -respout ocsp.der - 确认返回
responseStatus: successful，且输出为二进制 DER 格式（不可用 PEM）； - 检查响应有效期：
openssl ocsp -respin ocsp.der -text | grep -A2 "Next Update"，确保nextUpdate在合理范围内（通常 3–7 天）； - 将生成的
ocsp.der文件分发至所有负载均衡节点的统一路径，如/etc/nginx/ssl/example.com.ocsp。
Nginx/Tengine 配置要点（关键四行）
在 server 块或 http 块中添加以下指令，缺一不可：
-
ssl_stapling on;—— 启用 stapling 机制（即使离线也需开启）； -
ssl_stapling_verify on;—— 强制校验本地 OCSP 响应的签名、时间有效性及签发者可信度； -
ssl_stapling_file /etc/nginx/ssl/example.com.ocsp;—— 明确指向 DER 文件路径； -
ssl_trusted_certificate /etc/nginx/ssl/full-trusted-chain.pem;—— 指向专用于验证 OCSP 响应签名的信任链（非 ssl_certificate）。
注意：resolver 和 ssl_stapling_responder 在此模式下可省略，因不走网络查询；但若同时支持在线/离线双模式，可保留 resolver 并配合健康探测逻辑。
验证与维护要点
配置生效后，务必实测验证，而非仅依赖日志：
- 终端执行：
openssl s_client -connect yourdomain.com:443 -status -tls1_2 2>&1 | grep -A1 "OCSP response"，应看到OCSP Response Status: successful (0x0)； - 抓包观察 TLS ServerHello 扩展中是否携带
status_request及有效 OCSP 数据； - 定期更新
ssl_stapling_file：响应过期后 Nginx 不会自动重取，需在nextUpdate到期前重新生成并替换文件（可用定时任务+curl+openssl 自动化）； - 私有 CA 场景下，需自行部署 OCSP 响应器并导出其签发的 DER 响应，流程相同，仅 URL 和信任链不同。
