4、证书签发流程：CSR生成、CA验证、证书签发、证书链构建、CRL与OCSP
证书签发，是整个PKI体系里最核心的环节。说白了，就是让CA给设备发一张「数字身份证」。我这些年经手过不少物联网项目，从几万个传感器的小规模部署，到百万级车联网平台，签发流程的坑几乎都踩过一遍。今天咱们就把这个流程拆开揉碎了讲清楚。
4.1 CSR生成——证书请求的起点
CSR，全称是证书签名请求。设备要拿证书，第一步就是自己生成一对密钥，然后把公钥和身份信息打包成CSR，发给CA。
我个人习惯，在生成CSR时特别注意两点：一是密钥强度，二是Subject字段的完整性。物联网设备资源有限，但RSA 2048位是底线，千万别为了省那几毫秒用1024位。
CSR的核心内容：
- 公钥——设备生成的RSA或ECC公钥
- Subject——设备的DN（Distinguished Name），包括CN、O、OU等
- 签名算法——用设备私钥对CSR签名，证明你拥有对应的私钥
下面是一个典型的CSR生成命令，我建议你在生产环境中加上 -config 参数指定openssl配置文件，避免默认参数出问题。
# 生成设备私钥（RSA 2048位）
openssl genrsa -out device.key 2048
# 生成CSR
openssl req -new -key device.key -out device.csr \
-subj "/C=CN/O=IoTCompany/CN=device-001.iot.example.com"我的经验： 物联网设备批量部署时，CSR生成最好在产线完成。我曾经遇到一个项目，设备到现场后才生成CSR，结果网络不通，折腾了两周。后来改成产线预生成，问题迎刃而解。
4.2 CA验证——别让假设备混进来
CA收到CSR后，不能直接签发。你得先验证这个请求是不是合法的。验证分两步：身份验证和请求完整性验证。
身份验证，就是确认CSR里的Subject信息跟设备真实身份一致。在物联网场景里，通常通过设备序列号、MAC地址或者预置的注册码来验证。我见过有些项目图省事，跳过这一步，结果被攻击者伪造设备身份混入网络，教训很深刻。
请求完整性验证，是用CSR里的公钥验证签名。这一步是自动的，CA系统会检查签名是否匹配。如果签名验证失败，说明CSR被篡改过，直接拒绝。
注意： 验证CSR时，一定要检查Subject字段里的CN是否在允许的设备命名规则内。我曾经遇到过攻击者把CN改成“admin”试图获取高权限证书，幸好验证规则拦住了。
4.3 证书签发——CA的签名时刻
验证通过后，CA就开始签发证书了。这个过程包括：组装证书内容、用CA私钥签名、生成证书文件。
签发时，CA会把以下信息写入证书：
| 字段 | 说明 | 示例值 |
|---|---|---|
| 版本号 | X.509版本，目前主流是v3 | 2（表示v3） |
| 序列号 | CA分配的唯一编号 | 0x1A2B3C4D |
| 签名算法 | CA签名使用的算法 | sha256WithRSAEncryption |
| 颁发者 | CA自身的DN | /C=CN/O=IoTCA |
| 有效期 | 起止时间 | 2025-01-01 ~ 2026-01-01 |
| 主体 | 设备的DN | /C=CN/O=IoTCompany/CN=device-001 |
| 公钥 | 设备的公钥 | RSA公钥数据 |
| 扩展项 | 密钥用途、CRL分发点等 | Digital Signature, Key Encipherment |
签发命令很简单，但参数配置要仔细：
# CA签发设备证书
openssl x509 -req -in device.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out device.crt -days 365 \
-extfile device.ext我的习惯： 物联网设备的证书有效期不宜太长。我一般设1年，最多2年。时间太长，设备被攻破后证书吊销不及时，风险太大。时间太短，设备更新证书的运维成本又高。1年是个平衡点。
4.4 证书链构建——信任的传递
单张证书没法自证清白，得靠证书链把信任从根CA传递下来。证书链的结构通常是：根CA → 中间CA → 设备证书。
为什么要有中间CA？直接让根CA签发设备证书不行吗？技术上可以，但安全上不行。根CA的私钥是整个信任体系的命根子，一旦泄露，所有证书都得作废。所以实践中，根CA通常离线保存，只在签发中间CA时才上线。日常的设备签发，由中间CA完成。
证书链构建时，需要把中间CA证书和设备证书一起发给设备。设备验证时，从设备证书开始，逐级向上验证签名，直到信任的根CA。
证书链构建要点：
- 设备端需要保存完整的证书链（设备证书 + 中间CA证书）
- 根CA证书通常预置在设备的信任存储中
- 验证时从设备证书开始，逐级验证签名，直到信任锚点
4.5 CRL与OCSP——证书的「死亡名单」
证书签发后，不代表永远有效。设备被攻破、私钥泄露、设备退役，都需要吊销证书。吊销信息的查询方式有两种：CRL和OCSP。
CRL（证书吊销列表），是CA定期发布的被吊销证书列表。设备或验证方下载CRL后，检查目标证书的序列号是否在列表中。CRL的缺点是实时性差，通常一天更新一次。
OCSP（在线证书状态协议），是实时查询证书状态的协议。验证方向OCSP响应器发送查询请求，响应器返回「良好」、「吊销」或「未知」三种状态。OCSP实时性好，但需要OCSP响应器在线。
| 对比项 | CRL | OCSP |
|---|---|---|
| 实时性 | 低（按周期更新） | 高（实时查询） |
| 网络开销 | 下载整个列表，文件可能很大 | 单次查询，数据量小 |
| 离线支持 | 支持（可缓存CRL文件） | 不支持（需要在线） |
| 适用场景 | 资源受限设备、离线环境 | 实时性要求高的场景 |
我曾经踩过的坑： 有个车联网项目，设备通过OCSP查询证书状态。结果OCSP响应器挂了，所有设备都无法验证对方证书，整个通信链路瘫痪。后来我改成CRL + OCSP双模式，优先用OCSP，OCSP不可用时回退到CRL缓存。这个方案后来成了我的标准配置。
在实际部署中，我建议物联网设备采用CRL为主、OCSP为辅的策略。设备每天凌晨下载一次CRL并缓存，平时验证用缓存数据。如果遇到高安全级别的操作（如固件升级、远程控制），再触发OCSP实时查询。这样既保证了实时性，又避免了单点故障。
我的建议： CRL分发点（CDP）和OCSP响应器地址，一定要写在证书的扩展项里。这样验证方拿到证书后，自动就知道去哪里查状态。我见过有些证书没配这些扩展项，结果验证方不知道去哪查，只能默认信任所有证书——这跟没吊销一样。
证书签发流程，说到底就是「生成-验证-签发-构建-查询」这五个环节。每个环节都有坑，但只要你把流程标准化、自动化，物联网设备的大规模证书管理并不难。嗯，今天就聊到这儿，这些经验希望对你有帮助。