3. 公钥基础设施（PKI）：CA机构、证书链、X.509证书格式、证书吊销
说到安全更新签名验证，公钥基础设施（PKI）是绕不开的基石。说白了，PKI就是一套让互联网上互不相识的实体能安全交换公钥的信任体系。我做了这么多年安全，见过太多因为PKI设计不当导致签名验证形同虚设的案例。这一节，我们就把PKI的核心组件掰开揉碎了讲清楚。
3.1 CA机构：信任的起点
CA（Certificate Authority，证书颁发机构）是整个PKI信任链的根。它的职责很简单：核实申请者的身份，然后签发数字证书。你想想看，如果没有CA，任何人都可以声称自己是“Microsoft更新服务器”，那签名验证还有什么意义？
CA分两类：
- 公共CA：如DigiCert、GlobalSign、Let's Encrypt。它们被操作系统和浏览器广泛信任，适合面向公众的服务。
- 私有CA：企业内部自建的CA。我在项目中遇到过很多企业用OpenSSL搭建私有CA，用于内部设备固件签名。这样做的好处是密钥完全自主可控，但管理成本也不低。
核心原则：CA的私钥是PKI中最敏感的秘密。一旦泄露，攻击者就能签发任意证书，整个信任体系瞬间崩塌。我见过某厂商把CA私钥直接放在CI/CD流水线的环境变量里——嗯，这基本等于把家门钥匙挂在门外。
3.2 证书链：信任的传递
为什么要有证书链？直接让根CA签发所有证书不行吗？理论上可以，但实践中不行。根CA的私钥太重要了，不能频繁使用。所以PKI引入了层级结构：
- 根CA：自签名证书，离线存储，极少使用。
- 中间CA：由根CA签发，负责实际签发终端实体证书。
- 终端实体证书：最终用于签名验证的证书，如代码签名证书、TLS服务器证书。
验证时，验证方从终端证书开始，逐级向上追溯，直到找到本地信任的根证书。这个过程就是证书链验证。
我的经验：在安全更新系统中，我建议把中间CA证书和终端证书一起打包分发。因为很多嵌入式设备没有完整的CA证书库，只信任一个根。如果不带中间证书，链就断了，验证会失败。我曾经踩过这个坑，调试了整整两天才发现是缺了中间证书。
下面这张图展示了典型的证书链结构：
3.3 X.509证书格式：到底长什么样？
X.509是数字证书的国际标准格式。你打开一个证书文件，看到的那些乱码其实是ASN.1编码后的二进制数据。但别被吓到，我们只需要理解它的核心字段。
一个标准的X.509 v3证书包含以下主要部分：
| 字段 | 说明 | 我的备注 |
|---|---|---|
| 版本号 | 目前主流是v3（值为2） | v3引入了扩展字段，非常重要 |
| 序列号 | CA分配给证书的唯一编号 | 吊销时靠它定位 |
| 签名算法 | 如sha256WithRSAEncryption | 别用SHA-1，已经不安全了 |
| 颁发者 | 签发该证书的CA名称 | DN格式，如CN=MyCA,O=MyOrg |
| 有效期 | notBefore 和 notAfter | 我建议代码签名证书有效期不超过3年 |
| 主体 | 证书持有者名称 | 可以是域名、组织名或设备ID |
| 公钥 | 持有者的公钥信息 | 算法+密钥值 |
| 扩展 | v3引入的附加属性 | 关键扩展：Key Usage、Basic Constraints |
| 签名值 | CA用私钥对上述字段的签名 | 验证完整性的关键 |
注意：在安全更新场景中，证书的Key Usage扩展必须包含digitalSignature。如果漏了这个，验证方应该拒绝该证书。我曾经审计过一个项目，他们的代码签名证书Key Usage只写了serverAuth——签名验证通过了，但这是不合规的。
用OpenSSL查看证书内容的命令很简单：
# 查看PEM格式证书
openssl x509 -in certificate.pem -text -noout
# 查看DER格式证书
openssl x509 -in certificate.der -inform DER -text -noout输出会显示所有字段，包括扩展。我个人习惯先看Issuer和Subject，确认证书链关系，再看Validity和Key Usage。
3.4 证书吊销：信任的撤回
证书不是永久的。私钥泄露、员工离职、域名变更——这些情况都需要吊销证书。PKI提供了两种吊销机制：
- CRL（证书吊销列表）：CA定期发布一个被吊销证书的列表。验证方下载并检查。
- OCSP（在线证书状态协议）：实时查询单个证书的状态。更高效，但需要OCSP响应器在线。
两种方式的对比：
| 特性 | CRL | OCSP |
|---|---|---|
| 实时性 | 取决于发布周期（可能数小时到数天） | 实时查询 |
| 网络开销 | 需要下载整个列表（可能很大） | 每次只查一个证书 |
| 隐私性 | 不泄露查询目标 | CA知道你在查哪个证书 |
| 离线可用 | 可缓存列表 | 需要在线 |
| 适用场景 | 嵌入式设备、离线环境 | 高实时性要求的在线服务 |
我的建议：在安全更新系统中，我倾向于使用CRL + OCSP stapling的组合。设备定期拉取CRL缓存，同时服务器在TLS握手时附带OCSP响应。这样既保证了离线可用性，又能及时获取最新吊销状态。不过要注意，CRL缓存时间不能设太长——我曾经见过某设备缓存了30天的CRL，结果被吊销的证书还在用。
还有一个概念叫OCSP Must-Staple。这是证书扩展，要求服务器必须提供OCSP stapling响应。如果服务器没带，客户端应该拒绝连接。这个机制能有效防止OCSP请求被中间人拦截。
关键点总结：
- CA是信任的根，私钥保护是头等大事
- 证书链实现了信任的层级传递，减少根CA的使用频率
- X.509 v3证书的扩展字段（Key Usage、Basic Constraints）决定了证书的用途
- CRL和OCSP是证书吊销的两种手段，各有优劣，按场景选择
嗯，PKI这部分内容就讲到这里。理解这些基础，后面讲代码签名和更新包验证时，你就能明白为什么证书链验证、吊销检查这些步骤不可或缺了。