预计阅读时间：10 分钟

Cloudflare 要做互联网级 CA：ACME、Merkle 树证书与后量子迁移

推出 Universal SSL 十二年后，Cloudflare 正在申请成为证书颁发机构（Certificate Authority，CA）。这不只是把现有的免费证书服务再扩大一圈，而是试图把既有根信任、以 ACME 为核心的自动化流程，以及 Merkle Tree Certificates（Merkle 树证书，MTC）组合起来，为开放 Web 构建一条面向后量子时代的证书路径。

需要注意，“申请成为 CA”不等于已经获得所有浏览器和操作系统的默认信任。根证书进入信任库通常涉及安全审计、运营规范、浏览器政策和持续合规，这是一项长期的基础设施工程。

从 Universal SSL 到真正的信任基础设施

Universal SSL 解决的是大规模部署 HTTPS 的问题：站点不必逐个手工购买、上传和轮换证书。成为公共 CA 则更进一步，因为 CA 位于 Web PKI 的信任链上，承担的不只是签发动作。

一套面向整个互联网的 CA 至少要处理这些环节：

验证申请者是否控制目标域名；
安全地签发、续期和撤销证书；
保护离线根密钥与在线签发密钥；
满足浏览器根计划和行业基线要求；
记录并监控错误签发；
在算法升级时兼顾新客户端与旧客户端。

因此，“既有根 + ACME 优先 + MTC”的组合很关键。既有根信任有助于降低客户端迁移阻力，ACME 把证书生命周期变成机器可以执行的协议，而 MTC 则尝试重新设计 CA 如何证明一张证书获得了授权。

ACME-first：证书应该是自动更新的依赖

ACME 的核心价值不是“免费”，而是把申请、域名验证、签发和续期标准化。对于运维团队，证书不应是一份靠日历提醒更新的文件，而应像容器镜像或软件包一样，由自动化系统获取和轮换。

常见的 ACME 验证方式包括：

HTTP-01：在站点的固定 HTTP 路径提供挑战响应；
DNS-01：写入指定 TXT 记录，适合通配符证书和不直接暴露公网 HTTP 的服务；
TLS-ALPN-01：通过 TLS 握手完成控制权验证。

下面可以先检查一个现有站点的证书链和有效期。运行前把 DOMAIN 改成自己的域名：

export DOMAIN="example.com"

openssl s_client \
  -connect "${DOMAIN}:443" \
  -servername "${DOMAIN}" \
  -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -serial -dates

在接入新的 ACME 服务前，还可以直接检查它的目录端点。由于来源摘要没有给出 Cloudflare CA 的正式 ACME 地址，下面使用占位地址，不能把它当作已经上线的接口：

export ACME_DIRECTORY="https://ca.example/acme/directory"

curl -fsSL "$ACME_DIRECTORY" | jq .

一个标准 ACME 目录通常会返回 newNonce、newAccount、newOrder 等入口。正式迁移时，不要只测试首次签发，还要覆盖自动续期、账户密钥轮换、速率限制、失败重试和证书撤销。

如果服务器使用 Caddy，可以这样为未来的兼容 ACME 服务预留配置。请先替换邮箱、域名和目录地址：

{
    email ops@example.com
    acme_ca https://ca.example/acme/directory
}

app.example.com {
    reverse_proxy 127.0.0.1:8080
}

这只是通用 ACME 接入示例，并不表示占位端点已经可用。生产环境还应保留当前 CA 作为回退路径，并在测试环境验证客户端兼容性。

Merkle 树证书改变了什么

传统证书通常由 CA 对每张证书分别进行数字签名。这个模型简单直接，但如果换成体积更大、计算成本更高的后量子签名算法，大规模签发可能显著增加证书大小、网络负担和签名成本。

MTC 的思路是在一批证书或证书声明上构建 Merkle 树，由 CA 对树根进行签名。单张证书携带相应的包含证明，验证者便可以确认：

这张证书对应的叶子节点确实位于树中；
该树根得到了 CA 的授权签名；
证书内容在签发后没有被篡改。

这样可以把一次签名的成本分摊到大量证书上。Merkle 包含证明通常只需随树规模按对数增长，因此它为体积较大的后量子签名提供了一种更可扩展的部署思路。

不过，MTC 不应与 Certificate Transparency（CT，证书透明度）混为一谈。两者都使用类似的树结构，但目标不同：CT 重点是公开记录与审计证书签发，MTC 重点是证明证书属于某个由 CA 签名的集合。具体线缆格式、浏览器验证方式和兼容策略仍应以最终标准与实现为准。

“后量子 CA”不等于整条 TLS 链路已经抗量子

即使 CA 使用后量子签名或 MTC，TLS 连接也不会自动变成完整的后量子安全连接。至少要区分三个层面：

证书认证：客户端如何确认服务器公钥受到可信 CA 授权；
密钥交换：客户端和服务器如何协商会话密钥；
应用数据加密：会话建立后如何保护 HTTP 数据。

CA 层的升级主要解决长期身份认证与证书签名风险。要抵御“现在收集、未来解密”类型的威胁，TLS 密钥交换也需要采用后量子或混合机制。与此同时，浏览器、TLS 库、反向代理、硬件安全模块和中间网络设备都必须支持相关算法。

这也是既有根信任仍然重要的原因：密码算法可以快速演进，但分布在数十亿设备上的信任库无法同时更新。现实迁移往往需要双证书、混合算法或分阶段启用，而不是一次性切换。

接入前应该验证什么

面对新的公共 CA，团队可以按以下顺序评估：

确认其是否已进入目标浏览器、操作系统和运行时的信任库；
在测试域名上验证 ACME 首次签发与自动续期；
检查 RSA、ECDSA 及未来后量子方案的客户端覆盖范围；
测量完整证书链、握手包大小和连接延迟；
验证 CT、撤销、CAA 和监控工具是否兼容；
设计第二 CA 或现有证书链的回退方案；
对旧版 Android、Java、嵌入式设备和企业代理单独测试。

Cloudflare 的计划值得关注，不只是因为市场上可能多出一个 CA，而是因为它把自动化签发和后量子迁移放进了同一套架构。真正决定方案能否覆盖开放 Web 的，将是信任库接纳、标准成熟度、客户端实现以及长期运营能力。对应用团队而言，最稳妥的动作不是立即切换，而是先消除手工证书流程，建立可替换 CA、可观测、可回退的自动化证书体系。

Cloudflare 要做互联网级 CA：ACME、Merkkle 树证书与后量子迁移