量子计算威胁的时间表正在急剧缩短。Google 与 Oratomic 近期相继公布的研究进展表明，能够破解现有椭圆曲线密码学的量子计算机可能比预期提前到来。面对这一紧迫形势，Let's Encrypt 作为管理超过 2.5 亿张活跃证书的全球最大免费证书颁发机构，正在制定一套系统性的后量子密码学（PQC）迁移策略。
从加密到认证：威胁焦点的转移
过去数年，业界的 PQC 工作主要集中在密钥交换层面，以防范 "先收集后解密"（Harvest Now, Decrypt Later）攻击。这种攻击模式下，攻击者今日截获加密流量，待量子计算机成熟后再行解密。Let's Encrypt 已于 2024 年在服务器端支持 X25519Kyber768 混合密钥交换，现代浏览器如 Chrome、Firefox 也已内置相关支持。
然而，2026 年初的一系列技术突破改变了风险评估。Google 宣布大幅优化了破解 P-256 椭圆曲线的量子算法，Oratomic 则发布了在中性原子量子计算机上破解 RSA-2048 和 P-256 的资源估算 —— 仅需约 10,000 个量子比特。这些进展促使 Google 和 Cloudflare 将完整 PQC 安全目标提前至 2029 年，并将重点从加密转向认证—— 即防范量子计算机伪造证书签名、冒充服务器的主动攻击。
正如 Cloudflare 在其路线图公告中所指出的："当量子计算领域的专家开始修补认证系统时，我们都应该倾听。"
Merkle Tree 证书：WebPKI 的结构性革新
后量子数字签名算法（如 ML-DSA）面临一个严峻的工程问题：签名体积过大。据社区讨论中的技术估算，采用最强 ML-DSA 密钥的证书链可能膨胀至 20KB 以上。Cloudflare 的实测数据显示，超过 10KB 的握手数据会导致连接失败，9KB 也会造成 15% 的性能下降。
Let's Encrypt 工程师在社区论坛中确认，他们正与 Google、Cloudflare 及 Filippo Valsorda 等作者合作推进 Merkle Tree Certificates（MTC） 方案。MTC 将证书透明度机制嵌入签发流程，通过 "地标证书"（landmark certificates）实现签名压缩，从而解决大签名带来的传输瓶颈。
MTC 的核心设计在于区分两种证书形态：
- 独立证书（Standalone）：包含完整公钥和签名，体积较大但可立即使用
- 地标相对证书（Landmark-relative）：通过引用已分发的地标数据大幅缩小体积，但依赖异步更新机制
这一设计对 Let's Encrypt 的 ACME 协议提出了新要求 —— 需要支持从单个 Finalize 请求返回两种形态的证书，并处理 PQ ACME 账户密钥的兼容性问题。
运营层面的三重挑战
对于管理 2.5 亿张证书的 Let's Encrypt 而言，PQC 迁移不仅是技术升级，更是运营层面的系统性工程。
客户端兼容性断层 是最直接的障碍。Let's Encrypt 社区讨论中反复提及，即使今日仍有系统无法使用 ECC 证书，PQC 算法的兼容性挑战将更为严峻。Windows Server 2025 虽已支持 ML-KEM 和 ML-DSA，但尚未在 Schannel 层（TLS 实际协商层）开放，这预示着客户端生态的适配将是一个渐进过程。
证书生命周期策略 需要重新评估。传统短周期证书（如 90 天）在 MTC 架构下可能产生新的权衡 —— 地标数据的更新频率与证书有效期之间的协调。社区讨论中提出的一个思路是：保持现有的自动续期节奏，但延迟使用新证书至接近过期时，让证书 "陈化" 以确保依赖方已同步地标数据。
标准化进程依赖 构成了时间表的不确定性。证书格式的变更需要 CA/B Forum 基线要求的更新，ACME 协议的扩展则需要 IETF 的支持。正如社区成员指出的，除非出现安全漏洞需要热修复，或多家机构联合推动新标准，否则标准化流程难以加速。Let's Encrypt 已明确表示将在生态系统更稳定时快速跟进新标准。
面向运维人员的行动清单
基于当前技术路线和行业共识，运维团队可从以下维度启动准备工作：
监控与基线建立
- 在服务端启用混合密钥交换（X25519Kyber768）并监控握手成功率
- 跟踪 TLS 握手大小分布，识别接近 9-10KB 阈值的证书链
- 评估现有负载均衡器、CDN 对大型握手数据包的处理能力
兼容性测试
- 在测试环境部署 ML-KEM 密钥交换，验证客户端协商行为
- 关注操作系统和中间件的 PQC 支持路线图（如 OpenSSL 3.5+、Windows Server 更新）
- 识别依赖旧版加密栈的内部系统，制定隔离或升级计划
供应链与采购
- 将 PQC 支持纳入供应商评估标准，优先选择已公布 2029 年完整 PQC 安全目标的厂商
- 评估关键依赖方（支付网关、身份提供商）的 PQC 准备状态
- 建立证书轮换的自动化能力，为未来可能的紧急算法切换预留操作空间
风险分层
- 优先识别和保护长期密钥：根证书、API 认证密钥、代码签名证书
- 评估 "先收集后解密" 攻击对业务数据的实际影响，确定数据保护优先级
- 制定降级攻击防护策略，考虑在内部系统中实施 PQ HSTS 类机制
时间线与行业协调
Google 和 Cloudflare 已将 2029 年设为完整 PQC 安全目标，Let's Encrypt 的路线图预计将在年内通过官方博客公布。行业共识正在形成：混合密钥交换解决当下的加密需求，而认证系统的升级需要更长时间 —— 不仅是技术部署，更涉及依赖链验证、欺诈监控体系和第三方审计的协调。
对于依赖 Let's Encrypt 的运维团队而言，关键不在于等待完美方案，而在于建立监控基线、测试兼容性边界，并为渐进式迁移做好准备。后量子密码学的部署不是一次性切换，而是一个跨越数年的生态演进过程。
资料来源
- Let's Encrypt Community Discussion: Roadmap request (redux): Post-quantum cryptography
- Cloudflare Blog: Cloudflare targets 2029 for full post-quantum security
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。