1. PKI 基础概念：公钥基础设施、数字证书、CA机构
咱们搞SDK接口改造，第一步得把地基打牢。PKI这个东西，名字听着挺唬人 —— 公钥基础设施。说白了，就是一套解决“怎么在互联网上安全地证明你是谁”的体系。我在项目中见过太多人一上来就调接口、改代码，结果证书链验证都搞错了，后面debug到崩溃。
嗯，我们先不急着碰代码。先把PKI是什么、证书长什么样、CA又是干嘛的，捋清楚。这一章我尽量用大白话讲，但你放心，技术深度一点都不会少。
1.1 公钥基础设施概述
先问个问题：如果两个人从来没见过面，怎么安全地交换秘密？
你可能会说 —— 用非对称加密。对，但光有算法不够。你怎么知道你拿到的公钥，真的是对方的？万一中间被人换了怎么办？这就是PKI要解决的核心问题：密钥的生命周期管理和信任传递。
PKI不是单一的技术，而是一套完整的框架，至少包括这几个部分：
- 数字证书 —— 把公钥和身份绑定的“身份证”
- CA（证书颁发机构） —— 负责发证和作废证书的权威机构
- 证书吊销机制（CRL/OCSP） —— 用来检查证书是否还可用
- 密钥管理 —— 生成、存储、更新、销毁密钥的规范
我个人习惯把这个体系理解成一个“信任三角”：
信任三角：CA 背书 → 证书可信 → 公钥可信 → 安全通信
想想看，你在浏览器里看到小绿锁，背后就是这套体系在工作。如果没有PKI，https 根本不成立，网上银行、电子合同、代码签名全都玩不转。
下面这张图，我画了一个简化的PKI信任流。它把整个体系中各角色之间的关系串起来了，看一眼就能明白大概。
小技巧：做SDK对接时，一定要把信任链（根CA + 中间CA）完整地配进信任库。我见过有人只配了服务器证书，结果客户端验不了根，握手直接失败。
1.2 数字证书原理
数字证书就是 PKI 里的“身份证”。它把一个人的公钥和他的身份信息绑定在一块，然后由 CA 签个字，证明这个绑定是真的。
证书里到底有什么？
标准证书用的格式是 X.509 v3。我带着你看一遍核心字段：
| 字段 | 含义 | 个人提醒 |
|---|---|---|
| Subject | 证书持有人的身份（CN/O/OU 等） | 注意组织名写错了会被浏览器警告 |
| Issuer | 颁发这个证书的CA名称 | 大部分验链失败都是 Issuer 不匹配 |
| Subject Public Key Info | 证书里面绑定的公钥（算法+值） | RSA 2048 还可以，建议用 4096 或 ECC |
| Signature Algorithm | CA签名时用的哈希+算法 | SHA256WithRSA 是最常见的 |
| Validity | 生效和到期时间 | 很多线上事故都是证书过期导致的 |
| Serial Number | CA分配的唯一编号 | 吊销 CRL 时就是查这个号 |
说白了，数字证书的核心逻辑就是一句话：CA 用自己的私钥，给“公钥 + 身份”打一个不可篡改的数字签名。谁拿到这个证书，都可以用 CA 的公钥去验这个签名，确保信息没有被篡改过。
证书链是怎么工作的？
你不会直接拿根证书去签网站证书。那样效率太低，也不安全。
实际结构是 链式 的：
- 根 CA 证书 —— 自己给自己签名。叫“自签名证书”。
- 中间 CA 证书 —— 由根 CA 签发。
- 服务器/客户端证书 —— 由中间 CA 签发。
为什么这么设计？因为一旦根私钥泄露，整个体系就崩了。用中间层隔离，就算中间的私钥出了问题，还可以吊销它，根证书换一个就行。
避坑指南：我曾经在改造某个旧版SDK时，发现对方直接内置了根证书但是没带中间CA。客户端验链时找不到中间证书，连接一直报“unknown_ca”。我查了半天才定位到 —— 就是缺了一个中间证书。后来我在代码里加了自动补全中间CA的逻辑，这才跑通。
1.3 CA机构
CA，全称 Certificate Authority，证书颁发机构。它是 PKI 体系的 信任源头。
CA 的职责很清晰：
- 验证申请者的身份 —— 你申请证书时，CA 要确认你真的是那个组织或个人
- 签发证书 —— 签名并生成标准 X.509 证书
- 管理吊销列表 —— 维护 CRL 和 OCSP 服务
- 保证自身根私钥安全 —— 这是整个体系的命门
你想想看，如果 CA 自己都不靠谱，那它签的证书谁敢信？所以业界有严格的审核标准，比如 WebTrust 和 CA/B 论坛基线要求。
CA 的信任分层
我不建议你把所有业务都挂在同一个 CA 下。分层结构更灵活：
| 层级 | 角色 | 安全要求 |
|---|---|---|
| 根 CA | 离线保存，只签发中间CA | 物理隔离，多重签名保护 |
| 策略 CA | 按用途分（SSL、代码签名、个人） | 逻辑隔离，审计日志 |
| 颁发 CA | 实际给终端实体签发证书 | 联网服务，高可用 |
记住这个原则：你对接 SDK 时，根证书一旦配错，整个通信链路都会崩掉。在测试环境一定要先验证书链，不要等到线上才暴露问题。
我们经常打交道的CA类型
做 SDK 改造，你可能会碰到这么几种 CA：
- 公共 CA（如 DigiCert、GlobalSign、Let's Encrypt）—— 给互联网用，浏览器和操作系统内置了它们的根。
✅ 公开可信
❌ 有证书有效期限制（如 Let's Encrypt 90天） - 企业私有 CA（如微软AD CS、OpenCA、EJBCA）—— 公司内部用，不对外公开。
✅ 完全可控，免费用
❌ 外部设备不认，需要自己部署根证书到信任库 - 自签名证书 —— 开发调试时临时用。
✅ 随地生成
❌ 生产环境千万别用，会直接被客户端拒绝
我个人习惯是：开发测试用自签证书，预发布用私有 CA，线上正式环境一律走公共 CA。这个分层策略能最大程度减少证书问题导致的故障。
嗯，这一章的核心内容就是这些了。先说 PKI 是“信任体系”，再讲证书就是“绑定身份和公钥的凭证”，最后说 CA 就是“发证和管证的信源”。你只要把这把三个概念吃透，后面学证书链验证、OCSP 策略和 SDK 接口参数就轻松多了。