TLS 1.3 握手全流程与证书链排障：从 ClientHello 到会话复用

前面几篇我们把 DNS 解析、DHCP 拿地址、IP 选路都讲了一遍——这些都发生在「找到对方」的阶段。但从客户端点下回车到收到第一个字节，中间还夹着一段几乎没人细看的过程：TLS 握手。它决定了这次连接能不能建立、要花几个往返、以及你是不是「看起来安全但实际可被中间人替换」。

一、TLS 1.3 一次握手：一个往返就够

TLS 1.2 完整握手需要 两个往返（2-RTT），1.3 把它压到了 1-RTT，会话复用场景甚至能做到 0-RTT。压缩的关键在于：1.3 让客户端在第一条消息里就把「密钥交换的素材」一起送来，服务器不必再单独回一次。逐帧看是这样：

两点值得注意：

• 大括号表示"已加密"。从 ServerHello 之后的消息就全部被握手密钥保护了——包括服务器证书。这是 1.3 与 1.2 的一个显著差异：在 1.2 里证书是明文传输的，中间人可以观察到你在访问哪个站点用的哪张证书（当然看不到内容）。
• SNI 仍然是明文。因为服务器在拿到 ClientHello 时必须先知道「你要访问哪个域名」才能决定发哪张证书，所以 SNI 在 1.3 里依然是明文（除非启用 ECH）。这是「HTTPS 也泄露访问目标」的技术根源。

1.2 与 1.3 的差异对照

二、证书链验证：四个检查点，缺一不可

浏览器判断「这张证书可信」并不是看它本身，而是沿着一条信任链往上走，最终落到操作系统/浏览器内置的一个根证书上。这条链上的每一环都要通过四个检查：

实践中最常出问题的不是「证书错了」，而是链不完整：服务器只发了自己的证书，没发中间 CA 证书，于是浏览器无法把链接到根上。

# 只看服务器发了什么链（-showcerts 打印全部）
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -E "^(subject|issuer|Verify)"

# 证书链是否完整（返回 0 表示链完整可信）
openssl s_client -connect example.com:443 -servername example.com -verify_return_error </dev/null 2>&1 | grep -E "Verify return code"

证书类型速查

三、SNI 与 ALPN：握手阶段就决定了「给哪个网站、说哪种话」

这两个扩展都不涉及加密，却是虚拟主机与 HTTP/2 能否工作的开关。

• SNI（Server Name Indication）：客户端在 ClientHello 里明说「我要访问 a.com」。服务器据此选择对应的证书与虚拟主机。没有 SNI，一台 IP 上就只能放一张证书——这也是早年 HTTPS 部署成本高的原因。
• ALPN（Application-Layer Protocol Negotiation）：客户端列出 h2, http/1.1，服务器选定一个。这是现代 HTTP/2 启用的唯一正确途径——它把协议协商放在握手内部完成，省掉了额外的往返（对比 HTTP/1.1 的 Upgrade 头机制，那要一整轮往返才能升级）。

# 看 ALPN 是否协商到 h2
openssl s_client -connect example.com:443 -servername example.com -alpn h2,http/1.1 2>/dev/null | grep -i "ALPN"

# 指定 TLS 版本与套件排查（模拟老客户端）
openssl s_client -connect example.com:443 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256

四、OCSP Stapling：让证书吊销检查不再拖慢握手

验证证书是否被吊销，最原始的做法是客户端自己去问 CA 的 OCSP 服务器。问题有两个：多一次网络往返（握手变慢），而且等于把你的访问目标暴露给 CA（隐私问题）。

OCSP Stapling 的思路很聪明：让服务器自己去问 CA 拿一份带时间戳、由 CA 签名的吊销状态声明，然后在握手时一并捎给客户端。客户端不必外访，延迟和隐私问题同时解决。

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/chain.pem;   # 通常是「根 + 中间」证书
resolver 223.5.5.5 119.29.29.29 valid=300s;         # 必须配 resolver，否则无法取 OCSP
resolver_timeout 5s;

排障时经常遇到「配了 stapling 但没生效」，最可能的原因就是漏配 resolver——Nginx 需要自己解析 OCSP 服务器域名。用 openssl s_client ... -status 可以直接看到服务器有没有捎带 OCSP 响应。

五、会话复用：为什么第二次握手快得多

完整握手有非对称运算（签名验证、密钥交换），成本远高于对称加密。用户连续访问同一站点时，每次都做完整握手是巨大浪费。两种复用机制：

ssl_session_cache shared:SSL:10m;   # 10m 大约可存 4 万个会话
ssl_session_timeout 1d;
ssl_session_tickets on;

TLS 1.3 里去掉了 Session ID，统一用 PSK（预共享密钥） 模式：客户端在 ClientHello 里带上 pre_shared_key 扩展，服务器若能接受，直接在同一往返里完成握手，这就是 0-RTT。

六、排障手册：从报错反推到配置

1. 一套通用诊断命令

# ① 握手是否成功、用的哪个版本和套件
openssl s_client -connect example.com:443 -servername example.com </dev/null | head -20

# ② 只看证书链与有效期
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# ③ 逐级看链上每张证书（谁签的谁）
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -E "^ *[0-9]+ s:|^ *i:"

# ④ 模拟不支持 SNI 的老客户端，看默认站点返回什么证书
openssl s_client -connect example.com:443 </dev/null 2>&1 | grep "subject="

# ⑤ 在本机校验证书链是否完整
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt chain.pem

2. 常见报错与根因对照

3. 一份可直接用的现代 TLS 配置

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;            # TLS1.3 由客户端选更合适
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305;

ssl_certificate     /etc/nginx/ssl/fullchain.pem;   # 必须含中间证书
ssl_certificate_key /etc/nginx/ssl/privkey.pem;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;                  # 多机部署时需共享 ticket key，否则建议关

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
resolver 223.5.5.5 119.29.29.29 valid=300s;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;