2. mTLS身份认证原理回顾
mTLS（mutual TLS）并不是一套全新的协议，而是在标准 TLS 之上把“服务器单向出示证书”扩展为“双方各自出示证书并互相验证”。要理解它在 PQC 迁移中的位置，必须先回到 TLS 握手本身：证书在哪里出现、验证发生在哪一步、SNI 如何影响证书选择、会话恢复又绕过了哪些环节。只有把这些环节拆清楚，才能判断哪些部分会被后量子算法替换、哪些部分需要额外改造。
一、TLS 握手流程与证书出现的位置
以 TLS 1.3 为例，一次完整握手大致经历：客户端发送 ClientHello（含支持的密码套件、密钥共享、SNI 扩展）→ 服务器回复 ServerHello 并选择参数 → 服务器发送 EncryptedExtensions、Certificate、CertificateVerify、Finished → 客户端验证服务器证书链与签名，发送自己的 Certificate、CertificateVerify、Finished → 双方基于握手流量导出会话密钥。TLS 1.2 的次序略有不同，但证书交换与验证的语义一致。
关键点在于：证书本身不参与密钥协商，它只用于证明“持有私钥的一方确实是证书主体”。真正的密钥来自 ECDHE 等密钥交换，证书里的公钥用于验证 CertificateVerify 中的签名。因此 PQC 迁移会同时触及两条线：密钥交换（如 X25519 换成 ML-KEM）和签名/证书（如 ECDSA/RSA 换成 ML-DSA 或 SLH-DSA）。
二、双向证书验证：谁验谁、验什么
mTLS 中，服务器在握手时通过 CertificateRequest 明确要求客户端出示证书。客户端证书通常由企业内部 CA 签发，服务器用该 CA 的根证书或中间证书构建信任锚进行验证。验证内容至少包括：
- 证书链能否从终端证书逐级构建到受信任根；
- 每一级签名是否有效、算法是否被策略允许；
- 有效期、BasicConstraints、KeyUsage、ExtendedKeyUsage（serverAuth / clientAuth）是否符合用途；
- 主体名称或 SAN 是否与预期身份匹配；
- 是否被 CRL / OCSP 吊销。
任何一项失败，握手都会以 alert 终止。工程上最常见的失败不是“证书伪造”，而是链不完整、EKU 不匹配、时间偏差或吊销状态不可达。
三、证书链与信任锚
证书链是“终端证书 ← 中间 CA ← 根 CA”的签名关系。服务器通常只发送终端证书和中间证书，根证书由客户端本地信任库持有。mTLS 场景下，客户端证书链同样需要被服务器信任库覆盖。若企业使用私有 CA，必须把根证书预置到对端信任库，否则会出现“unknown CA”告警。
在 PQC 迁移中，证书链会显著变长：ML-DSA 公钥和签名尺寸远大于 ECDSA，一张证书可能从 1KB 级增长到数 KB，链传输和握手包大小都会上升，需要关注 TLS 记录分片与 MTU 问题。
四、SNI 与会话恢复
SNI（Server Name Indication）让客户端在 ClientHello 中声明目标主机名，服务器据此选择对应证书。mTLS 中 SNI 仍然只影响服务器证书选择，不影响客户端证书选择；客户端证书通常由服务器在 CertificateRequest 中通过可接受的 CA 列表来约束。
会话恢复（TLS 1.3 的 PSK / session ticket，TLS 1.2 的 session ID 或 ticket）会跳过完整证书交换。这意味着：恢复会话不会重新验证证书。如果证书在会话有效期内被吊销或算法策略变更，恢复路径可能仍在使用旧信任状态。PQC 迁移期间，若新旧算法并存，必须明确会话恢复是否允许跨算法族复用，通常建议在迁移窗口内缩短 ticket 生命周期或禁用跨族恢复。
五、常见部署模式
mTLS 在工程中有几种典型落地方式，选择哪种直接决定证书生命周期管理和 PQC 迁移的改造面。
| 部署模式 | 证书终止位置 | 典型场景 | PQC 迁移关注点 |
|---|---|---|---|
| 边缘直连 mTLS | 业务服务自身 | 服务间东西向调用 | 每个服务需独立支持新算法 |
| 网关终止 mTLS | API 网关 / Ingress | 外部客户端接入 | 网关与后端之间需二次身份传递 |
| Service Mesh mTLS | Sidecar 代理 | Kubernetes 微服务 | 控制面签发证书，算法由 mesh 统一升级 |
| 双向 TLS 隧道 | VPN / 隧道端点 | 跨机房、跨云互联 | 长连接恢复策略影响算法切换 |
以 Service Mesh 为例，控制面（如 Istio 的 Citadel / istiod）为每个工作负载签发短期证书，Sidecar 自动完成双向验证。这种模式下 PQC 迁移的改造点集中在控制面 CA 和 Sidecar 的 TLS 栈，业务代码几乎无感；而边缘直连模式则需要逐个服务升级，改造面大得多。
六、迁移视角下的关键判断
把上述环节放到 PQC 迁移中，可以形成几个明确的判断依据：
- 握手是否完整：完整握手会重新验证证书链，是算法切换的安全窗口；会话恢复不会，需单独控制。
- 证书链是否可控：私有 CA 可自主签发 PQC 证书，公有 CA 受其根证书算法限制。
- SNI 是否影响证书选择：多域名场景下，服务器需为每个 SNI 准备对应算法族的证书。
- 验证策略是否允许混合：迁移期通常需要“经典 + PQC”双证书或混合签名，验证端要能同时接受。
openssl s_client -connect host:443 -showcerts 抓取对端完整证书链，确认链长度、签名算法和 EKU；再用 openssl verify -CAfile ca.pem chain.pem 在本地复现验证路径，提前发现链不完整或算法不被信任库接受的问题。理解这些环节后，后续讨论 PQC 证书格式、混合握手和迁移顺序时，就能准确判断每一步改动落在握手的哪个阶段、影响哪一类部署模式，而不是把“换算法”当成一个笼统的动作。