Cloudflare 将后量子认证延伸到源站连接：AOP 与自定义信任库如何落地

2026-07-29 23 预计阅读时间: 1 分钟
来源: blog.cloudflare.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

Cloudflare 现在支持在连接客户源站时使用后量子（Post-Quantum，PQ）认证，覆盖 Authenticated Origin Pulls（AOP，经过身份验证的源站拉取）和 Custom Origin Trust Store（自定义源站信任库）两条链路。这意味着后量子保护不再只停留在访客到边缘节点的连接上，边缘节点与源站之间的身份验证也开始进入迁移范围。

这项变化的重点不是“把某个 TLS 开关打开”，而是重新检查源站双向认证、私有 CA、证书生命周期和 TLS 运行时是否能够共同处理后量子认证材料。Cloudflare 将其定位为向旗下产品全面提供 PQ 认证的第一步，因此现阶段更适合渐进验证，而不是未经测试便替换全部生产证书。

两条源站认证链路，解决的是不同方向的问题

理解 AOP 与 Custom Origin Trust Store 的方向，是设计迁移方案的第一步。

Authenticated Origin Pulls：源站验证 Cloudflare

启用 AOP 后，Cloudflare 连接源站时会提供客户端证书，源站根据受信任的 CA 验证该证书。它解决的是下面这个问题：

到达源站 443 端口的请求，是否确实来自经过授权的 Cloudflare 连接？

这是一种 mTLS 风格的源站访问控制。即使攻击者知道源站 IP，也不能只靠普通 HTTPS 请求绕过 Cloudflare，因为源站还会要求客户端证书。

Custom Origin Trust Store：Cloudflare 验证源站

自定义源站信任库处理相反方向：Cloudflare 在连接源站时，需要验证源站提供的服务器证书。企业可以使用自己的 CA 或私有 PKI，而不是让源站证书必须链到公共 CA。

因此，两项能力可以组合成双向身份验证：

  1. 源站使用 Custom Origin Trust Store 对应的证书链，向 Cloudflare 证明自己是正确的源站。
  2. Cloudflare 使用 AOP 客户端证书，向源站证明请求来自受信任的 Cloudflare 连接。

后量子认证支持进入这两条路径后，迁移对象就不仅是边缘配置，还包括源站 TLS 库、Web 服务器、证书签发流程和监控系统。

PQ 认证不等于整条连接已经“完全后量子化”

TLS 连接通常同时涉及密钥交换、证书签名、证书链验证和对端身份认证。此次能力明确指向源站连接中的后量子认证，因此不能仅凭“PQ authentication”就推断连接中的每个密码学环节都已采用同一种后量子机制。

评估时应拆开检查：

  • Cloudflare 到源站使用了什么 TLS 版本与密码套件。
  • 源站证书和 AOP 客户端证书采用什么签名算法。
  • 中间 CA、根 CA 与叶证书是否形成可验证的完整链。
  • 源站的 OpenSSL、BoringSSL 或其他 TLS 实现是否识别相关算法。
  • NGINX、Envoy、HAProxy 等上层软件是否链接到了具备所需能力的 TLS 库。
  • 日志、证书扫描器和密钥管理系统是否会把新算法误报为“未知”或“不安全”。

另一个现实边界是兼容性。某个 TLS 库能够列出一种 PQ 签名算法，并不代表 Web 服务器、证书解析器和生产构建链已经完整支持它。应以真实握手和证书验证结果为准，而不是只看版本号。

可以这样实践：先盘点源站，再进行隔离验证

下面的命令不会自动启用 Cloudflare 的 PQ 认证，但可以直接用于迁移前的源站检查。请把 origin.example.com 替换为真实源站域名；如果源站只允许 Cloudflare IP，建议在隔离测试环境中运行。

#!/usr/bin/env bash
set -euo pipefail

ORIGIN="${1:-origin.example.com}"
PORT="${2:-443}"

echo "== OpenSSL version =="
openssl version -a

echo
echo "== Potential PQ signature algorithms exposed by this build =="
openssl list -signature-algorithms 2>/dev/null \
  | grep -Ei 'ML-DSA|Dilithium|Falcon|SPHINCS' \
  || echo "No commonly named PQ signature algorithm was found."

echo
echo "== Origin certificate summary =="
openssl s_client \
  -connect "${ORIGIN}:${PORT}" \
  -servername "${ORIGIN}" \
  -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -text \
  | grep -E 'Subject:|Issuer:|Not Before:|Not After :|Serial Number:|Signature Algorithm'

运行方式：

chmod +x inspect-origin-tls.sh
./inspect-origin-tls.sh origin.example.com 443

如果没有列出 PQ 算法，不应立即升级生产主机。更稳妥的做法是先确认 Cloudflare 当前支持的算法与证书要求，再为测试环境选择兼容的 TLS 运行时。具体算法名称、证书格式和控制面配置应以账户中实际提供的 Cloudflare 配置为准。

AOP 源站配置示例：把客户端证书验证设为强制

下面是一个可改造的 NGINX mTLS 配置。假设 Cloudflare 提供或允许配置一条用于 AOP 的受信任证书链，并将其保存为 /etc/nginx/tls/cloudflare-pull-ca.pem。该路径和证书必须替换成账户实际使用的内容。

server {
    listen 443 ssl;
    server_name origin.example.com;

    ssl_certificate     /etc/nginx/tls/origin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/origin-private-key.pem;

    # 用于验证 Cloudflare 在 Authenticated Origin Pulls 中提供的客户端证书。
    ssl_client_certificate /etc/nginx/tls/cloudflare-pull-ca.pem;
    ssl_verify_client on;
    ssl_verify_depth 4;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Client-Cert-Subject $ssl_client_s_dn;
        proxy_pass http://127.0.0.1:8080;
    }
}

保存后先做语法检查，再平滑加载：

sudo nginx -t
sudo systemctl reload nginx

还可以用一组负向与正向测试确认源站没有被意外开放。没有客户端证书的请求应失败；携带测试客户端证书的请求才应成功：

# 预期失败：未提供客户端证书。
curl -v --resolve origin.example.com:443:203.0.113.10 \
  https://origin.example.com/

# 预期成功：替换为测试环境中有效的客户端证书和私钥。
curl -v --resolve origin.example.com:443:203.0.113.10 \
  --cert ./aop-test-client.pem \
  --key ./aop-test-client-key.pem \
  --cacert ./origin-ca.pem \
  https://origin.example.com/

这里的 NGINX 配置只展示 AOP 的验证边界，并不会凭空赋予 NGINX 后量子能力。要验证 PQ 认证，NGINX 所使用的 TLS 库、客户端证书算法以及受信任 CA 链必须全部兼容。不要为了排除握手错误而长期设置 ssl_verify_client optional，否则会削弱 AOP 原本要建立的访问边界。

上线时不要把证书轮换当成普通配置发布

后量子认证迁移最好采用独立测试源站、少量流量和可回滚证书链。一个实用的上线检查表包括：

  • 为 PQ 测试准备独立主机名或源站池，避免直接覆盖唯一的生产入口。
  • 分别验证 Cloudflare 到源站、运维人员到源站以及健康检查到源站的握手行为。
  • 确认 AOP 开启后，直接访问源站 IP 的无证书请求会被拒绝。
  • 确认自定义信任库中包含正确的根证书和中间证书，并检查链顺序与有效期。
  • 记录证书签名算法、序列号和到期时间，避免监控平台因无法解析新算法而失去告警能力。
  • 保留已验证的旧证书链、TLS 配置和快速回滚步骤。
  • 检查负载均衡器、服务网格、WAF 后端连接及中间代理，确保没有某一层终止 TLS 后丢失认证要求。

Cloudflare 对源站 PQ 认证的支持，为企业迁移私有 PKI 和 mTLS 链路提供了一个明确入口。但真正的工作发生在整条证书验证路径上：边缘节点能发起握手只是起点，源站运行时、CA 层级、代理软件和运维工具都必须读懂并正确执行新的认证规则。先把双向身份边界做清楚，再逐步替换密码学组件，通常比一次性切换更可靠。

# Cloudflare # Rust # 云平台 # 后端 # 平台工程

相关推荐