吊销前准备：获取设备列表、确认证书序列号、备份CA数据库
证书吊销这事儿，最怕什么？最怕你操作到一半，发现设备列表不对，或者序列号抄错了，再或者CA数据库崩了没法回滚。嗯，这些坑我都踩过。所以今天咱们聊聊吊销前的准备工作，说白了就是三件事：拿到准确的设备清单、确认每张证书的序列号、把CA数据库备份得妥妥当当。
一、获取设备列表：别信Excel，信系统
很多团队习惯用Excel维护设备清单。我个人觉得，这玩意儿只适合做展示，不适合做吊销依据。为什么？因为Excel里的数据可能滞后，可能被误改，甚至可能被删了都没人知道。
我建议直接从以下三个来源拉取设备列表：
- CMDB（配置管理数据库）：如果公司有CMDB，优先从这拉。字段要包含设备ID、设备类型、所属业务、证书序列号、证书到期时间。
- CA系统日志：从CA的签发日志里导出最近一段时间内签发的证书列表。这个最准，因为CA不会撒谎。
- 终端管理平台：比如AD域控、MDM（移动设备管理）或者IoT管理平台。这些平台会实时上报设备状态。
拿到列表后，我一般会整理成这样的格式：
| 设备ID | 设备类型 | 证书序列号 | 签发时间 | 到期时间 | 吊销状态 |
|---|---|---|---|---|---|
| DEV-001 | 服务器 | 0A:1B:2C:3D:4E:5F | 2024-01-15 | 2025-01-15 | 未吊销 |
| DEV-002 | 网关 | 6A:7B:8C:9D:0E:1F | 2024-02-20 | 2025-02-20 | 未吊销 |
| DEV-003 | 终端 | 2A:3B:4C:5D:6E:7F | 2023-11-10 | 2024-11-10 | 已过期 |
二、确认证书序列号：一个字符都不能错
证书序列号是吊销操作的唯一凭证。序列号错了，CA会报错，或者更糟——吊销了错误的证书。你想想看，把别人的证书吊销了，那台设备就彻底废了，业务中断的锅谁来背？
确认序列号，我一般走三步：
- 从设备本地读取：登录设备，用openssl或certutil命令读取证书序列号。比如Linux下执行
openssl x509 -in /etc/ssl/certs/device.crt -noout -serial。 - 从CA系统比对：在CA管理控制台里，根据设备ID或CN（通用名称）搜索证书，核对序列号是否一致。
- 人工复核：这一步很多人会跳过，但我建议至少抽检10%。尤其是批量吊销时，序列号格式可能不统一——有的是十六进制大写，有的是小写，有的带冒号，有的不带。统一转换成大写+冒号分隔的格式，比如
0A:1B:2C:3D:4E:5F。
避坑指南：我曾经遇到过一台设备上绑了多张证书的情况。比如服务器同时有TLS证书和代码签名证书，序列号完全不同。如果只吊销了TLS证书，代码签名证书还在，那这台设备依然能执行签名操作，等于没吊销干净。所以一定要确认：你要吊销的是哪张证书？设备上还有没有其他证书需要一并处理？
序列号确认无误后，我建议生成一个吊销清单文件，格式如下：
# 吊销清单 - 2024-12-01
# 格式：序列号,设备ID,吊销原因
0A:1B:2C:3D:4E:5F,DEV-001,设备报废
6A:7B:8C:9D:0E:1F,DEV-002,密钥泄露
2A:3B:4C:5D:6E:7F,DEV-003,业务下线这个文件后续可以直接导入吊销脚本，避免手动输入出错。
三、备份CA数据库：给自己留条后路
吊销操作是不可逆的。一旦执行，证书就废了，除非你重新签发。所以备份CA数据库是必须的，不是建议，是必须。
我见过最惨的情况：有人吊销证书时，CA数据库突然损坏，结果所有证书状态都丢了，整个PKI体系重建花了两周。嗯，从那以后，我每次操作前都会备份。
备份CA数据库，我建议做三件事：
- 全量备份CA数据库文件：比如OpenCA的
/var/lib/openca/data目录，或者EJBCA的MySQL/PostgreSQL数据库。用mysqldump或pg_dump导出完整SQL文件。 - 备份CA私钥和证书：虽然吊销操作不涉及私钥，但万一需要重建CA，私钥是命根子。把
ca.key和ca.crt复制到安全位置，最好加密存储。 - 备份吊销列表（CRL）：当前已签发的CRL文件也要备份。如果吊销后CRL生成失败，至少还有上一版CRL可用。
ca_backup_20241201_100000.sql。这样万一需要回滚，能精确找到操作前的那个版本。另外，备份文件要存到至少两个不同的物理位置，比如本地磁盘+远程NAS。
四、整体流程：一张图看懂
说了这么多，咱们用一张SVG图把整个准备流程串起来。这样你脑子里就有个清晰的框架了。
你看，整个流程其实不复杂，但每一步都马虎不得。尤其是备份这一步，很多人觉得麻烦就跳过了。但我跟你说，CA数据库一旦出问题，恢复成本远高于备份成本。所以，别偷懒。