nginx / 宝塔里的 ssl_stapling 还要不要开？

只有证书里还带 OCSP 地址时才有用，先用 openssl x509 -in cert.pem -noout -ocsp_uri 查看。2025 年 5 月 7 日之后签发的 Let's Encrypt 证书没有 OCSP 地址，开了 stapling 也取不到响应，只会在日志里多一条警告；如果证书仍带 OCSP 地址，开着没有坏处。

OCSP 退场以后，吊销还有用吗？

有用。CA 必须发布 CRL，Chrome 把其中一部分做成 CRLSets，Firefox 把 CT 日志里所有吊销做成 CRLite；同时证书有效期越来越短，被吊销证书能被滥用的时间窗口也在缩小。7 天以内的短期证书甚至不需要吊销信息。

怎么自己查一张证书有没有被吊销？

从证书的 CRL Distribution Points 扩展拿到 CRL 地址，下载后查找证书序列号，或者直接用 openssl verify -crl_check；证书若还有 OCSP 地址，也可以用 openssl ocsp 查询。完整命令见 OCSP 与 CRL 命令手册。

国内的 360、QQ 浏览器会检查吊销吗？

这些浏览器大多基于 Chromium 内核，通常沿用 Chromium 的做法：不在握手时在线查 OCSP/CRL，而是依赖内置或下发的吊销数据。具体策略各厂商不同，也可能随版本变化，重要场景不要假设客户端一定会发现吊销。

OCSP 与 CRL：证书吊销检查原理与 2026 年现状

证书吊销用来告诉客户端：这张证书还没过期，但已经不能再信任。CA 有两种发布方式：CRL 是一份签名的吊销序列号清单，OCSP 是按单张证书实时查询的状态服务。截至 2026 年 11 月，公网 PKI 已经全面转向 CRL：OCSP 对 CA 变成可选，Let's Encrypt 在 2025 年 8 月关掉了响应器，浏览器改用本地缓存的数据判断吊销。

为什么需要吊销

证书可能在到期前很久就变得不可信，这就是吊销存在的原因。常见情况有：私钥泄露、域名换了主人、证书签发有误、CA 发现自己的验证流程有漏洞。按照 Baseline Requirements，最严重的情形（例如确认私钥泄露）CA 要在 24 小时内吊销，其余大多数情形是 5 天。

真正的难点在于“让客户端知道”。浏览器要在几十亿张证书里，及时而且不泄露隐私地得知某一张已经作废。CRL 和 OCSP 是两种答案，各有代价。

CRL 的工作方式

CRL（证书吊销列表）是 CA 签名的一个文件，里面列出被吊销证书的序列号。格式定义在 RFC 5280 第 5 节，证书通过 CRL Distribution Points（CRL 分发点）扩展告诉客户端去哪里下载。

字段	含义
Issuer	签发这份清单的 CA
This Update / Next Update	本次生成时间、下一次最晚更新时间
Revoked Certificates	序列号、吊销时间、可选的吊销原因
CRL Number	单调递增的序号
Issuing Distribution Point	标记分片 CRL 及其覆盖范围
签名	CA 对以上内容的签名

大 CA 早就不发布一个巨大的 CRL 了，而是把吊销记录拆成许多分片 CRL（partitioned / sharded CRL）。2026 年 11 月签发的一张 Let's Encrypt 证书指向其中一个分片：

X509v3 CRL Distribution Points:
    Full Name:
      URI:http://ye2.c.lencr.org/51.crl

用 OpenSSL 解开这个分片，能看到它的结构（有删节）：

Certificate Revocation List (CRL):
    Version 2 (0x1)
    Signature Algorithm: ecdsa-with-SHA384
    Issuer: C=US, O=Let's Encrypt, CN=YE2
    Last Update: Nov  9 17:52:09 2026 GMT
    Next Update: Nov 18 17:52:08 2026 GMT
    CRL extensions:
        X509v3 CRL Number:
            1794246729324766624
        X509v3 Issuing Distribution Point: critical
            Full Name:
              URI:http://ye2.c.lencr.org/51.crl
            Only User Certificates
Revoked Certificates:
    Serial Number: 05E7C117F64B64BC83F3691B78C8F454F1B2
        Revocation Date: Sep 24 17:49:02 2026 GMT

这个分片约 100 KB，有几千条记录。CRL 自带签名、可以缓存、能放在任何 CDN 上，但想完整覆盖就得下载很多份，所以浏览器不会在访问网站时临时去拉 CRL。

OCSP 的工作方式

OCSP（RFC 6960）把“下载清单”换成了“一问一答”。客户端向 CA 的响应器发一个请求，用签发者名称和公钥的哈希加上序列号来标识一张证书，响应器返回签名过的状态。

浏览器                              OCSP 响应器（CA）
   |  与 example.com 握手               |
   |  证书 AIA 里有 OCSP 地址           |
   |---- OCSP 请求（序列号 0x05E7…）---->|
   |<--- 签名响应：good / revoked / unknown，
   |     thisUpdate、nextUpdate --------|
   |  根据结果继续或中断连接            |

状态	含义
`good`	响应器认识这张证书，且未吊销
`revoked`	已吊销，附吊销时间和可选原因
`unknown`	响应器不认识这张证书

响应由 CA 本身或带 OCSP Signing EKU 的委托响应器证书签名。公网 CA 通常预先生成响应、通过明文 HTTP 由 CDN 分发，所以 RFC 里可选的 nonce 很少被使用。

OCSP 为什么被放弃

OCSP 在隐私、可靠性和性能上都有结构性问题，业界最终认定修不好。

隐私：每次查询都等于告诉 CA“这个 IP 正要访问哪个网站”，而且请求走明文 HTTP，链路上的任何人都看得到。Let's Encrypt 把这一点列为停用 OCSP 的首要原因。
软失败：响应器连不上时，浏览器一向选择放行，否则 CA 的每次故障都会变成网站故障。能劫持流量的攻击者通常也能顺手拦掉 OCSP 请求，所以软失败的检查恰恰在最需要时失效。
延迟：Mozilla 统计，OCSP 请求让 TLS 握手的中位数多阻塞约 100 毫秒。在国内访问境外 CA 的 OCSP 响应器，延迟和超时往往更明显，这也是过去国内运维普遍开启 Stapling 的原因。
成本：Let's Encrypt 高峰期每月要应答约 3400 亿次 OCSP 请求。

OCSP Stapling 与 Must-Staple

OCSP Stapling 把查询从浏览器挪到了服务器。客户端在握手中带上 RFC 6066 第 8 节定义的 status_request 扩展，服务器把自己事先取回的 OCSP 响应“钉”在握手里一起发出。TLS 1.2 里它是单独的 CertificateStatus 消息；TLS 1.3 里它放在 Certificate 消息中叶子证书条目的扩展里。

Stapling 解决了隐私和延迟，却解决不了软失败：服务器完全可以不钉。Must-Staple（RFC 7633 的 TLS Feature 扩展，OID 1.3.6.1.5.5.7.1.24）本想补上这个缺口，要求客户端在收不到钉附响应时拒绝证书。但实际情况是 Firefox 执行、Chrome 不执行，服务器在响应器故障时处理得很糟，带这个扩展的证书极少。Let's Encrypt 在 2025 年已不再接受 Must-Staple 申请。

# 只有证书里仍有 OCSP 地址时才有意义
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver 223.5.5.5 119.29.29.29 valid=300s;

SC-063：CRL 必须有，OCSP 可选

CA/Browser Forum 在 2023 年通过的 SC-063 投票，把两种机制的地位颠倒了过来：签发公开信任 TLS 证书的 CA 必须发布 CRL，OCSP 则成为可选项。

投票同时规定了 CRL 的更新频率：吊销一张证书后 24 小时内必须发布新 CRL；平时，如果证书里带 OCSP 地址，至少每 7 天更新一次，否则至少每 4 天一次。分片 CRL 明确允许，只要合起来能覆盖全部吊销证书。

SC-063 还定义了短期证书：有效期不超过 10 天的证书（2026 年 3 月 15 日起签发的收紧到 7 天）可以不带 CRL 或 OCSP 地址，也不要求吊销，靠到期自然失效。Let's Encrypt 的 shortlived 配置签发 160 小时的证书，正好落在这个范围内。

Let's Encrypt 在 2025 年停掉 OCSP

全球签发量最大的 Let's Encrypt 在 2025 年 8 月完成了向“只用 CRL”的切换。它 2022 年起就支持 CRL，2024 年 12 月 5 日公布了时间表：

日期	变化
2025-01-30	新的 Must-Staple 申请失败（以前用过 Must-Staple 的账户除外）
2025-05-07	证书已带 CRL 地址；去掉 OCSP 地址；所有 Must-Staple 申请失败
2025-08-06	关闭 OCSP 响应器

到关停那天，所有带 OCSP 地址的证书都已过期，因此没有在用证书受影响。Let's Encrypt 特别提醒：浏览器和网站不受影响，但一些非浏览器软件，比如配置成必须查 OCSP 的 VPN 客户端或企业中间件，可能需要调整。国内不少政企内网设备、老版本 Java 应用开启了严格吊销检查，换成 Let's Encrypt 证书前值得先测一遍。

更多相关变化见 Let's Encrypt 时间线。

浏览器现在怎么查吊销

现代浏览器提前把吊销数据推送到本地，而不是在握手时去问 CA。两种主流方案的覆盖范围差别很大：

客户端	机制	覆盖范围
Chrome / Edge	CRLSets：从 CA 的 CRL 中挑选，经组件更新下发	紧急和重点吊销；按 Mozilla 的对比约占全部吊销的 1%
Firefox 桌面版	CRLite：把 CT 日志中所有被吊销证书压缩编码，每 12 小时更新	CT 日志中证书的全部吊销
Firefox 对 DV 证书	自 Firefox 142 起停用 OCSP	由 CRLite 覆盖

Chromium 官方文档写明 Chrome 一般不做在线 OCSP/CRL 检查，企业策略可以重新打开在线 OCSP。Mozilla 从 Firefox 137 起为所有桌面用户启用 CRLite，平均每天下载约 300 KB 吊销数据。CRLite 依赖证书透明度：只有能在 CT 日志里找到的证书才会被收录。

浏览器之外的 TLS 实现各有各的规则。Windows CryptoAPI、Java 以及大量嵌入式客户端都有自己的吊销设置，有些企业产品可以配置成硬失败。如果你在维护这类软件，请用一张不带 OCSP 地址的证书测试一下。

运维需要做什么

大多数网站什么都不用改，但有几处配置值得检查。先确认证书里到底有哪些吊销指针：

openssl x509 -in cert.pem -noout -ocsp_uri
openssl x509 -in cert.pem -noout -ext crlDistributionPoints,authorityInfoAccess

Let's Encrypt 证书的 Stapling：-ocsp_uri 没有输出，就说明 ssl_stapling 无事可做。宝塔等面板的默认模板常常打开它，留着无害，去掉可以少一条日志警告。
Must-Staple：从 ACME 客户端配置里删掉 --must-staple 之类的选项，否则 Let's Encrypt 会拒绝订单。
内部客户端：对 OCSP 有硬性要求的应用（开启 OCSP 的 Java、严格检查吊销的 VPN 网关）要能接受只有 CRL 的证书。
私有 PKI：自建 CA 仍然可以运行 OCSP，但无论如何都应发布 CRL，参见私有 CA 命令手册。
私钥泄露：先通过 CA 或 ACME 客户端吊销，再立即换证。不要只依赖吊销，部分客户端可能要好几天才会察觉。

检查线上服务器可以用 openssl s_client -status，看输出里有没有 OCSP response。浏览器里的吊销报错见 NET::ERR_CERT_REVOKED。

吊销的未来

吊销问题的长期答案是缩短证书寿命。根据 SC-081v3 投票，公开信任 TLS 证书的最长有效期从 2026 年 3 月 15 日起是 200 天，2029 年 3 月 15 日起降到 47 天，详见 47 天证书。47 天证书的私钥一旦泄露，攻击者能利用的时间是几周而不是一年；6 天证书则根本不需要吊销。

CRL 仍是权威来源，浏览器把它们压缩成 CRLSets 和 CRLite，OCSP 主要留在私有 PKI 和选择继续提供它的 CA 那里。想亲手查看这些数据，可以照着 OCSP 与 CRL 命令手册一步步来。