Let's Encrypt新签发证书包含CRL地址了，不过解决不了证书吊销问题

Let's Encrypt 新签发证书包含 CRL 地址，但受客户端行为和机制限制，无法彻底解决证书吊销问题。具体分析如下：

一、Let's Encrypt 的 CRL 部署进展

时间节点：自 2025 年 3 月 12 日起，新申请的证书将包含 CRL 地址；2025 年 5 月 7 日起，停止在证书中包含 OCSP URL。这一调整标志着其吊销机制从 OCSP 向 CRL 的迁移。
技术实现：每张证书将嵌入一个指向 CRL 的链接（如示例中的
http://e5.c.lencr.org/123.crl
），客户端可通过该链接获取吊销证书列表。用户可通过脚本验证证书是否在 CRL 中，流程包括：
获取证书：openssl s_client -connect community.letsencrypt.org:443 -servername example.com 2>/dev/null </dev/null | openssl x509 -out certificate.crt
提取 CRL 地址：CRL_URL=$(openssl x509 -in certificate.crt -noout -text | grep -oP 'URI:K[^ ]+' | head -1)
对比序列号：curl -s "$CRL_URL" | openssl crl -inform DER -noout -text | grep -A 1 "$SERIAL"

二、CRL 的局限性分析

客户端依赖性问题：
浏览器差异：Chrome 等主流浏览器不严格依赖 CA 提供的 CRL，而是采用内置的 CRLSet（仅包含高风险或大规模吊销的证书），而非完整 CRL。用户可通过 chrome://components/ 检查 CRLSet 更新状态。
实验性配置取消：Chrome 曾支持强制启用 CRL 校验的实验性选项，但现已移除，进一步削弱了 CRL 的实际作用。
操作系统存储导入：用户可通过 Windows 的 certmgr.msc 或 mmc 命令将 CRL 导入系统不受信任存储，但操作复杂，普及率极低。
CRL 机制本身的缺陷：
实时性不足：CRL 文件较大，客户端通常缓存一段时间（如数小时至数天），导致吊销信息更新延迟。Let's Encrypt 曾推出 6 天短期证书，通过缩短有效期和自动化更新缓解此问题。
无标准解决方案：OCSP 和 CRL 均未被广泛严格实施，证书吊销机制的有效性长期依赖客户端行为，而非 CA 单方面控制。

三、证书吊销问题的根源

客户端自主性：证书吊销的生效与否最终由客户端决定。例如：
Chrome 的 CRLSet 仅覆盖部分高风险证书，普通吊销可能被忽略。
移动端或嵌入式设备可能完全禁用 CRL/OCSP 校验以节省资源。
历史机制失败：OCSP 因隐私和性能问题被弃用，CRL 因实时性和规模问题效果有限，两者均未成为通用标准。

四、当前环境下的建议

短期证书策略：Let's Encrypt 用户可继续使用短期证书（如 90 天有效期），通过自动化工具（如 Certbot）定期更新，降低吊销风险窗口。
客户端兼容性测试：若需严格吊销校验，需针对目标客户端（如特定浏览器或操作系统）测试 CRL 支持情况，但普适性较低。
关注新兴技术：如 OCSP Stapling 或 CT 日志（Certificate Transparency）可作为补充，但同样依赖客户端实施。

总结：Let's Encrypt 引入 CRL 地址是技术上的进步，但受客户端行为分散、机制缺陷和历史问题影响，无法彻底解决证书吊销问题。证书吊销的有效性仍需行业在客户端标准、性能优化和用户教育上进一步突破。

热门标签