HTTPS 握手到底做了什么：对称、非对称与哈希的分工

三种技术的分工

握手（TLS 1.3）大致流程

1. 客户端发送 ClientHello：支持的版本、密码套件、随机数；
2. 服务端返回 ServerHello 与证书（内含公钥）；
3. 客户端验证证书链：是否由受信任 CA 签发、域名是否匹配、是否在有效期内；
4. 双方通过 ECDHE 交换临时密钥材料，各自独立算出同一把会话密钥；
5. 此后所有数据都用对称密钥加密，并附带认证标签。

整个过程通常在几十到一百多毫秒内完成。TLS 1.3 还支持 0-RTT 或会话恢复，让回访连接几乎无感。

为什么是“混合”，不全用非对称

非对称算法慢几个数量级，而且 RSA 无法加密超过模组长度的数据。所以它只承担“安全地得到一把对称密钥”这一步，剩下的大批量数据交给 AES——这就是混合加密，也是实际所有安全通信的通用套路。

证书链是什么

信任是链式的：站点证书 → 中间 CA 证书 → 根 CA 证书（预置在系统或浏览器中）。链条上任意一环缺失、过期或域名不匹配，浏览器就会报错。自签证书之所以“不受信任”，是因为根证书不在信任库里，需要手动导入。

实战排查：三个证书/握手问题

1. “NET::ERR_CERT_DATE_INVALID”：证书过期或系统时间不对。修复：检查服务器时间并配置自动续期（ACME），别手动一年一签。
2. “域名不匹配（certificate name mismatch）”：证书的 SAN 未覆盖该子域。修复：签发时把所有需要的域名写进 SAN，或使用通配符证书。
3. “中间证书缺失导致部分客户端失败”：服务器没下发完整证书链，浏览器能补、命令行工具常报错。修复：配置完整链（fullchain）。

常见问题

HTTPS 能隐藏访问的域名吗？TLS 1.3 加密了大部分握手信息，但 DNS 查询仍可能暴露目标域名；需要更强隐私要配合 DoH/DoT 与 ECH。有 HTTPS 就安全吗？它保证传输过程不可窃听、不可篡改，不代表站点本身可信——钓鱼站同样能申请证书。证书过期怎么办？用 ACME（Let's Encrypt 等）自动签发与续期，避免人工遗漏。

三个排查命令

# 查看证书链、有效期与签发者
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

# 查看协商出的协议版本与证书校验结果
curl -sS -o /dev/null -w '%{http_version} verify=%{ssl_verify_result}
' https://example.com/

# 仅用于定位问题（不要用于生产判断）：跳过证书校验
curl -kI https://example.com/

常见故障速查

• 证书链不完整：缺少中间证书时，部分浏览器会提示不受信；
• 主机名不匹配：证书签给 www 而访问的是根域，或反过来；
• 本机时间错误：会导致「证书尚未生效 / 已过期」的误报；
• SNI 配置问题：同一 IP 托管多域名时，未正确返回对应证书会导致握手失败。

动手试试：哈希计算、对称加密

TLS 1.3 与 1.2 的握手差异

• 往返次数：1.3 只需 1 个 RTT 即可完成握手（1.2 需 2 个），会话复用时可做到 0-RTT；
• 密钥交换：1.3 移除了 RSA 密钥交换，只保留（EC）DHE，天然具备前向保密；
• 加密范围更大：1.3 把证书也纳入加密，中间设备更难窥探，也因此更依赖 SNI 做分流；
• 升级建议：优先启用 TLS 1.3 并保留 1.2 兼容旧客户端，明确禁用 1.0/1.1。

0-RTT 的代价

会话恢复时的 0-RTT 能省掉一个往返，但早期数据不具前向保密，且存在被重放的风险。因此只应对幂等的只读请求使用 0-RTT，写操作与支付类请求务必等到握手完成后再发送。

SNI 与证书选择

同一 IP 上托管多个域名时，服务端依靠 SNI 选择证书。若客户端过旧不支持 SNI，只能拿到默认证书，从而出现证书不匹配。多域名部署应确保默认证书可用，并在日志中关注 SNI 缺失的比例，必要时为这部分流量单独处理。