数字证书、CA 与证书链：信任的基石

聊到启动校验，绕不开一个核心问题：你怎么确定手里的公钥是真的？

你想想看，如果攻击者在中途把公钥换成了他自己的，那后续所有的校验都白搭了。我早年做嵌入式安全时，就见过一个产品因为硬编码了一个测试用的自签名证书，结果被逆向工程后直接伪造了固件更新包。嗯，那场面挺尴尬的。

所以，我们需要一套机制来证明“这个公钥确实属于声称拥有它的人”。这就是数字证书、CA 和证书链要解决的问题。

说白了，数字证书就是一个数字身份证。它把一个人的身份信息（比如公司名、域名）和一把公钥绑定在一起，然后由一个大家都信任的机构来签名担保。

我习惯把证书想象成一个带防伪标签的驾照。驾照上有你的照片、姓名、准驾车型，还有发证机关的盖章。证书也一样：

证书的格式标准是 X.509。你平时看到的 .crt、.pem、.der 文件，本质上都是 X.509 证书的不同编码形式。

核心要点：证书本身不保证“你是好人”，它只保证“这个公钥在有效期内确实属于这个主体”。至于这个主体是否可信，那是你业务逻辑要判断的事。

CA 就是那个发证的机构。它的角色非常关键——它是信任的起点。

CA 的工作流程大致是这样的：

验证身份：你提交 CSR（证书签名请求）给 CA，CA 会通过各种方式验证你的身份是否真实。比如申请 SSL 证书时，CA 会让你证明你确实拥有这个域名。
签发证书：验证通过后，CA 用自己的私钥给你的公钥和身份信息签名，生成一张数字证书。
维护状态：CA 还会维护证书吊销列表（CRL）或提供 OCSP 服务，告诉你哪些证书已经失效了。

CA 本身也分等级。最顶层的叫根 CA（Root CA），它的证书是自签名的——也就是自己给自己发证。根 CA 的证书被预置在操作系统、浏览器或设备的信任存储区里。

一个小经验：我在做 IoT 设备启动校验时，通常不会直接把根证书烧录到设备里。因为根证书一旦泄露或需要更换，代价太大了。我一般会用一个中间 CA 来签发设备证书，设备里只信任这个中间 CA。这样即使中间 CA 出问题，根 CA 还在，重新签发一批中间证书就行。

你不可能让所有设备都直接信任根 CA。根 CA 的私钥太重要了，通常会被离线保存在保险柜里。日常签发工作是由中间 CA（Intermediate CA）来完成的。

这就形成了证书链：

验证的时候，从终端证书开始，逐级向上找签发者，直到找到一个设备信任的根证书。这个过程就叫证书链验证。

我曾经在一个项目中遇到过一个问题：设备只烧录了根证书，但服务器下发的是完整的证书链（终端证书 + 中间证书）。结果设备在验证时，因为找不到中间证书的签发者（根证书），验证失败了。后来我调整了策略，让设备在收到证书链后，先缓存中间证书，再逐级向上验证。问题就解决了。

注意：证书链验证不仅仅是检查签名。你还需要检查：

下面这张图展示了典型的证书链结构。你可以看到信任是如何从根 CA 一层层传递到终端设备的。

在启动校验场景里，证书链通常是这样用的：

验证流程就是：BootROM 用内置的根公钥验证 Bootloader 的签名 → Bootloader 用中间证书验证内核镜像的签名。每一级只信任上一级签发的证书，形成一条完整的信任链。

我的建议：在设计启动校验时，不要把证书链搞得太长。三级（根 → 中间 → 终端）通常就够了。链太长会增加验证时间和存储开销，而且中间任何一环出问题都会导致启动失败。

好了，证书和 CA 的基本概念就这些。记住一句话：证书是载体，CA 是担保，证书链是信任的传递路径。搞懂这三者的关系，后面讲证书绑定和校验逻辑时，你就不会觉得晕了。