2、TLS握手流程与证书验证机制归纳总结
说实话，TLS 握手这件事，我前前后后排查过不下几十次。有的项目上线前握手正常，一上生产就报错，证书链断了，或者客户端压根不信任服务器。嗯，今天咱们就把这块彻底捋清楚。
2.1 握手流程概览
TLS 握手不是一次简单的“你好我好”，它得完成三件大事：身份验证、密钥协商、对称密钥生成。我画了张图，方便你一眼看明白整体流程。
这张图里我把握手拆成了 8 步，但实际报文交互只有 4 条。为什么这么画？因为客户端和服务端内部还要做不少事情。你想想看，如果中间有一步证书没通过，后面全白搭。
2.2 握手关键步骤详解
咱们挑几个容易踩坑的步骤重点说说。
2.2.1 ClientHello 与 ServerHello
客户端带着支持的加密套件列表（cipher suites）、TLS 版本、随机数（Client Random）打招呼。服务端从中挑一个自己也能支持的，再发回 Server Random 和选中的套件。
- 注意：如果客户端只能 TLS 1.2，服务端只开 TLS 1.3，握手直接失败。我去年遇到过一个客户，nginx 配了
ssl_protocols TLSv1.3;，但浏览器只支持 1.2，最后把老用户全挡住了。 - 加密套件的顺序也重要。服务端一般选自己列表里的第一个能匹配的。所以建议把强安全套件放前面。
2.2.2 证书下发与验证
服务端发完 ServerHello 后，紧跟着发 Certificate 消息，里面就是一串证书链（服务端证书 → 中间CA → 根CA）。客户端收到后要干这几件事：
- 证书链完整性：逐级签名验证，直到信任的根CA。
- 域名匹配：检查证书中的 CN 或 SAN 是否匹配你访问的域名。
- 有效期：证书是否在有效期内。
- 吊销状态：通过 CRL 或 OCSP 确认证书未被吊销。
⚠️ 常见坑：我曾经遇到一个项目，服务端只发了叶子证书，没带中间CA。客户端本地没有那个中间CA，验证链直接断掉。结果就是所有新设备连不上，旧设备因为缓存了中间CA反而能连——这种“间歇性故障”最难排查。
2.2.3 密钥协商与 Finished 校验
ClientKeyExchange 里客户端用服务器的公钥加密一个预主密钥（pre-master secret）发回去。双方用各自的随机数和预主密钥算出相同的会话密钥。最后互发 Finished 消息（包含之前所有握手消息的 MAC），确保没被篡改。
💡 我的经验：如果握手到“Finished”步骤失败，多半是密钥计算过程不一致。检查一下双方 PRF 算法是否一致，或者随机数是否有截断。用 Wireshark 看“Client Finished”和“Server Finished”里的 verify_data 就能定位。
2.3 证书验证机制归纳
证书验证是整个握手的安全基石。我整理了一个表格，把验证项和攻击场景对应起来，方便你自查。
| 验证项 | 检测内容 | 如果失效会导致什么？ |
|---|---|---|
| 证书链 | 每个中间CA的签名必须合法，直到根CA | 攻击者可伪造任意证书 |
| 域名匹配 | 证书 CN/SAN 包含访问的域名 | 中间人用颁发的假证冒充目标 |
| 有效期 | 当前时间在 notBefore ~ notAfter | 过期证书被重放或被盗用 |
| 吊销状态 | CRL/OCSP 显示证书未被吊销 | 已泄露的私钥仍被信任 |
| 基本约束 | CA:TRUE 标识正确，路径长度限制不超 | 可构造非法 CA 签发无限信任链 |
| 密钥用法 | 数字签名、密钥加密等位必须合理 | 将客户端证书误当服务器证书使用 |
🔍 重点关注吊销状态：很多生产环境图省事，关闭了 OCSP Stapling 或者 CRL 下载配置。一旦私钥泄露，攻击者还能使用旧证书握手。我自己就处理过一起事故：某公司的支付证书吊销了，但他们的 Nginx 没开 OCSP 验证，结果攻击者利用旧证书成功中间人窃取了半年的交易数据。
2.4 常见配置错误与避坑指南
说几个我实际踩过的坑，希望你不用再走一遍。
- 证书链不完整：很多运维直接从 CA 下载一个 `.crt` 文件就配上了，不知道还得把中间CA 拼接进去。正确做法是把服务器证书、中间CA 按顺序合并到一个文件里。
- 密码套件顺序错误：比如把 `TLS_AES_128_GCM_SHA256` 放在 `TLS_CHACHA20_POLY1305_SHA256` 后面，导致某些老客户端协商出弱加密。我的习惯：优先用 AEAD 套件，把 GCM 和 ChaCha20 放前面。
- 忽略 SNI：一个 IP 上托管多个 HTTPS 站点时，必须配 SNI。否则客户端连过来时服务端不知道发哪个证书。我见过有人把所有证书配到同一个 default 里，结果域名一律返回第一个证书，浏览器疯狂警告。
- OCSP 响应超时：默认的 OCSP 查询是同步的，如果 CA 的响应服务器挂了，握手会卡住好几秒。解决办法是启用 OCSP Stapling，让服务端自己缓存并推送状态。
📌 我用的小工具：每次改完 TLS 配置，我都会用 openssl s_client -connect host:port -showcerts 命令行模拟完整握手，看证书链是否完整、验证是否通过。再加一个 -tlsextdebug 能看到 SNI 扩展有没有正确发送。
# 示例：验证 github.com 的握手（输出太多，只截取关键部分）
$ openssl s_client -connect github.com:443 -showcerts
CONNECTED(00000005)
depth=2 CN = DigiCert Global Root CA
verify error:num=0
---
Certificate chain
0 s:CN = github.com
i:CN = DigiCert TLS RSA SHA256 2020 CA1
1 s:CN = DigiCert TLS RSA SHA256 2020 CA1
i:CN = DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
看到 verify error:num=0 就表示证书链验证通过。如果出现 num=20 或 num=21，那就得去查证书链或域名问题了。
好了，这一章关于握手流程和证书验证的核心点就这些。记住，证书验证是“一票否决制”——任何一项没通过，握手直接中断。配置时多花十分钟检查证书链，能省掉后面十小时的排障时间。