X.509 证书撤销机制为何失败

核心问题

X.509 证书是互联网安全的基础（TLS），但证书撤销机制基本失效。

信任不是永恒的：

私钥泄露
证书错误签发
服务停止
CA 被攻破

问题： 客户端如何知道证书已被撤销？

方案一：CRL（证书撤销列表）

机制：

CA 定期发布已撤销证书的序列号列表
客户端下载 CRL，检查序列号

问题：

问题	说明
延迟大	CRL 更新间隔可能长达 9 天（Let's Encrypt 示例）
体积大	大量撤销 → CRL 巨大
低效	只查一个证书，却要下载整个列表
未被使用	没人愿意承担这个延迟

方案二：OCSP（在线证书状态协议）

机制：

客户端向 CA 发送证书序列号
CA 返回该证书的状态（good/revoked/unknown）

OCSP 记分卡：

指标	评价
速度	✅ 比 CRL 快
额外延迟	❌ 仍有请求/响应延迟
可用性	❌ CA 服务器必须高可用
失败模式	❌ 无响应时 soft-fail = 白信任
隐私	❌ CA 知道谁在何时访问哪个网站

浏览器实测：

浏览器	OCSP 支持
Chrome	❌ 不支持（自 2012）
Safari	✅ 支持
Firefox	✅ 支持

Let's Encrypt 数据： 2025 年初，每月 3400 亿次 OCSP 请求（平均 14 万/秒）

方案三：Stapled OCSP

机制：

服务器在 TLS 握手中附带 OCSP 响应
客户端无需查询 CA

优势：

✅ 无额外延迟
✅ CA 不知道客户端身份
✅ 减少 CA 负载

问题：

CA 不响应时，服务器无法获取 OCSP 响应 → hard fail
如果证书已撤销，为什么服务器还要传给客户端？

浏览器实测：

浏览器	Stapled OCSP 支持
Chrome	❌ 不支持
Safari	✅ 支持
Firefox	✅ 支持

Chrome 的做法：CRLsets

Google 爬虫收集各 CA 的 CRL
过滤掉"不重要"的撤销
推送到 Chrome 客户端

问题：

作者测试：Chrome 的撤销列表只有 1,081 条
Let's Encrypt 一个 CA 就有 1,062 条
Chrome 市场份额 80% → 它的做法 = 互联网实际标准

根本矛盾

时间窗口问题：

攻击者几分钟内完成入侵 + 数据窃取
CRL/OCSP 延迟 = 数天到数周
"几纳秒的世界，证书撤销提供的是同一周的服务"

Adam Langley (Google) 的观点：

证书有效期应该只有几天，然后根本不需要撤销。如果 CA 宕机 6 小时，无所谓；只有宕机几天才有问题。想"撤销"证书？停止续签就行。

行业方向：缩短证书有效期

Let's Encrypt 2026 年 5 月变更：

证书有效期：90 天 → 45 天
按 CA/Browser Forum 要求执行

作者质疑：

攻击几分钟完成，45 天 vs 90 天有什么区别？
7 天 vs 45 天可能也差不多

替代方案：DANE + DNSSEC

DNS 模式：

公钥存储在 DNS（DANE, RFC 6698）
DNSSEC 提供真实性
DNS TTL 控制缓存时间（小时/天级别）

优势：

TTL = 小时级别，远短于证书有效期（月/年）
隐私更好（DNS 有递归解析器中间层）
无需单独的撤销机制

TLS 集成：

服务器提供公钥 + DNSSEC 签名 + 验证链
客户端无需查询 DNS

实测：撤销后 48 小时

作者测试：

为 revoked.potaroo.net 申请 Let's Encrypt 证书
立即撤销
确认 CRL 中存在该序列号
等待 48 小时

结果：

浏览器	结果
Firefox 148.0.2	❌ 未检测到撤销
Chrome 147.0.7727.117	❌ 未检测到撤销
Safari 25.4	❌ 未检测到撤销

结论：撤销失败。

核心结论

方案	状态
CRL	低效、延迟大、未被使用
OCSP	隐私泄露、Chrome 不支持、soft-fail 失效
Stapled OCSP	覆盖率低、逻辑矛盾
CRLsets	Chrome 仅覆盖极少数"重要"撤销
缩短有效期	方向正确，但 45 天仍太长

根本问题：

现有 PKI 架构无法提供实时或接近实时的撤销状态
攻击者几分钟内完成入侵，证书系统响应时间是数天
互联网安全基础依赖于一个滞后几代的安全框架

可能的出路：

大幅缩短证书有效期（天级别）
或采用 DANE + DNSSEC 模式，利用 DNS TTL 实现快速更新