每个人都可以，
拥有SSL证书

APNIC在2026年4月那份分析，基本给传统证书吊销机制下了结论：CRL太慢，OCSP没人查。

Chrome占了全球浏览器市场65%左右，但从2012年起就不再执行OCSP实时吊销检查，只靠随浏览器更新分发的CRLSet顶一下。CRLSet实际是一个紧急吊销子集，体积小，只放最严重事件。它跟完整CRL和OCSP都不在一个量级，普通私钥泄露、错误签发根本轮不到。

多数TLS连接在握手时没有实时确认证书是否已被吊销。

吊销检查为什么失效

CRL可以理解成小区门口贴的失信名单。

每次有人进门都得把名单翻一遍。CA把已吊销证书序列号全列进去，文件动辄几十MB，逐连接检索耗时太长。更麻烦的是列表本身可能滞后实际吊销事件长达9天。9天里，泄露的私钥签出来的证书照样能用。

OCSP做的是单证书状态查询，客户端拿序列号问CA一句这证书还有效吗。

响应速度和隐私都是问题，每次查询等于告诉CA你在访问哪个站点。配Nginx开了 ssl_stapling on，用 openssl s_client -status 一测，经常回一句 OCSP response: no response sent，OCSP响应器超时或不可达。Chrome当年关掉实时OCSP检查，性能隐私考量占大头。全球最大浏览器不查，其他浏览器查了也未必把结果当硬阻断。

OCSP Stapling这类修补方案让服务器提前取好OCSP响应，握手时一并下发，省去客户端直连CA的耗时和隐私问题。但它依赖服务器配置和CA响应稳定性，实际启用率一直上不去。Must-Staple证书要求客户端强制验证装订，一旦OCSP响应缺失就直接失败，也因CA和浏览器支持不一致没成为默认。

APNIC给出的判断很直接：缩短证书有效期才是行业最现实的修复路径。TLS证书最长有效期已经压到200天，2027年计划100天，2029年47天。

Let's Encrypt从2026年1月起已经提供6天超短有效期证书。证书自然过期速度快过事件响应速度，吊销是否实时就不再那么要命。

短证书周期下的自动化续期

证书持有者要面对的是续期频率翻几倍。一个业务线可能有十几个域名，加上泛域名、内部IP证书，到期时间散布全年。再靠人工下载CSR、做DNS验证、替换Nginx配置、reload，基本是给自己排雷。

凌晨收到过期告警再手工补，业务中断窗口往往已经发生。

ACME协议把申请、验证、续期标准化了，Let's Encrypt、Google Trust Services、ZeroSSL这些CA都支持。运维要做的就是把申请和部署串起来，让证书临期自动更换。

lcjmSSL这类平台在这块比较有代表性，支持多域名、泛域名、IP证书，自动申请、验证、部署，给一组简洁API，不需要在ACME客户端和各家CA接口之间来回适配。把续期任务挂进crontab或CI，证书到期前自动换，部署后触发reload，人工介入点只剩故障排查。

证书吊销机制走到今天，已经不能单独指望CRL或OCSP来兜底。短有效期加自动化续期，是把风险从发现后吊销挪到过期前自动替换。

这个变化对证书持有者是负担，但把它纳入安全模型之后，反而比维护一套没人查的吊销检查实际得多。