3. 证书吊销机制概述：吊销场景分析、CRL与OCSP对比、吊销状态码详解

证书吊销，说白了就是给一张数字证书“判死刑”。

我经常跟团队里的新人讲：证书不是发出去就完事了。它可能被泄露、被滥用、或者干脆就不该再被信任。这时候，你就得有一套机制，告诉全世界——“这张证书废了”。

这套机制，就是证书吊销。今天咱们就把它掰开揉碎了讲清楚。

3.1 什么时候需要吊销证书？——吊销场景分析

很多人觉得证书吊销离自己很远。其实不然。我经历过好几次半夜被叫起来处理证书泄露的事故，那滋味可不好受。

常见的吊销场景，我归纳为以下五类：

• 私钥泄露：这是最要命的。私钥一旦暴露，攻击者就能冒充你的身份。我记得有一次，某客户的运维人员把私钥文件传到了公开的代码仓库……嗯，那晚我们全员加班。
• 证书信息变更：公司改名了、域名换了、组织重组了。原来的证书信息对不上号，必须吊销重发。
• 员工离职或设备退役：签发给离职员工的客户端证书，或者退役服务器的 TLS 证书，都应该及时吊销。我曾经见过一个离职员工的证书被用了半年才被发现，那叫一个后怕。
• CA 被入侵或误发：CA 自己出问题了，或者不小心发了一张不该发的证书。这时候，所有受影响的证书都得批量吊销。
• 合规与审计要求：某些行业标准（比如 PCI DSS）强制要求定期检查证书状态，不合规的必须吊销。

3.2 吊销状态怎么查？——CRL 与 OCSP 对比

证书吊销了，别人怎么知道？这就需要两种查询机制：CRL 和 OCSP。

我刚开始做 PKI 的时候，只用 CRL。后来发现它太笨重了，才慢慢转向 OCSP。咱们来对比一下。

对比维度	CRL（证书吊销列表）	OCSP（在线证书状态协议）
工作方式	CA 定期发布一个“黑名单”文件	实时查询单个证书的状态
实时性	差，取决于 CRL 的更新周期（可能几小时到几天）	好，实时响应
网络开销	客户端需要下载整个列表，文件可能很大	每次只查询一个证书，请求小
隐私性	好，客户端不暴露自己正在访问哪个站点	差，OCSP 服务器能知道你在查谁的证书
部署复杂度	低，CA 生成文件，客户端下载即可	高，需要部署 OCSP 响应器
典型应用	企业内部 PKI、离线环境	互联网 TLS、高频验证场景

3.3 吊销状态码详解

证书吊销不是只有“吊销”和“未吊销”两种状态。RFC 5280 定义了多种状态码。我整理了一份清单，你对照着看。

状态码	含义	说明
0	未指定（unspecified）	吊销原因未记录。能用别的就别用这个，审计时会很麻烦。
1	密钥泄露（keyCompromise）	私钥被泄露。这是最严重的情况，必须立即吊销。
2	CA 泄露（cACompromise）	CA 的私钥被泄露。这会导致整个 CA 下的证书都受影响。
3	附属关系变更（affiliationChanged）	证书主体所属的组织或部门发生变化。
4	证书被替代（superseded）	证书被新证书替代，旧证书正常退役。
5	操作终止（cessationOfOperation）	证书对应的服务或实体已停止运营。
6	证书暂停（certificateHold）	临时冻结证书，后续可以解除。注意，这不是永久吊销。
8	从 CRL 中移除（removeFromCRL）	用于 delta CRL，表示某证书从增量列表中移除。
9	特权撤销（privilegeWithdrawn）	证书持有者的权限被撤销，但证书本身可能没泄露。
10	AA 泄露（aACompromise）	属性机构的私钥被泄露，比较少见。

3.4 吊销机制的核心逻辑

说了这么多，咱们用一张图把吊销机制的整体逻辑串起来。你一看就明白了。

你看，整个流程其实很清晰：

1. 触发吊销：私钥泄露、信息变更、设备退役、合规要求等事件触发。
2. CA 处理：CA 收到吊销请求后，更新内部数据库，并生成吊销记录。
3. 发布状态：通过 CRL 或 OCSP 两种方式，把吊销状态告诉外界。
4. 客户端验证：客户端在验证证书时，会主动查询 CRL 或 OCSP，确认证书是否被吊销。

好了，证书吊销的机制就讲到这里。你想想看，理解了这些基础，后面咱们讲设备隔离和自动化吊销时，你就知道每一步是在干什么了。