Let's Encrypt 押注 Merkle Tree Certificate：后量子证书体积难题的破解之道

行业动态 · 2026-06-19 · 8 阅读

前言

2026 年 6 月 3 日，全球最大的免费证书签发机构 Let's Encrypt 发布了一篇重磅博文《A Post-Quantum Future for Let's Encrypt》，明确宣布将以 Merkle Tree Certificate（MTC） 作为其后量子 Web PKI 身份验证的主要方案。这标志着 Web PKI 的后量子迁移从"密钥交换加固"阶段正式迈入了"身份验证重构"的新阶段。

本文将从工程实践角度，深入分析以下几个核心问题：

为什么后量子签名直接替换现有 Web PKI 会失败？
MTC 的批签发机制如何将身份验证开销压缩到比今天更小？
这一变革对 ACME 协议、Certificate Transparency 和国密 PKI 有何深远影响？

Web PKI 后量子困局：不是算法问题，是体积问题

过去几年，后量子密码学（PQC）的讨论主要集中在加密层面——攻击者可以现在录制加密流量，等量子计算机成熟后再解密（即"Harvest Now, Decrypt Later"）。混合后量子密钥交换（如 X25519MLKEM768）已经在主流浏览器中部署，AWS 也在 2026 年 4 月将 ML-KEM 后量子 TLS 默认启用到了 KMS、Secrets Manager、ACM 等服务。

相比之下，身份验证（即证书签名）的紧迫性长期被低估。毕竟，量子计算机需要实时伪造签名，而不能事后回溯。但这种"舒适"正在被打破：

NSA CNSA 2.0：要求国家安全系统在 2030-2035 年间完成后量子迁移，RSA-2048 和 P-256 将在 2030 年后被弃用
Google：2026 年 3 月宣布将在 2029 年前完成全服务后量子迁移
Cloudflare：同步承诺后量子迁移时间线
Go 1.27：将 NIST 标准化的 ML-DSA 后量子签名算法纳入标准库，标志着后量子签名从理论走向实用基础设施

问题的核心在于体积。当前 Web PKI 使用的签名方案体积很小：RSA-2048 签名仅 256 字节，ECDSA-P256 更是只有 64 字节。而 NIST 标准化的 ML-DSA-44（已经是最小的后量子签名方案之一）单个签名就有约 2,420 字节，公钥 1,312 字节。

一个典型的 Web PKI TLS 握手需要携带 5 个签名和 2 个公钥。如果全部替换为 ML-DSA：

CODE

当前握手验证数据量：5 × 256B + 2 × 256B ≈ 2,048 字节（RSA-2048）
后量子握手验证数据量：5 × 2,420B + 2 × 1,312B ≈ 14,724 字节（ML-DSA-44）

超过 10 KB 的握手数据增长。Cloudflare 的研究（基于其大规模网络实测数据）表明，在真实网络环境中，这种体积膨胀会导致相当比例的 TLS 连接失败——当 TLS 握手载荷超过 10 KB 时，约 5% 的连接会因中间件（防火墙、负载均衡器、IDS）无法处理 oversized TLS 记录而直接失败（参见：Network Impact of Post-Quantum Certificate Chain sizes），即使不成功也会显著变慢。对于一个每天签发数亿张证书的机构来说，这是不可接受的默认行为。

MTC 的核心设计：批签发替代单张签发

MTC（Merkle Tree Certificates）的核心思路是改变证书签发的粒度——从"每张证书单独签名"变为"批量证书合并签名"。

传统 X.509 签发模型

CODE

CA 私钥 → 签名证书 A
CA 私钥 → 签名证书 B
CA 私钥 → 签名证书 C
CA 私钥 → 签名证书 D
...

每张证书包含一个独立的 CA 签名，浏览器需要逐一验证。

MTC 批签发模型

CODE

Root Signature（Landmark）
                         ↙            ↘
                  Hash(A||B)        Hash(C||D)
                    ↙      ↘          ↙      ↘
              Hash(A)  Hash(B)  Hash(C)  Hash(D)
                 │        │        │        │
              Cert A   Cert B   Cert C   Cert D

CA 将所有待签发证书构建为一棵 Merkle Tree，只在树根签署一个签名（称为 Landmark）。每个证书的验证路径包含：

一个签名（Landmark）
一个公钥（CA 的根公钥）
一个包含证明（Merkle Inclusion Proof，即从叶子节点到根路径上的兄弟哈希）

在常见情况下，MTC 握手中的身份验证路径只需要 一个签名 + 一个公钥 + 一个包含证明，总体积甚至小于今天的 Web PKI 握手——即使使用的是后量子算法。

两种形式

MTC 定义了两种使用形式：

形式	适用场景	握手体积
Batch 形式（常见）	客户端已同步最新 Landmark	1 签名 + 1 公钥 + 1 包含证明（约几 KB）
独立形式（降级）	Landmark 过期或客户端不支持	完整证书链 + 签名（类似传统 X.509，稍大）

Landmark 通过带外通道（如浏览器内置更新、CRLite 等机制）同步给客户端，不占用 TLS 握手带宽。

为什么 MTC 是 Certificate Transparency 的天然替代

现有的 Certificate Transparency（CT）体系是"附加式"的：

CA 签发证书
CA 将证书提交到 CT Log（本质是一棵 append-only Merkle Tree）
CA 获得 SCT（Signed Certificate Timestamp）
服务器在 TLS 握手时向浏览器提供 SCT

这个过程中，CT 是事后附加的——证书可以先存在，再被记录。而且每个 SCT 都增加了握手体积。

MTC 从根本上改变了这个游戏规则：证书不能脱离 Merkle Tree 而存在。签发即记录，记录即签发。每个证书天生就带有可验证的包含证明，无需额外的 CT Log 基础设施。

Let's Encrypt 自 2019 年起就运营 CT Log，对大规模 Merkle Tree 的生产运维有丰富经验。MTC 使用的数据结构与 CT Log 的 append-only Merkle Tree 同源，这意味着他们可以将现有基础设施的运维经验直接复用。

标准化进程与生态准备

MTC 的标准化正在 IETF 的 PLANTS Working Group 推进，当前进度：

RFC draft：draft-ietf-plants-merkle-tree-certs（已到 -04，2026-05-24）
Cloudflare + Chrome 已联合开展真实网络环境下的可行性实验
Chrome 已明确表示 MTC 是其公共 Web 后量子证书的首选路径
ACME Working Group 正在讨论协议扩展（draft-ietf-acme-merkle-tree-certs）

Let's Encrypt 的计划时间线：

时间	里程碑
2026 年末	建立 MTC 测试环境（staging）
2027 年	生产环境上线 MTC
持续	同步跟进 ML-DSA X.509（RFC 9881）和 TLS（draft-ietf-tls-mldsa）标准

关键承诺：现有证书的申请和续期流程不受影响。后量子证书将像 Let's Encrypt 一贯的服务原则一样：免费、自动化、对所有人可用。

技术细节：MTC 验证的完整流程

以下是一个简化的 MTC 验证流程示意（基于 IETF draft 描述）：

CODE

┌─────────────────────────────────────────────────────┐
│                    TLS 握手                          │
│                                                     │
│  服务器发送：                                        │
│  ├── MTC 叶子节点数据（域名、公钥、有效期等）          │
│  ├── Merkle 包含证明（兄弟哈希路径）                   │
│  └── 对应时期的 Landmark 签名                        │
│                                                     │
│  浏览器验证：                                        │
│  1. 从本地 Landmark 缓存中获取 CA 公钥和 Root Hash   │
│  2. 利用包含证明重新计算 Root Hash                   │
│     hash(path): H(leaf) → H(leaf||sibling) → ... → Root │
│  3. 比对计算出的 Root Hash 与 Landmark 中的 Root Hash │
│  4. 验证 Landmark 签名（后量子签名，如 ML-DSA）       │
│  5. 验证叶子节点中的证书内容（域名匹配、有效期等）     │
│                                                     │
│  结果：5 步验证，1 次签名验证，体积 < 传统多证书链     │
└─────────────────────────────────────────────────────┘

对于 ACME 客户端而言，最大的变化在于：

申请方式变化：不再是"申请一张证书拿到一个文件"，而是"申请加入某个批次的 Merkle Tree"
验证周期变化：证书不再是独立生效，而是批次生效——需要等待当前批次构建完成
吊销机制变化：MTC 的吊销可能需要更新 Merkle Tree 而非简单发布 CRL/OCSP

这对使用 cert-manager、acme.sh 等工具的 DevOps 团队来说，意味着需要关注 ACME 客户端的版本更新。

对国密 PKI 的启示

MTC 的设计理念对国密 PKI 体系同样有重要的参考价值，但需要结合国密体系的具体架构差异来理解：

1. 双证书体系的优化空间

国密 TLS（GM/T 0024-2014 / TLS 1.3 国密套件）采用双证书机制（签名证书 + 加密证书），单次握手已携带 2 个签名 + 2 个公钥。以 SM2（256 位）签名约 64 字节计算，当前国密双证书握手签名开销约为 128 字节。但如果未来需要将签名算法迁移到后量子方案（如基于格的 SM2 后量子替代算法），即使采用 ML-DSA-44 级别方案，签名膨胀至 2,420 字节将导致双证书握手签名开销从 128 字节激增至 4,840 字节——MTC 的批签发思路可将此膨胀控制在可接受范围内。

2. 国密 CT 日志的架构融合

国密 PKI 体系目前对 Certificate Transparency 的应用仍在早期阶段。当前国密 CT 日志使用 SM3 替代 SHA-256 作为哈希函数，是独立于签发流程的附加组件。MTC 的设计思想可以指导国密 CT 日志从"事后审计"升级为"签发必需"，不过需要注意：国密体系下的 CT 日志可能服务于不同的合规目标（如密评要求、国密证书透明度审计），架构设计需兼顾国内监管要求。

3. 与 CNSA 2.0 的协同

NSA CNSA 2.0 要求国家安全系统在 2030-2035 年间完成后量子迁移，RSA-2048 和 P-256 将在 2030 年后被弃用。需要注意的是，CNSA 2.0 主要面向美国国家安全系统（NSS），其算法选择（ML-KEM/ML-DSA）与国际标准一致但不涉及 SM2/SM3/SM4 等国密算法。国密体系的后量子迁移路径尚未有明确的官方时间表，但国内 Web PKI 参与者可以关注 MTC 标准进展，评估其对国密证书批量签发场景的适用性。

实施挑战与注意事项

尽管 MTC 方案前景看好，但仍有多项重大工程挑战：

1. ACME 协议适配

Let's Encrypt 的 ACME 协议（RFC 8555）目前围绕单张证书的生命周期设计。MTC 需要新的 ACME 扩展来支持：

批次加入的异步确认
Landmark 同步状态查询
批次吊销的新语义

2. 根程序（Root Programs）信任扩展

Mozilla NSS、Microsoft Root Program、Apple 等根程序需要明确对 MTC 证书的支持策略。这包括：

是否允许 MTC 格式的 TLS 证书
Landmark 的密钥轮换策略
独立形式 MTC 的兼容性处理

3. 客户端生态支持

ACME 客户端（如 certbot、acme.sh、lego、cert-manager）需要更新以支持新的申请流程。这对企业自动化证书管理有直接影响。

4. 批次延迟

MTC 证书不再是"立即可用"——需要等待批次构建完成（可能是分钟级或小时级）。对需要快速签发证书的场景（如自动扩缩容环境），这可能需要架构调整。

行动建议

对于不同角色的从业者，MTC 带来的行动项有所不同：

TLS 服务运维：

确保服务器已启用混合后量子密钥交换（X25519MLKEM768），这是当前最高杠杆操作
关注 ACME 客户端更新日志，准备适配 MTC 扩展
评估自身证书管理流程对批次签发的兼容性

ACME 客户端开发者：

跟踪 IETF PLANTS Working Group 和 ACME Working Group 的标准进展
参与 mtcs@chromium.org 邮件列表讨论
开始设计 MTC 支持的架构方案

国密 PKI 从业者：

关注 MTC 对双证书体系优化的参考价值
评估 MTC 与 GM/T 0024 协议的兼容性
研究后量子国密签名的批签发可行性

总结

Let's Encrypt 的 MTC 计划标志着 Web PKI 后量子迁移进入了一个关键转折点。过去，行业专注于"如何让加密流量抵抗量子攻击"；现在，问题变成了"如何让后量子身份验证在实际部署中可行"。

MTC 给出的答案是：不要逐个签名，要批量签名；不要附加透明度，要内嵌透明度。这个设计将后量子证书的握手体积从"不可接受"压缩到"甚至更小"，同时通过 Merkle Tree 的结构特性将 Certificate Transparency 从"附加功能"变为"天然属性"。

当然，MTC 的全面部署还需要时间——IETF 标准仍在演进，根程序政策支持需要协调，客户端生态需要准备。但方向已经明确：Web PKI 的后量子未来，正在从 Merkle Tree 的生长开始。

参考来源

A Post-Quantum Future for Let's Encrypt — Let's Encrypt 官方博文，2026-06-03
Let's Encrypt 規畫2027年建立後量子憑證架構 — iThome 中文报道
Let's Encrypt 押注 Merkle 树证书，迎战量子威胁 — 开源中国
A Post-Quantum Future for Let's Encrypt | Hacker News — 社区讨论与解读
Why the 47-Day Clock Isn't the Real Story — Cyber Security News 深度分析
draft-ietf-plants-merkle-tree-certs — IETF PLANTS Working Group
Hybrid Post-Quantum TLS with AWS KMS — AWS 后量子 TLS 文档
Meta PQC Migration Framework — Meta 工程博客
ML-KEM Post-Quantum TLS on AWS — AWS Builder 博客
NIST CNSA 2.0 — NSA 后量子密码标准
Network Impact of Post-Quantum Certificate Chain sizes on Time to Last Byte — arxiv 实测研究，量化 PQ 证书体积对 TLS 性能的影响

← 返回文章列表