4. 证书生命周期管理：从生到死的完整旅程

证书不是永远有效的。它从申请、签发，到使用、吊销，再到最后的更新，每一个环节都有坑。我最早接手 PKI SDK 改造时，只盯着签发流程，觉得只要能生成证书就行。结果线上出事之后才明白，生命周期管理如果没做好，整个系统就是定时炸弹。

这一章，咱们把证书的整个生命流程拆开看。说白了就是回答两个问题：一张证书怎么来到这个世界，又该怎么体面地离开。

4.1 申请与签发：证书的「出生」

证书的生命，从 CSR（证书签名请求）开始。

申请阶段，客户端先生成公私钥对，然后把公钥和身份信息打包成 CSR，提交给 CA。我建议你注意一下，CSR 里包含的 Subject、Public Key、Signature Algorithm 这三项，缺了哪个后面都会出问题。

签发阶段，CA 拿到 CSR 后做两件事：

• 验证身份：确认 CSR 里的签名确实来自对应的私钥持有者
• 组装证书：把公钥、身份信息、有效期、颁发者信息组合，再用 CA 私钥签名

这里有一个容易忽略的点：Key Usage 和 Extended Key Usage。我在项目中遇到过，有人把 Key Usage 设成了数字签名，结果证书被拿去服务端认证，直接报错。你想想看，这种情况多冤枉。

4.2 证书验证：别以为拿到手就能用

签发完毕，客户端拿到证书。很多 SDK 就直接去用了，结果握手阶段才发现证书有问题。我建议你在 SDK 里内置一个验证流程——说白了，先自己查一遍，再扔给系统去查双重。

证书验证的核心步骤：

1. 签名验签：用 CA 公钥验证证书上的签名
2. 有效期检查：当前时间是否在 notBefore 和 notAfter 之间
3. 吊销状态：查询 CRL 或 OCSP（下面会细讲）
4. 链完整性：当前证书到根证书的路径是否完整

4.3 吊销与 CRL/OCSP：证书的「死亡宣告」

证书被吊销，意味着它不再被信任。为什么会吊销？私钥泄露、域名变更、员工离职，原因很多。问题在于，怎么让全系统都知道这个证书已经死了。

主流的两种方式：

我建议你在 SDK 里同时支持两种模式，优先级设为 OCSP > CRL。但要注意，OCSP Stapling 是性能最优的方案——服务器主动把 OCSP 响应拼在握手包里，客户端不用再查一遍。嗯，这个咱们后面讲 TLS 握手的章节会细说。

4.4 更新：让证书「优雅续命」

证书到期前必须更新。我在项目里见过太多次，证书过期了还在跑，系统直接瘫痪。你想想看，这种问题其实完全可以避免。

我个人推荐的做法是：静默续期。SDK 在证书到期前 30 天就开始自动申请新证书，下载后直接替换旧证书，整个过程对业务无感。

实现的关键点：

• 监控通知：设置一个定时器，每天检查一次证书剩余有效期
• 预签发：到期前若干天就开始走签发流程，避免最后一天突发异常
• 原子替换：新证书写入和旧证书删除必须是原子操作，防止中间状态

4.5 状态验证：谁在查谁？

证书的状态验证不是单向的。既有服务端向 CA 查自己证书是否被吊销，也有客户端查服务端证书是否有效。我建议你把这些逻辑抽象成一个统一的 状态检查器：

• 本地缓存：CRL 和 OCSP 响应结果不要每次都请求，缓存一段时间
• 异步刷新：后台线程定期拉取，避免阻塞业务线程
• 降级策略：如果 OCSP 服务不可用，是否允许回退到 CRL？是否允许本地信任？

我记得有一个系统的设计很有意思：他们把 OCSP 响应缓存 24 小时，然后每天凌晨统一刷新一批证书的状态。这种做法在大多数内网场景下是安全的，而且性能很好。

4.6 完整流程图谱

上面讲了这么多，我画了一张图帮你理清整个生命周期。你可以把它当作代码实现时的参考，每个节点对应一个模块。

图里你能看到，签发之后是验证与使用，接着进入吊销或更新分支，最后状态验证结果又会反馈给验证环节。这个闭环是保证证书安全的核心。我建议你写 SDK 时，把每个环节都设计成可插拔的模块。

4.7 避坑总结

最后，把我这些年踩过的坑列出来，你写代码时记得避开：

• 别把签发和验证放一起：我见过有人想在同一个线程里做签发、验证、写库，结果并发一上来就卡死。建议拆成异步任务。
• CRL 太大怎么办？：分片下载，或者直接用 OCSP。我现在是默认 OCSP，CRL 做降级。
• 证书更新别全量替换：保留旧证书一小段时间，等所有连接都切换到新证书之后再删除。
• 状态验证缓存要设最大容量：我曾经没加缓存驱逐策略，结果内存撑爆了——就几千张证书而已，但缓存不清理也能吃满内存。

嗯，证书生命周期管理说到这儿。你仔细看看那幅图，想想如果让你来写 SDK，你会把每个模块封装成什么接口。