Let's Encrypt 公布后量子路线：Merkle Tree 证书保障 TLS 未来

Let's Encrypt 公布后量子路线：Merkle Tree 证书保障 TLS 未来

Let's Encrypt 在 2026 年 6 月正式宣布了它的后量子 Web PKI 路线：用 Merkle Tree Certificates（MTC，Merkle 树证书）作为前进方向，目标是在 2026 年底上线可以签发 MTC 的分期（staging）环境，2027 年上线生产环境。对站长来说，当前证书的签发与续期完全不受影响，未来也会继续以"免费、自动化、开放"的方式提供后量子证书。

为什么时间表在加速

过去几年，后量子讨论主要围绕"加密"（防"先记录、后解密"的收割式攻击），认证（TLS 中证明服务器身份的环节）被认为没那么紧迫。但这一舒适区正在被侵蚀：

• 美国 NSA 的 CNSA 2.0 自 2022 年起就把国家安全系统导向后量子算法，时间表是 2030-2035；
• NIST 的过渡指南草案计划在 2030 年后弃用 RSA-2048 和 P-256，2035 年后禁止；
• 欧盟路线图要求高风险系统 2030 年底前、全面迁移 2035 年前完成；
• 2026 年时间表进一步缩短：Google 和 Cloudflare 都把自家服务迁移目标定在 2029 年；Go 1.27 标准库加入了 NIST 后量子签名算法 ML-DSA。

Web PKI 的特殊难题：体积

后量子签名很难部署进 Web PKI 的原因只有一个字：大。ML-DSA-44 是较小的 NIST 后量子签名方案，单个签名约 2420 字节，而 RSA-2048 只有 256 字节、ECDSA-P256 只有 64 字节。一个典型握手携带 5 个签名和 2 个公钥，如果全部换成 ML-DSA，单次 TLS 握手会超过 10KB——Cloudflare 的研究显示，在这个规模上相当比例的 TLS 连接会直接在真实网络中失败，其余也会变慢。

签名体积差出两个数量级，正是"直接换算法"走不通、必须重新设计证书结构的原因。这也解释了为什么 Web PKI 的后量子迁移比加密更慢：加密侧的 X25519MLKEM768 密钥交换体积增加有限，而认证侧的证书会成倍膨胀。

Merkle Tree 证书如何工作

MTC 的核心思路是"批量签发"：CA 一次性给整批证书签发，用一个签名覆盖整个批次，浏览器通过握手之外的渠道（称为 landmarks）保持对批次签名的跟进。在常见场景下，MTC 握手的完整认证路径只有一个签名、一个公钥和一个包含证明，比今天的 Web PKI 握手还小，即使底层使用后量子算法；"standalone"形态则作为回退，应对客户端 landmarks 过期的情况。

MTC 还有个额外好处：证书存在于 Merkle 树之中，透明度（Certificate Transparency）从"事后外挂"变成签发本身的属性。Let's Encrypt 自 2019 年就运营 CT 日志，正是 MTC 所依赖的同一类数据结构。目前 Cloudflare 和 Chrome 已用真实流量开展 MTC 可行性实验，IETF 的 PLANTS 工作组在推进标准化，Chrome 也宣布 MTC 是公共网络添加后量子证书的首选路径。

你现在该做什么

对多数站点来说，当下无需任何操作。最有杠杆的行动是：确保服务器支持混合后量子密钥交换 X25519MLKEM768——主流浏览器和操作系统已经支持，在服务端打开它即可抵御"先记录后解密"。

以 Nginx + OpenSSL 3.5 为例，把曲线组写进配置即可启用：

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

改完 nginx -t && nginx -s reload，再用 openssl s_client -connect 你的域名:443 -groups 验证协商出的组里是否出现 X25519MLKEM768；或直接 curl --tlsv1.3 --curves X25519MLKEM768 -I https://你的域名 看是否握手成功。Caddy 与主流反向代理也已在默认配置里包含该曲线组，绝大多数情况只需升级软件版本。开启后，即使日后量子计算机能破解经典公钥，过去被"先记录"的流量也无法被解密。证书侧的自动化与生命周期管理可参考Let's Encrypt SSL 配置和Certbot 自动续期，选型思路见SSL 证书指南。更多内容请查看安全/SSL分类。

常见问题

会不会影响性能与兼容性？ 混合密钥交换只在握手阶段多出几个字节，老客户端会自动回退到经典曲线，不会破坏现有兼容性。

现有证书会提前失效吗？ 不会。MTC 是并行演进，现有证书按原生命周期签发与续期，到期后照常续期即可；续期时机的智能化可参考ACME ARI 续期。

谁需要提前行动？ 自建 TLS 终止、API 网关、以及需要长期保存的密钥基础设施，应尽早跟进 CA 与浏览器的进度；普通站点跟随 ACME 客户端升级即可。证书类型与选型见SSL 证书类型，自动化方案参考Certbot 自动化。

16IDC 观察

后量子迁移是一个以年为单位的长期过程，但对站长的影响被很多人高估了：证书签发与续期完全自动化，浏览器侧也在同步跟进，普通网站几乎不需要感知底层算法的变化。真正需要提前行动的，是自建 TLS 终止、API 服务或长期存续的密钥基础设施。最稳妥的当下策略是：保持 ACME 自动化续期闭环，在服务端开启混合后量子密钥交换，然后持续跟踪 CA 与浏览器的进度即可。免费、自动化、开放的证书生态，正是这套迁移能平稳推进的最大底气。

参考：NIST 后量子密码项目 https://csrc.nist.gov/Projects/post-quantum-cryptography；FIPS 204（ML-DSA）https://csrc.nist.gov/pubs/fips/204/final；原文来源：https://letsencrypt.org/2026/06/03/pq-certs