1、证书吊销基础：什么是证书吊销、CRL与OCSP的区别、吊销场景分析
各位好，我是老赵。做PKI/CA这一行十几年了，今天咱们聊聊证书吊销。
很多人觉得证书签发出去就完事了，其实不是。证书的生命周期里，吊销才是真正考验功底的地方。我见过不少项目，证书签发流程跑得挺顺，一到吊销就手忙脚乱。嗯，今天咱们就把这块基础打扎实。
1.1 什么是证书吊销
说白了，证书吊销就是在证书到期之前，强制宣布它作废。
你想想看，证书是用来证明身份的。如果私钥泄露了、员工离职了、设备被黑了，那这张证书就不能再信了。这时候就需要CA把它拉进黑名单——这就是吊销。
核心要点：吊销不是删除，而是标记。证书本身还在，但CA会告诉所有人：“这张证书从现在起，别信了。”
吊销和过期是两码事。过期是自然失效，吊销是人为干预。我在项目中遇到过客户把这两个概念搞混，结果该吊销的证书没吊销，过期证书倒被当成吊销处理了……那场面，挺尴尬的。
1.2 CRL与OCSP的区别
CA怎么告诉别人证书被吊销了？主要有两种方式：CRL 和 OCSP。
先看个对比表格，一目了然：
| 对比项 | CRL（证书吊销列表） | OCSP（在线证书状态协议） |
|---|---|---|
| 工作方式 | CA定期发布一个黑名单文件 | 实时查询单张证书状态 |
| 实时性 | 依赖更新周期，有延迟 | 实时响应，延迟低 |
| 网络开销 | 一次下载，本地缓存 | 每次验证都要发起请求 |
| 隐私性 | 不暴露查询目标 | CA知道你在查谁的证书 |
| 适用场景 | 离线环境、批量验证 | 在线交易、高频验证 |
我个人习惯是：批量设备场景下，优先用CRL。为什么？你想想看，几千台设备同时上线，每台都去OCSP查一遍，CA服务器扛得住吗？我见过一个项目，OCSP响应器直接被查挂了，那叫一个惨。
但OCSP也有它的优势。实时性好啊，适合金融交易这种场景。CRL有个更新周期，比如24小时发一次，那这24小时里被吊销的证书就处于“盲区”。
我的建议：如果条件允许，可以两者结合。用CRL做批量兜底，用OCSP做关键交易的单点验证。这叫“双保险”。
1.3 吊销场景分析
哪些情况需要吊销证书？我按实际项目经验，分了四类：
场景一：私钥泄露
这是最常见的。私钥一旦泄露，证书就等于废纸。我曾经处理过一个案例，某厂商的固件签名私钥被拖库，当天就得吊销所有关联证书，涉及上万台设备。那晚基本没睡。
场景二：人员或设备变更
员工离职、设备报废、域名变更……这些情况证书都得吊销。别想着“反正快过期了，等等吧”。我见过有人这么干，结果离职员工用旧证书搞了波操作，追责的时候才发现证书没吊销。
场景三：证书信息变更
比如证书里的CN、SAN信息需要修改。有些CA支持重签发，但旧证书必须吊销。这里有个坑：重签发前一定要先吊销旧证书，否则会出现两张有效证书同时存在的情况。
场景四：合规与审计要求
金融、政务、医疗等行业，监管要求很严。证书到期前如果不再使用，必须主动吊销。我做过一个银行的项目，审计发现一批已停用的证书没吊销，直接被开了整改单。
下面这张图，把吊销的核心逻辑串起来了：
注意：吊销不是撤销。有些文档把“revoke”翻译成“撤销”，但严格来说，吊销是CA主动行为，撤销可能是用户申请。咱们做工程，术语要准确。
好了，这一章的基础就这些。记住三个关键词：吊销是什么、CRL和OCSP怎么选、什么场景要吊销。后面咱们会深入讲批量吊销的实操，这些基础不牢，后面容易翻车。