TLS/SSL 基础：握手协议、加密套件与证书
说实话，刚开始接触 mTLS 那会儿，我也觉得这东西神秘兮兮的。但说白了，它就是给普通的 HTTP 通信套上了一层加密和身份验证的外壳。而理解这层外壳，得从 TLS/SSL 的三大支柱说起：握手协议、加密套件、证书。
我自己带过不少团队，发现很多人卡在证书配置上，根本原因就是没搞懂握手时到底发生了什么。大家别急，咱们一步步来拆解。
TLS 握手协议：一次安全的碰面
想像一下你要和一个人交换机密文件。你不能直接把文件扔过去吧？你得先互相确认身份，再商量好用什么暗号加密。TLS 握手就是干这事的。
一次完整的 TLS 1.2 握手，通常会经历这么几个来回：
- ClientHello：客户端打招呼，告诉服务器：“我支持这些加密套件，这是我的随机数。”
- ServerHello：服务器回复：“我们就用这个套件，这是我的随机数和证书。”
- 证书验证：客户端检查服务器证书是否合法、有效。
- 密钥交换：双方用非对称加密交换一个预主密钥，然后各自算出会话密钥。
- Finished：双方都说一句“我准备开始加密通信了”，握手结束。
我记得有一次调试一个生产环境问题，客户端死活连不上服务器，查了半天才发现是握手超时。原因很蠢——证书链没配全，客户端在验证证书时卡住了。嗯，这事后面会细说。
加密套件：通信双方的语言约定
加密套件，你可以把它理解为一套完整的加密“配方”。它决定了：
- 密钥交换算法：比如 ECDHE、RSA。
- 身份验证算法：比如 ECDSA、RSA。
- 对称加密算法：比如 AES_128_GCM、CHACHA20_POLY1305。
- 消息认证码算法：比如 SHA256、POLY1305。
一个典型的加密套件长这样：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。前半段是握手用的，后半段是加密通信用的。
说到这个，我想起之前有个同事，为了“极致性能”，把加密套件全换成了强度很低的。结果安全审计没过，还被批评了。所以我的建议是：别自己瞎改套件，用系统推荐的就行。
下面这个表格，我列出了几种常见的套件对比：
| 套件名称 | 密钥交换 | 认证 | 加密 | 完整性 | 安全级别 |
|---|---|---|---|---|---|
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDHE | RSA | AES-128-GCM | SHA256 | 高 |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ECDHE | ECDSA | AES-256-GCM | SHA384 | 极高 |
| TLS_RSA_WITH_AES_128_CBC_SHA | RSA | RSA | AES-128-CBC | SHA1 | 低（已过时） |
大家注意，TLS_RSA_WITH_AES_128_CBC_SHA 这种老套件，已经不建议用了。没有前向安全性，SHA1 也不安全。我曾经接手过一个遗留系统，里面全是这种老套件，费了好大劲才迁移掉。
证书的作用：身份的“身份证”
证书是 TLS 握手的信任基石。如果没有证书，你无法确认对面那个“服务器”到底是不是真的。
X.509 证书，本质上就是一个数字化的身份证。它包含：
- 版本号：通常 V3。
- 序列号：每个证书唯一。
- 签名算法：比如 sha256WithRSAEncryption。
- 颁发者：谁签发了这个证书。
- 有效期：起止时间。
- 主体：证书的持有者，比如域名。
- 公钥：持有者的公钥。
- 签名：颁发者的数字签名，用来防篡改。
为什么说证书链重要？你想想看，如果每个证书都要手动去信任，那互联网不就乱套了？所以有了 CA（证书颁发机构）和证书链。你的服务器证书，由中间 CA 签发；中间 CA 的证书，由根 CA 签发。只要你的设备信任根 CA，那就自动信任了整条链上的证书。
这就像你认识张三，张三说他认识李四，李四说他认识王五。你信任张三，所以间接信任了王五。
在 mTLS 里，服务器要出示证书，客户端也要出示证书。这叫做“双向认证”。这就是为什么我们这门课叫“自签名证书在 mTLS 中的使用”。
知识体系结构图
为了让大家更直观地理解本章的知识结构，我画了一张图。它展示了 TLS/SSL 的三大核心板块，以及它们之间的关系。
理解了这张图，整个 TLS 的脉络就清楚了。下次配置证书的时候，你至少能明白：我现在配的东西，在握手流程里扮演了什么角色。