4、证书管理：PKI体系是基石，但别让它成为绊脚石。
说到设备身份治理，PKI（公钥基础设施）几乎是绕不开的话题。很多厂商上来就跟你讲“我们支持国密”、“我们有自研CA”，听起来很唬人。但说实话，PKI这东西，用好了是基石，用不好就是绊脚石。我在项目里见过太多“证书管理翻车”的案例，今天就跟大家聊聊这里面的坑。
4.1 你真的需要自建CA吗？
这是第一个灵魂拷问。很多甲方一上来就说：“我们要自建CA，安全可控。” 嗯，精神可嘉，但现实往往很骨感。
自建CA意味着什么？你得维护一套完整的CA系统，包括根CA、中间CA、OCSP响应器、CRL分发点。这还没完，你得有专人盯着证书生命周期，从申请、审核、签发、续期到吊销，每个环节都不能出错。
我个人习惯是，先问三个问题：
- 设备量级：是几千台还是几百万台？量级不同，架构完全不同。
- 生命周期：设备证书有效期多久？是1年还是10年？
- 运维能力：团队有没有PKI运维经验？
如果设备量不大（比如<10万），且团队没有专职PKI运维人员，我建议直接考虑托管CA服务。别为了“可控”二字，把自己拖进运维泥潭。
4.2 证书生命周期管理：别让证书“裸奔”
证书不是签发了就完事了。它从生到死，每个阶段都有坑。
我把它分成四个阶段：
| 阶段 | 核心动作 | 常见坑点 |
|---|---|---|
| 注册 | 设备身份绑定、CSR生成 | CSR中CN/SAN填写不规范，导致身份绑定失败 |
| 签发 | CA验证、签发证书 | CA策略过于宽松，未做设备身份校验 |
| 使用 | TLS握手、签名验证 | 证书链不完整，客户端验证失败 |
| 吊销 | 设备退役、私钥泄露 | CRL/OCSP更新不及时，已吊销证书仍被信任 |
这里重点说说吊销。很多平台只关注签发，不关注吊销。结果设备被攻破了，私钥泄露了，但证书还在有效期内。你想想看，这跟没锁门有什么区别？
4.3 证书格式与算法：兼容性是个大问题
你以为证书就是X.509？太天真了。实际项目中，你会遇到各种“方言”。
我记得有一次，某物联网平台对接一个传感器厂商。对方说支持证书认证，结果发过来的证书是DER格式的，而且签名算法是SHA1WithRSA。我们的平台只支持PEM格式和SHA256。就这一个问题，扯皮了两周。
所以，选型时一定要确认以下几点：
- 证书格式：PEM、DER、PKCS#12，你的平台都支持吗？
- 签名算法：至少支持SHA256WithRSA，SHA1已经不安全了。
- 密钥类型：RSA 2048位起步，ECC（P-256）也是好选择。
- 国密支持：如果涉及合规，SM2/SM3/SM4必须支持。
4.4 证书存储：硬件还是软件？
证书私钥放哪儿？这是个老生常谈的问题。
软件存储（文件系统、数据库）成本低，但安全性也低。硬件存储（HSM、TEE、SE）安全性高，但成本也高。
我的建议是分层处理：
- CA私钥：必须用HSM。这是整个PKI的根，丢了就全完了。
- 设备私钥：根据设备安全等级来定。高安全设备（如支付终端）用SE或TEE；普通IoT设备用软件存储+加密保护即可。
这里有个坑：很多平台把设备私钥直接明文存储在Flash里。一旦设备被物理破解，私钥就泄露了。我建议至少做一层加密，密钥从设备唯一ID派生。
4.5 PKI体系架构图
下面这张图，是我个人习惯用的PKI架构。它涵盖了从根CA到设备证书的全链路。
4.6 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历的坑，希望能帮你少走弯路。
- 坑一：证书链不完整。有一次，设备端只带了终端证书，没带中间CA证书。结果服务端验证时，找不到中间CA，直接拒绝连接。排查了半天，最后发现是证书打包时漏了。所以，一定要在设备端配置完整的证书链。
- 坑二：CRL更新不及时。某项目，设备被吊销后，CRL列表一天才更新一次。结果被吊销的设备在这一天内还能正常通信。后来我们改成了OCSP实时查询，才解决这个问题。
- 坑三：证书序列号重复。这个比较低级，但确实发生过。CA系统配置不当，导致不同设备拿到了相同的序列号。虽然概率低，但一旦发生，排查起来非常痛苦。建议使用UUID作为序列号，保证全局唯一。