TLS/SSL 基础回顾：握手协议、证书链与 PKI
在深入 Kong 网关的证书更新与性能优化之前，必须牢固掌握 TLS/SSL 的核心机制。本章将系统回顾 TLS 1.2 与 1.3 的握手流程差异、证书链的验证逻辑以及公钥基础设施（PKI）的信任模型。这些知识是后续配置证书、诊断握手失败和优化加密性能的理论基石。
2.1 TLS 握手协议：1.2 与 1.3 对比
TLS 握手是客户端与服务器之间建立加密会话的初始协商过程。TLS 1.3 相比 1.2 在安全性和性能上均有显著提升，尤其在减少往返次数（RTT）方面。
核心差异速览： TLS 1.2 需要 2-RTT 完成握手，而 TLS 1.3 仅需 1-RTT，且支持 0-RTT 快速恢复。
2.1.1 TLS 1.2 握手流程（2-RTT）
- ClientHello： 客户端发送支持的 TLS 版本、密码套件列表、随机数。
- ServerHello + 证书： 服务器选择密码套件、发送证书链和 ServerHelloDone。
- 客户端密钥交换： 客户端验证证书，发送 Pre-Master Secret（用服务器公钥加密），双方计算会话密钥。
- ChangeCipherSpec + Finished： 客户端通知启用加密，发送 Finished 消息。
- 服务器 Finished： 服务器确认握手完成，开始加密通信。
2.1.2 TLS 1.3 握手流程（1-RTT）
- ClientHello： 客户端直接发送支持的密码套件和 Key Share（DH 公钥参数）。
- ServerHello + 证书 + 完成： 服务器选择参数，返回证书和加密的 Finished 消息，握手立即完成。
- 客户端 Finished： 客户端验证证书并发送 Finished，开始加密通信。
性能提示： TLS 1.3 将密钥协商与证书验证并行化，减少了 1 个 RTT。对于高延迟网络（如跨国访问），延迟降低效果非常明显。
2.2 证书链与验证机制
证书链（Certificate Chain）是 PKI 信任模型的核心实现。服务器发送的证书通常不是由根 CA 直接签发，而是由中间 CA 签发，形成一条从服务器证书到根证书的信任链。
2.2.1 证书链结构
| 层级 | 证书类型 | 签发者 | 作用 |
|---|---|---|---|
| 1 | 根证书 (Root CA) | 自签名 | 信任锚点，预装在操作系统或浏览器中 |
| 2 | 中间证书 (Intermediate CA) | 根 CA | 签发最终实体证书，隔离根密钥风险 |
| 3 | 服务器证书 (Leaf/Server Cert) | 中间 CA | 绑定域名与公钥，用于实际通信 |
常见配置错误： 在 Kong 或 Nginx 中仅配置服务器证书而未包含中间证书链，会导致部分客户端（如移动设备）因无法构建完整信任链而拒绝连接。
2.2.2 证书验证过程
- 构建链： 客户端从服务器证书开始，逐级向上查找签发者，直到找到本地信任的根证书。
- 签名验证： 使用父证书的公钥验证子证书的数字签名，确保证书未被篡改。
- 有效期检查： 验证每个证书的生效日期和到期日期。
- 吊销检查： 通过 CRL 或 OCSP 检查证书是否已被吊销。
- 域名匹配： 验证服务器证书的 Subject Alternative Names (SAN) 是否匹配访问的域名。
2.3 公钥基础设施（PKI）
PKI 是支撑 TLS 安全通信的完整体系，包含证书颁发机构（CA）、注册机构（RA）、证书吊销列表（CRL）和在线证书状态协议（OCSP）等组件。
2.3.1 PKI 核心组件
| 组件 | 职责 | 在 Kong 场景中的关联 |
|---|---|---|
| CA (证书颁发机构) | 签发、吊销证书 | 选择受信任的 CA 购买或签发证书 |
| RA (注册机构) | 验证申请者身份 | 证书申请时的域名验证流程 |
| CRL (证书吊销列表) | 发布已吊销证书序列号 | Kong 可配置 CRL 检查策略 |
| OCSP (在线证书状态协议) | 实时查询证书状态 | OCSP Stapling 可提升握手性能 |
| HSM (硬件安全模块) | 安全存储私钥 | 企业级 Kong 部署可集成 HSM |
2.3.2 密钥对与证书生命周期
- 密钥对生成： 服务器生成 RSA（2048/4096 位）或 ECDSA（P-256/P-384）密钥对。
- CSR 提交： 将公钥和域名信息封装为证书签名请求（CSR）提交给 CA。
- 证书签发： CA 验证身份后，使用其私钥签发证书。
- 证书部署： 将证书和私钥配置到 Kong 网关。
- 证书更新： 在到期前重新生成密钥对并替换旧证书。
- 证书吊销： 私钥泄露或域名变更时立即吊销。
Kong 运维要点： 证书更新窗口期应至少提前 30 天。使用 ECDSA 证书可减少握手计算开销，配合 TLS 1.3 可获得最佳性能。
2.4 密码套件与算法选择
密码套件定义了握手过程中使用的密钥交换、身份验证、加密和消息认证码（MAC）算法组合。TLS 1.3 简化了密码套件结构，移除了不安全算法。
| 协议版本 | 推荐密码套件 | 密钥交换 | 性能特征 |
|---|---|---|---|
| TLS 1.2 | ECDHE-RSA-AES128-GCM-SHA256 |
ECDHE + RSA | 前向安全，兼容性好 |
| TLS 1.3 | TLS_AES_128_GCM_SHA256 |
ECDHE (隐式) | 更少 RTT，更优性能 |
| TLS 1.3 | TLS_CHACHA20_POLY1305_SHA256 |
ECDHE (隐式) | 移动端性能更佳 |
优化建议： 在 Kong 中优先启用 TLS 1.3 并配置
ssl_ciphers 仅包含 AEAD 套件。对于高并发场景，ECDHE 密钥交换的计算开销低于传统 RSA 密钥交换。
2.5 本章小结
- TLS 1.3 通过 1-RTT 握手和 0-RTT 恢复显著降低延迟，是 Kong 网关的首选协议。
- 证书链必须完整配置，包含服务器证书和所有中间证书，否则客户端验证会失败。
- PKI 信任模型依赖根证书作为锚点，运维中需关注证书有效期和吊销状态。
- 密码套件选择应优先考虑前向安全（ECDHE）和 AEAD 加密模式。