1. PKI 基础与证书概念：公钥基础设施原理、数字证书结构（X.509 v3）、证书链与信任模型
各位好，我是老周。今天咱们开始第一讲，聊聊 PKI 和数字证书那些最基础的东西。说实话，我见过不少工程师，证书用得很溜，但一问到根证书怎么来的、证书链怎么验证的，就卡壳了。嗯，这章咱们就把这些底层的概念彻底捋清楚。
1.1 公钥基础设施（PKI）到底是个啥？
PKI，全称 Public Key Infrastructure，中文叫公钥基础设施。说白了，它就是一套用来管理密钥和证书的规则、流程、软硬件的集合。你想想看，互联网上两个陌生人要安全通信，怎么确认对方身份？怎么保证数据不被篡改？PKI 就是干这个的。
我个人习惯把 PKI 拆成三个核心组件：
- 证书颁发机构（CA）——负责签发和管理证书的权威机构。它是整个信任体系的起点。
- 注册机构（RA）——负责验证申请者身份的中间层。CA 可以自己干 RA 的活，也可以委托给 RA。
- 证书存储库——通常就是 LDAP 目录或 Web 服务器，用来发布证书和证书吊销列表（CRL）。
核心要点：PKI 不是单一技术，而是一套完整的信任基础设施。没有 PKI，HTTPS、代码签名、电子合同这些应用全都玩不转。
我在项目中遇到过一家企业，自己搭了内部 PKI，结果 CA 私钥保护没做好，被运维人员直接拷贝走了。嗯，那场面……整个内部证书体系都得重建。所以，PKI 里最值钱的不是证书本身，而是 CA 的私钥。
1.2 数字证书结构（X.509 v3）
数字证书，说白了就是一张「电子身份证」。目前最通用的标准是 X.509 v3，几乎所有 HTTPS 证书都遵循这个格式。我刚开始接触证书时，总觉得 ASN.1 语法很吓人，其实你只要抓住几个关键字段就够了。
一个标准的 X.509 v3 证书包含以下主要部分：
| 字段 | 说明 | 我的经验 |
|---|---|---|
| 版本号 | 目前主流是 v3（值为 2） | v1 和 v2 基本绝迹了，别用 |
| 序列号 | CA 分配给证书的唯一编号 | 吊销时就是靠这个找证书 |
| 签名算法 | CA 签名用的算法，如 SHA256-RSA | 别再用 SHA1 了，不安全 |
| 颁发者 | 签发该证书的 CA 名称（DN） | 链式验证时逐级比对 |
| 有效期 | notBefore 和 notAfter | 我见过证书过期导致全线瘫痪的事故 |
| 主体 | 证书持有者的名称（DN） | 对于 SSL 证书，就是域名 |
| 公钥 | 持有者的公钥信息 | 算法+密钥长度，2048 位起步 |
| 扩展 | v3 新增的灵活区域 | 这才是 v3 的精髓，下面细说 |
小技巧：用 OpenSSL 查看证书内容时，openssl x509 -in cert.pem -text -noout 这个命令我几乎每天都会敲一遍。你可以试试看，所有字段一目了然。
1.2.1 X.509 v3 扩展——真正拉开差距的地方
v3 扩展让证书不再只是「公钥+身份」那么简单。我挑几个最常用的说说：
- 基本约束（Basic Constraints）——标记这个证书是不是 CA 证书。如果 CA 证书里没设这个扩展，浏览器会报错。
- 密钥用法（Key Usage）——规定公钥能干啥。比如 digitalSignature 用于签名，keyEncipherment 用于加密。
- 扩展密钥用法（Extended Key Usage）——更细粒度的限制。比如 serverAuth 表示只能用于服务器身份验证。
- 主体备用名称（Subject Alternative Name, SAN）——这才是现代 HTTPS 证书的核心。一个证书可以保护多个域名。
避坑指南：我曾经遇到一个案例，代码签名证书的 EKU 只设了 codeSigning，结果客户想用它做 SSL 服务器认证，直接失败。扩展用错了，证书就是废纸一张。
1.3 证书链与信任模型
证书链，也叫信任链。你想想看，浏览器里预装了上百个根证书，但你的网站证书肯定不是根 CA 直接签的，中间可能隔了一级甚至两级中间 CA。这个从「你的证书」到「根证书」的链条，就是证书链。
我画了一张图，帮你理解证书链的结构：
为什么会这样设计？直接让根 CA 签所有证书不行吗？嗯，这里有两个原因：
- 安全隔离——根 CA 的私钥通常离线保存，甚至放在保险柜里。如果根 CA 被攻破，整个信任体系就完了。中间 CA 可以在线操作，即使被攻破，吊销它一个就行。
- 运营灵活性——不同业务线可以用不同的中间 CA，方便管理。我在一家金融机构见过，交易签名和内部认证用了不同的中间 CA，互不影响。
1.3.1 三种信任模型
信任模型决定了「谁可以信任谁」。常见的就三种：
| 模型 | 特点 | 适用场景 |
|---|---|---|
| 层次模型 | 单一根 CA，向下签发中间 CA，再签发终端证书 | 公共 PKI（如 SSL/TLS） |
| 网状模型 | 多个 CA 互相交叉认证 | 大型企业内部 PKI |
| 桥接模型 | 通过一个桥 CA 连接多个独立的 PKI 域 | 跨组织信任联合 |
我的建议：对于大多数企业，层次模型就够了。网状模型虽然灵活，但证书路径复杂，验证起来很头疼。我曾经帮一个客户从网状模型迁移到层次模型，光是清理交叉证书就花了两个月。
1.4 证书验证流程——浏览器到底在干啥？
当你访问一个 HTTPS 网站时，浏览器背后做了这么几件事：
- 获取证书链——服务器在 TLS 握手时会把证书链发过来。
- 检查有效期——当前时间必须在 notBefore 和 notAfter 之间。
- 检查吊销状态——通过 CRL 或 OCSP 确认证书没有被吊销。
- 验证签名链——从服务器证书开始，逐级用上一级证书的公钥验证签名，直到信任的根证书。
- 检查域名匹配——访问的域名必须在 SAN 或 CN 中。
这五步，一步都不能少。我见过一个案例，某公司自签证书忘了设 SAN 扩展，结果 Chrome 直接报 NET::ERR_CERT_COMMON_NAME_INVALID。嗯，Chrome 从 2017 年起就不再信任 CN 匹配了，必须用 SAN。
调试利器：用 openssl s_client -connect example.com:443 -showcerts 可以完整看到服务器发来的证书链。我排查证书问题时，这个命令是首选。
1.5 本章小结
这一章我们覆盖了 PKI 的核心概念、X.509 v3 证书的结构、证书链的层级关系以及三种信任模型。这些东西看起来理论性很强，但后面每一章都会用到。尤其是证书链的概念，理解不透的话，后面讲证书注入和吊销时你会很痛苦。
我个人建议，学完这章后，找个真实的 HTTPS 证书，用 OpenSSL 拆开看看每个字段。纸上得来终觉浅，亲手操作一遍比看十遍都管用。