📚 课程目录第2章设备证书生命周期

2. 设备证书生命周期：证书申请、签发、分发、使用、续期、吊销全流程

设备证书的生命周期，说白了就是一张证书从「出生」到「死亡」的全过程。很多运维兄弟只关心证书能不能用，却忽略了每个环节都可能埋坑。我这些年处理过的证书故障，十有八九都出在生命周期管理上。

咱们先看一张总览图，把整个流程串起来。

2.1 证书申请：一切从这里开始

申请阶段的核心产出是 CSR（Certificate Signing Request）。说白了，就是设备把自己的公钥和身份信息打包，交给 CA 去签名。

我个人习惯把申请过程拆成三步：

生成密钥对 —— 私钥必须留在设备本地，绝对不能外传
构造 CSR —— 包含公钥、CN（Common Name）、组织信息等
提交给 CA —— 通过 API 或手动上传

小技巧： 我建议在 CSR 的 Subject 里加上设备序列号或唯一标识，方便后续审计。曾经有个客户，几千台设备证书的 CN 全是 "device"，吊销时根本分不清哪台是哪台。

一个典型的 CSR 生成命令长这样：

# 生成 RSA 2048 位密钥对
openssl genrsa -out device.key 2048

# 生成 CSR
openssl req -new -key device.key -out device.csr \
  -subj "/CN=device-001/O=MyCompany/C=CN" \
  -addext "subjectAltName=DNS:device-001.example.com"

嗯，这里要注意：SAN（Subject Alternative Name） 现在几乎是必填项。很多现代客户端只认 SAN，不认 CN。我踩过这个坑，证书明明配了 CN，浏览器就是报「证书名称不匹配」。

2.2 证书签发：CA 的活儿

CA 收到 CSR 后，会做两件事：验证身份、签名证书。

验证方式取决于你的 PKI 架构：

内部 PKI：通常通过 API Token 或预共享密钥验证
外部 CA：需要人工审核或域名验证（DV/OV/EV）

签发时，CA 会往证书里写入一堆关键字段。我整理了一张表，方便你对照：

字段	含义	常见坑点
有效期	notBefore ~ notAfter	设备证书建议 1-2 年，太长有安全风险
Key Usage	digitalSignature, keyEncipherment 等	缺了 keyEncipherment 会导致 TLS 握手失败
Extended Key Usage	serverAuth, clientAuth	双向认证时两端都要配
CRL Distribution Points	吊销列表下载地址	地址不可达会导致验证超时
Authority Info Access	OCSP 响应地址	必须配 HTTPS，否则明文传输有风险

警告： 我曾经遇到一个案例，设备证书的 Key Usage 只配了 digitalSignature，结果做 TLS 加密时直接报错。CA 签发时一定要跟业务方确认用途，别想当然。

2.3 证书分发：安全第一

证书签发完成后，怎么安全地送到设备上？这是个容易被忽视的环节。

我见过最野的操作：用邮件发 .p12 文件，密码写在正文里。嗯，这跟把银行卡密码贴在卡上没区别。

推荐几种安全分发方式：

SCEP（Simple Certificate Enrollment Protocol）：设备主动拉取，支持挑战密码
EST（Enrollment over Secure Transport）：基于 TLS 的标准化协议
API 直推：通过 mTLS 加密通道下发给设备
手动安装：仅适用于少量设备，必须走带外通道

分发时，我建议把证书和私钥分开传输。私钥最好在设备本地生成，CA 只下发证书。如果必须打包下发，记得用强密码加密，且传输通道必须是 HTTPS 或 SFTP。

2.4 证书使用：设备开始干活

证书装到设备上后，主要干三件事：

TLS 握手 —— 服务端证书用于身份认证，客户端证书用于双向认证
数字签名 —— 固件签名、配置签名等
数据加密 —— 用公钥加密，私钥解密

使用阶段最容易出问题的，其实是 证书链验证。设备上不仅要装自己的证书，还得装中间 CA 和根 CA 的证书。我遇到过一台 IoT 设备，只装了叶子证书，没有中间 CA，结果 TLS 握手时对端无法构建完整链，直接拒绝连接。

  核心原则： 设备上必须包含完整的证书链（叶子 + 中间 CA + 根 CA），且根 CA 证书要标记为「信任锚」。

2.5 证书续期：别等到最后一刻

证书到期前必须续期。续期本质上就是重新走一遍申请 + 签发流程，但有个关键区别：私钥可以重用，也可以重新生成。

我个人建议每次续期都重新生成密钥对。原因很简单：私钥用得越久，泄露风险越大。你想想看，一个用了三年的私钥，中间经过了多少次备份、迁移、运维操作？

续期的时间窗口怎么定？我一般这么设：

有效期 1 年的证书：提前 30 天开始续期
有效期 2 年的证书：提前 60 天开始续期
自动续期：失败后重试 3 次，间隔 1 小时

避坑指南： 我曾经负责一个物联网平台，几千台设备证书同时到期，续期请求把 CA 打挂了。后来我改成「随机偏移续期时间」，每台设备在到期前 30 天内随机选一个时间点续期，完美解决。

2.6 证书吊销：紧急情况下的「核按钮」

证书吊销，说白了就是让一张还在有效期内的证书提前失效。什么情况下需要吊销？

私钥泄露（最常见）
设备被盗或退役
员工离职（如果是个人证书）
证书信息变更（如域名变更）

吊销后，CA 需要把证书序列号发布到 CRL（证书吊销列表） 或通过 OCSP（在线证书状态协议） 实时查询。

这里有个性能问题：CRL 会越来越大，设备每次验证都要下载整个列表。我建议用 OCSP 做实时查询，CRL 做兜底。OCSP 响应可以缓存，但缓存时间别太长，我一般设 5-10 分钟。

注意： 吊销不是删除！证书吊销后，CA 必须保留吊销记录，用于审计和追溯。我曾经见过有人吊销证书后直接把数据库记录删了，结果审计时完全查不到。

2.7 全流程监控：别让证书「裸奔」

生命周期管理不能只靠人工。我建议在每个环节都加监控：

环节	监控指标	告警阈值
申请	CSR 提交成功率	< 99% 告警
签发	签发延迟	> 5 分钟告警
分发	分发失败率	> 1% 告警
使用	TLS 握手失败率	> 0.1% 告警
续期	到期前剩余天数	< 7 天紧急告警
吊销	CRL 更新延迟	> 1 小时告警

嗯，这套监控体系我用了好几年，基本没出过大问题。你如果刚开始搭 PKI，建议先从「续期告警」和「吊销响应延迟」入手，这两个是最容易出事的环节。