📚 课程目录第4章证书颁发策略

4、证书颁发策略：CA分级架构设计、证书申请与签发流程、证书策略与证书实践声明

证书颁发策略，说白了就是回答三个问题：谁来发？怎么发？发了之后怎么管？

我见过不少物联网项目，一开始图省事，所有设备共用一套证书体系。结果设备量一上来，吊销一个证书要遍历整个数据库，运维直接崩溃。所以，这一章我们重点聊聊CA分级架构、申请签发流程，还有那些容易被忽略的策略声明。

4.1 CA分级架构设计

为什么一定要分级？你想想看，几百万个传感器如果都直接找根CA要证书，根CA的私钥暴露风险会急剧上升。一旦根CA被攻破，整个信任链就完了。

我个人习惯采用三级架构：根CA → 中间CA → 注册机构（RA）。根CA离线保存，中间CA负责签发，RA负责审核身份。

核心原则：根CA永远离线，中间CA按业务域拆分，RA贴近设备侧。

举个例子，我在做智能楼宇项目时，把中间CA分成了三类：

设备中间CA：专门签发传感器、执行器的设备证书
网关中间CA：签发边缘网关证书，策略更严格
运维中间CA：签发管理平台和运维工具的证书

这样即使设备中间CA被攻破，也只影响设备域，网关和运维系统不受牵连。

我的经验：中间CA的密钥最好用HSM（硬件安全模块）保护。有一次客户为了省钱把中间CA密钥放软件里，结果被挖矿病毒扫到了密钥文件...嗯，后来他们乖乖买了HSM。

4.2 证书申请与签发流程

流程设计得好，运维效率能翻倍。我一般把流程拆成四个阶段：

设备注册：设备出厂时预置唯一身份标识（如设备序列号、MAC地址）
CSR生成：设备本地生成密钥对，构造证书签名请求
RA审核：RA验证设备身份标识与注册信息是否匹配
CA签发：中间CA签发证书，返回给设备

这里有个关键点——私钥永远不能在网络上传输。CSR里只包含公钥和身份信息，私钥必须留在设备本地。

我曾经踩过的坑：有个项目为了简化流程，让设备把私钥通过HTTPS传给服务器生成证书。结果中间人攻击直接拿到了私钥副本。从那以后，我坚持私钥绝不离设备。

下面是一个典型的CSR生成代码示例（使用OpenSSL）：

# 设备本地生成密钥对
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:prime256v1 \
  -out /secure/device_privkey.pem

# 构造CSR，包含设备序列号
openssl req -new -key /secure/device_privkey.pem \
  -subj "/CN=SN-2024A0001/O=SmartHome/C=CN" \
  -addext "subjectAltName=DNS:sensor01.smarthome.local" \
  -out /tmp/device_csr.pem

# 将CSR发送给RA（通过安全通道）
curl -X POST https://ra.smarthome.local/csr \
  -H "Authorization: Bearer <device_token>" \
  --data-binary @/tmp/device_csr.pem

RA收到CSR后，会做以下几件事：

验证设备令牌是否有效
检查CSR签名是否完整
核对设备序列号是否在注册列表中
确认证书请求的域名或标识符是否合规

审核通过后，RA将CSR转发给中间CA。中间CA签发证书时，会附加一些关键扩展：

扩展项	用途	示例值
Key Usage	限制密钥用途	digitalSignature, keyEncipherment
Extended Key Usage	限制证书用途	clientAuth（仅客户端认证）
Subject Key Identifier	唯一标识公钥	哈希值
Authority Key Identifier	指向签发CA	CA公钥哈希

我建议：物联网设备证书尽量只开clientAuth这一个用途。别图省事把serverAuth也加上，万一证书泄露，攻击者能拿它伪装服务器。

4.3 证书策略与证书实践声明

证书策略（CP）和证书实践声明（CPS）是CA运营的“宪法”。很多团队觉得这是法务的事，技术不用管。其实不然——CP和CPS直接决定了你的证书体系是否合规、是否可审计。

证书策略（CP）是一份高层次文档，描述CA签发证书的目的、适用范围和安全要求。它面向的是证书使用者和管理者。

证书实践声明（CPS）是具体操作手册，描述CA每天怎么干活。它面向的是CA运维人员。

我参与过的一个智慧城市项目，CP里明确写了：

证书有效期不超过365天
设备证书只能用于TLS客户端认证
私钥必须存储在安全元件（SE）或TPM中
吊销检查间隔不超过24小时

而对应的CPS则详细到：

RA审核员每天几点检查注册列表
CSR审核超时时间设为30秒
证书吊销列表（CRL）每6小时更新一次
HSM的备份密钥由两人分别保管

关键区别：CP说“要做什么”，CPS说“怎么做”。CP变更需要审批委员会，CPS变更运维主管签字就行。

写CPS时，我习惯用表格把每个操作步骤列清楚：

操作项	责任人	执行频率	记录方式
CSR审核	RA审核员	实时	审计日志
证书签发	中间CA自动	按需	数据库记录
CRL发布	CA运维	每6小时	文件签名
密钥轮换	CA运维+安全官	每2年	双人签字

注意：CP和CPS不是写一次就完事的。我见过一个项目，CPS里写的CRL更新频率是1小时，实际运维改成6小时，结果审计时被开了严重不符合项。所以，文档和实际操作必须一致。

最后说一句，证书策略里一定要包含吊销策略。设备被篡改、密钥泄露、设备退役，这些场景都需要及时吊销证书。我建议在CP里明确：

吊销触发条件（如：设备离线超过30天）
吊销通知方式（如：通过MQTT下发吊销指令）
吊销后的重新签发流程

嗯，证书颁发策略这块，核心就是架构要分层、流程要闭环、策略要落地。别想着一步到位，先跑通最小可行体系，再逐步完善。