Nginx报ssl_stapling ignored：新证书没有OCSP URL怎么处理

Nginx 启动或 reload 时出现 ssl_stapling ignored, no OCSP responder URL in the certificate，并不等于证书坏了。它只说明当前证书没有 OCSP 响应地址，Nginx 无处获取可装订的状态响应。对 2026 年新签发的 Let’s Encrypt 证书，这通常是正常现象。

先看结论：warning 不等于 HTTPS 失效

OCSP Stapling 是服务器在 TLS 握手时，把 CA 签名的证书状态响应一并交给客户端。前提是证书的 AIA 扩展里存在 OCSP URI，而且 CA 的 responder 仍提供服务。缺少 URI 时，Nginx 会忽略 stapling，但证书链、域名匹配和 TLS 握手仍可能完全正常。

别看到 warning 就反复重签。先确认 CA 和证书类型，再决定删除无效配置，还是补齐 OCSP 条件。

为什么新 Let’s Encrypt 证书没有 OCSP URL

Let’s Encrypt 在 2025 年 5 月 7 日停止向新证书写入 OCSP URL，并于 8 月 6 日关闭 OCSP 服务，之后通过 CRL 发布吊销信息。当前 Profiles 文档也明确写着“不支持 OCSP”。因此，2026 年的新证书出现这条 Nginx warning 正是预期结果。

这不是 Nginx 过旧，也不代表 fullchain.pem 损坏。通常应移除 ssl_stapling 与 ssl_stapling_verify，不要编造 responder 地址。时间线见 OCSP 服务终止公告，当前机制见 Profiles 文档。

第一步：直接检查证书里有没有 OCSP 和 CRL

先读线上实际部署的叶证书，不要只看 ACME 客户端目录里的某个同名文件。下面两条命令分别检查 AIA 的 OCSP URI 和 CRL Distribution Points：

openssl x509 -in /etc/nginx/ssl/example.com/fullchain.pem \\
-noout -ocsp_uri

openssl x509 -in /etc/nginx/ssl/example.com/fullchain.pem \\
-noout -text | grep -A4 'CRL Distribution Points'

第一条没有输出、第二条能看到 CRL 地址，符合 Let’s Encrypt 目前的证书形态。若第一条返回真实 OCSP URL，说明该 CA 仍可能支持 stapling，可以继续检查签发链、信任链和网络解析。

第二步：确认 warning 来自哪个 server 块

一台 Nginx 常挂着多个站点。日志只给证书路径时，很容易改错配置。先展开全部有效配置，再定位证书路径和 stapling 指令：

nginx -T 2>&1 | grep -nE \\
'server_name|ssl_certificate|ssl_stapling|ssl_trusted_certificate'

journalctl -u nginx –since '30 minutes ago' –no-pager

nginx -T 展示合并后的有效配置，比只翻一个 conf 可靠。宝塔、容器和发行版包常用 include 拆分配置。

两种处理方式：按 CA 能力分流

对新 Let’s Encrypt 证书，最小配置可以保持清爽：

ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

# 当前证书没有 OCSP URI 时不要开启
# ssl_stapling on;
# ssl_stapling_verify on;

其他 CA 仍支持 OCSP 时怎么配

证书确实含 OCSP URI 时，可按 Nginx SSL 模块文档配置。验证 OCSP 响应的签发链放进 ssl_trusted_certificate；responder 是域名时还要配置可用的 resolver：

ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;
ssl_trusted_certificate /etc/nginx/ssl/example.com/issuer-chain.pem;

resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
ssl_stapling on;
ssl_stapling_verify on;

DNS 地址应换成环境中可信且可达的 resolver。ssl_trusted_certificate 应提供验证响应所需的 CA 证书链。

第三步：用线上握手验证，不靠配置想象

改完先检查语法，再读取线上实际握手。-status 会请求服务器返回 stapled OCSP response；-servername 用于明确 SNI，避免测到默认站点：

nginx -t && systemctl reload nginx

openssl s_client -connect example.com:443 \\
-servername example.com -status </dev/null

curl -Iv https://example.com/

CA 支持且配置成功时，输出会出现 OCSP Response Status: successful。新 Let’s Encrypt 证书没有 OCSP URI，看到 OCSP response: no response sent 不代表 HTTPS 故障；继续检查证书链、域名和到期时间即可。

别把 CRL 当成 Nginx stapling 的替代开关

CA 转向 CRL，不等于把 ssl_stapling 改成 ssl_crl。Nginx 的 ssl_crl 主要用于 mTLS 客户端证书校验，不是给公网服务器证书做“CRL Stapling”。普通 HTTPS 站点应先保证证书链和自动续期可靠，再按 CA 能力决定是否使用 OCSP Stapling。

最终验收清单

• openssl x509 -ocsp_uri 已确认当前叶证书是否包含 OCSP URI。
• 已根据 CA 官方说明确认 OCSP 服务是否仍可用，没有手填来路不明的 responder。
• nginx -T 已定位到真正生效的 server 块和证书路径。
• 无 OCSP URI 的证书已移除无效 stapling 指令；有 URI 的证书已配置可信签发链和 resolver。
• nginx -t 通过后才 reload，没有拿生产配置练胆量。
• openssl s_client -servername … -status 与 curl -Iv 均验证了线上实际结果。
• 证书域名、有效期和完整链路正常，不能用一个 warning 代替全部 TLS 验收。

先读证书，再读 CA 当前规则，最后验证线上握手。Nginx 的 warning 并不等于网站坏了。