密码学基础回顾：对称加密与非对称加密、数字证书与CA、X.509证书结构、公钥基础设施(PKI)概念
聊 mTLS 之前，咱们得先把密码学这块地基夯实了。说实话，我见过太多团队在配置双向认证时出问题，根子都在于对底层概念一知半解。你想想看，连证书里到底装了啥都不清楚，出了问题怎么排查？
这一章咱们就快速过一遍核心概念。别担心，我不会扔一堆数学公式给你。咱们用工程师的视角，把对称加密、非对称加密、CA、X.509 和 PKI 这五样东西串起来讲。
对称加密 vs 非对称加密：一个快，一个安全
先说对称加密。说白了，就是加密和解密用同一把钥匙。你拿钥匙锁门，拿同一把钥匙开门。典型算法有 AES、DES、3DES。
它的优点就一个字：快。我在做高性能网关项目时，大量数据都是用 AES-256 加密的，硬件加速下几乎零延迟。但缺点也很致命——密钥分发问题。你怎么把钥匙安全地交给对方？如果通过网络传，万一被截获，加密就形同虚设。
非对称加密就不一样了。它有一对钥匙：公钥和私钥。公钥可以公开给任何人，私钥只有自己知道。你用我的公钥加密数据，只有我能用私钥解密。反过来，我用私钥签名，你用公钥验签，就能确认消息确实是我发的。
RSA 和 ECC 是主流算法。ECC 在同等安全强度下密钥更短，我最近几年更偏爱它。但非对称加密有个硬伤——慢。比对称加密慢几百倍甚至上千倍。
实际工程怎么选？
我习惯的做法是：用非对称加密协商一个临时对称密钥，然后用对称加密加密后续所有数据。这就是 TLS 握手的核心逻辑。既解决了密钥分发问题，又保证了性能。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个（共享密钥） | 2 个（公钥 + 私钥） |
| 速度 | 快（硬件加速可达 Gbps） | 慢（RSA 2048 签名约 1ms） |
| 密钥分发 | 困难（需要安全通道） | 容易（公钥可公开） |
| 典型算法 | AES, ChaCha20 | RSA, ECDSA, Ed25519 |
| 主要用途 | 批量数据加密 | 密钥交换、数字签名 |
数字证书与 CA：谁来证明“你是谁”？
好，现在你有了公钥，你把它扔到网上说「这是我的公钥」。我怎么知道这公钥真的是你的？万一中间人把他的公钥换上去呢？
这就是数字证书要解决的问题。证书本质上是一张「数字身份证」，里面绑定了你的身份信息和你的公钥。谁来担保这张证是真的？CA（Certificate Authority，证书颁发机构）。
CA 是个可信的第三方。它用自己的私钥给你的证书签名。任何人拿到你的证书，只要用 CA 的公钥验签通过，就能确认：证书内容没被篡改，公钥确实属于你。
我曾经帮一家金融科技公司排查过问题。他们的服务端证书是自己用 OpenSSL 签的，但客户端没把自签 CA 证书加到信任库。结果 TLS 握手一直报错，折腾了两天。说白了，就是「你信我，但你凭什么信我」这个链条断了。
避坑指南：我曾经在测试环境图省事，直接用自签名证书。结果上线前忘了换成 CA 签发的证书，QA 环境一切正常，生产环境死活连不上。后来我养成了习惯：测试环境用自建 CA，生产环境一律用公共 CA 或企业内部 CA。环境隔离要彻底。
X.509 证书结构：一张证书里到底装了啥？
现在咱们把证书拆开看看。X.509 是国际标准，定义了证书的格式。你平时看到的 .crt、.pem、.der 文件，底层都是 X.509 结构。
一个典型的 X.509 v3 证书包含以下字段：
- 版本号：目前主流是 v3（值为 2）
- 序列号：CA 分配的唯一编号，用于吊销时识别
- 签名算法：CA 签名时用的算法，比如 sha256WithRSAEncryption
- 颁发者：签发该证书的 CA 名称（DN）
- 有效期：notBefore 和 notAfter，证书生效和过期时间
- 主体：证书持有者的名称（DN），比如 CN=example.com
- 主体公钥信息：持有者的公钥和算法
- 扩展：v3 新增的灵活区域，比如密钥用途、SAN（主题备用名称）、CA 标志等
- 签名：CA 用私钥对整个证书内容的签名
这里我特别想强调一下 SAN（Subject Alternative Name）。以前证书靠 CN 字段匹配域名，但 RFC 2818 已经明确废弃这种做法了。现在浏览器和 mTLS 客户端都只认 SAN。我见过有人生成证书时只填了 CN，结果 Chrome 直接报安全错误。
注意：生成证书时，务必把域名或 IP 加到 SAN 里。CN 字段现在基本只做展示用。如果你用 OpenSSL 命令行生成证书，记得在配置文件中加上 subjectAltName 项。
公钥基础设施（PKI）：把信任链串起来
单个 CA 签发的证书好理解。但现实世界是分层的。你想想，如果全球只有一个 CA，它被攻破了怎么办？所以 PKI 引入了证书链的概念。
PKI 的核心组件包括：
- 根 CA：信任的锚点，自签名证书。它的公钥被预装在操作系统或浏览器里。
- 中间 CA：由根 CA 签发，用于签发终端实体证书。这样即使中间 CA 出问题，根 CA 还能撤销它，不用重新分发根证书。
- 终端实体证书：最终给服务器或客户端用的证书。
- CRL / OCSP：证书吊销机制。CRL 是黑名单列表，OCSP 是在线查询状态。
验证过程是自底向上的：从终端证书开始，逐级验证上一级证书的签名，直到信任的根证书。这就是信任链。
下面这张图展示了典型的 PKI 信任链结构：
在 mTLS 场景下，服务端和客户端各自持有自己的证书和私钥。握手时，双方互相出示证书，并验证对方的证书是否在信任链上。这就是「双向」认证的由来。
我的经验：搭建内部 PKI 时，我建议至少分三级：根 CA 离线存储，中间 CA 用于日常签发，终端证书按用途分类（服务器、客户端、管理员）。这样即使中间 CA 私钥泄露，只需要吊销它并重新签发下级证书，根 CA 纹丝不动。
小结一下
这一章咱们把密码学基础过了一遍。对称加密快但密钥分发难，非对称加密解决了分发问题但慢，两者结合就是 TLS 的基石。数字证书绑定了身份和公钥，CA 负责担保。X.509 定义了证书的标准化结构，PKI 则把信任链组织成可管理的体系。