第1章：PKI 基础概念回顾
咱们先聊点基础的。毕竟后面要做跨平台的 SDK 改造，如果 PKI 的概念不捋清楚，后面代码逻辑很容易跑偏。
我刚开始做安全开发那会儿，也以为 PKI 就是“买个证书装上就完事”。后来线上出了事故才发现——嗯，没那么简单。
1.1 公钥基础设施到底是个啥？
PKI，全称 Public Key Infrastructure，中文叫公钥基础设施。说白了，它是一套“让人能信任公钥”的机制。
想象一下：你想给同事发加密邮件，你需要他的公钥。问题是——你怎么确保这个公钥真的是他的，而不是黑客伪造的？
PKI 就是解决这个问题的。
它的核心组成部分包括：
- 数字证书：把身份和公钥绑定在一起的文件
- CA（证书颁发机构）：签发证书的权威机构
- RA（注册机构）：帮 CA 做身份审核的部门
- 证书吊销列表：被吊销的证书名单
- 密钥管理系统：生成、存储、销毁密钥的整套流程
我记得有一次，客户在 iOS 上集成我们的 SDK，发现 SSL 握手总是失败。最后定位到是他们内部部署的 CA 没配置好证书链——公钥根本没在可信列表里。
一句话总结：PKI 就是一套“认证公钥真伪”的公共框架。没有它，互联网上的加密通信基本不靠谱。
1.2 数字证书的结构
数字证书这东西，大家最熟悉的可能就是 X.509 v3 格式。HTTPS 用的就是它。
证书里包含的关键字段，我列个表给大家看看：
| 字段 | 含义 | 实际作用 |
|---|---|---|
| 版本号 | X.509 版本 | v3 支持扩展域 |
| 序列号 | CA 唯一编号 | 吊销时定位证书 |
| 签名算法 | 比如 SHA-256 + RSA | 验证证书完整性 |
| 颁发者 | 签发这张证书的 CA 名称 | 构建证书链 |
| 有效期 | 起止时间 | 防止永久有效 |
| 主体 | 证书持有者 | 比如域名 example.com |
| 公钥 | 持有者的公钥 | 加密/验签用 |
| 扩展域 | 用途限制、密钥用法等 | 防滥用 |
这里有个坑，我在项目里踩过：证书的扩展域里有个字段叫 Key Usage。如果你的证书标记了“仅用于数字签名”，但你拿去给 SSL 做密钥交换——握手直接就断了。
避坑指南：我曾经在 Android 上遇到过一次证书验证失败，查了两天才发现是证书的 Basic Constraints 扩展没设 CA 标志，导致中间 CA 证书被客户端当成终端证书验了。写 SDK 时一定要检查扩展字段。
1.3 CA 与 RA 的角色分工
很多人以为 CA 和 RA 是一个东西。其实不是。
- CA（Certificate Authority）：手里握着根密钥，负责签发证书。它是最终的信任锚点。
- RA（Registration Authority）：做身份审核的代理。它不直接签发证书，但会确认“这个人是不是真的这个人”。
你想想看，大型企业里，如果每个员工申请证书都得找 CA 审查身份，CA 的工作量太大了。所以 RA 就把审核工作分担出去，只把审核通过的结果告诉 CA，CA 直接签发。
实践中：我在帮某金融机构做项目时，他们自己建了 RA 系统，配合外部的公开 CA。RA 审核员工身份，外部 CA 签发证书。这样既控制了成本，又保证了权威性。
1.4 证书链
证书链，这是 PKI 里最容易让人绕晕的概念。
简单说：一个证书不是孤立存在的。你要验证它，得一直往上找到根证书。
结构一般是三层：
- 根 CA 证书：自签名，是信任的起点。所有设备里预置的信任列表就是它。
- 中间 CA 证书：由根 CA 签发，负责给终端用户发证书。为什么要有这层？怕根证书被攻破。
- 终端实体证书：比如你的网站证书，或客户端的身份证书。
验证过程是：拿着终端证书，找到它的颁发者（中间 CA），再验证中间 CA 的合法性，直到根证书 — 如果根证书在系统的信任库里，整条链就受信了。
为什么会这样设计？
你想想，如果根证书直接被用来签发所有终端证书，一旦根私钥泄露，整个 PKI 体系全报废。有了中间层，即使某个中间 CA 被攻破，吊销它一个就够了，根证书依然安全。
我个人的习惯：在 SDK 里，我会用代码强制检查证书链的完整性，不依赖操作系统的默认行为。因为 iOS 和 Android 对证书链拼装的处理细节不一样——这个后面咱们会专门讲。
下面这张图展示了 PKI 的核心信任模型：