摘要

  • RFC 9538 用 MI.ACMEDelegationMethod 把上游 CDN 的授权与下游 CDN 自持密钥的证书申请连接起来，避免共享上游长期私钥。
  • 委托对象、CSR 校验和 CA 签发各自证明有限事实；它们不证明 DNS 已指向目标集群，也不证明每个边缘节点选用了正确证书并返回了正确内容。
  • STAR 的取消与普通证书的吊销有不同的生效时钟。运营记录必须把授权、签发、解析、安装、握手、内容和终止拆成独立回执。

最危险的绿灯，往往不是假的，而是被解释得太宽。

一个下游 CDN 完全可以拥有一张有效证书，同时仍未具备完整的交付能力：某个地区没有完成安装；另一个地区把新证书写入磁盘，却仍由 SNI 规则选中默认证书；部分递归解析器还看见旧的 CNAME；握手成功的节点又从错误缓存键中返回了别人的对象。这些故障都不会让证书本身失效。

2024 年 2 月发布的互联网标准轨文档 RFC 9538 解决的是一个真实而狭窄的问题。上游 CDN 通过 DNS 重定向把 HTTPS 交付委托给下游 CDN 时，下游需要一张绑定内容提供者域名的证书。直接复制长期私钥会把同一秘密扩散到组织边界之外。RFC 9538 因而复用 RFC 9115 的委托模型：下游自己生成密钥，上游身份所有者约束它能申请什么。

四个字段只负责启动证书路径

MI.ACMEDelegationMethod 的 acme-delegation 是下游账户对应委托对象的 HTTPS 地址；time-window 给出证书有效区间；出现 lifetime 就表示短期自动续签的 STAR 模式，缺少该字段则表示非 STAR；lifetime-adjust 可调整 STAR 生命周期。该类型已进入 IANA CDNI 参数登记表。RFC 8006 和 RFC 8008 分别规定元数据接口及能力通告的安全语义，RFC 7336 提供 CDN 互联框架。

这四个字段里没有边缘节点清单，没有安装确认，没有从多个网络看到的 DNS 结果，也没有 SNI 探测、HTTP 内容摘要或用户侧结果。把“已通告委托”直接显示成“HTTPS 已就绪”，等于让一个局部状态替多条控制链作证。

账户能授权申请者，不能替结果背书

在 RFC 9115 中，上游是身份所有者，下游是名称委托使用者。双方先在协议外完成账户登记和授权边界。下游用账户密钥取得含 CSR 模板的委托对象，生成自己的密钥对与 CSR；上游核对请求是否符合域名、密钥和扩展约束，再用自己的 CA 账户执行 ACME 基础流程。

这个结构的价值很明确：上游长期私钥无需进入下游机群。但它也使下游账户密钥成为高价值控制点。账户认证加预配置委托，在这段流程中取代了通常的 ACME 域名挑战。因此，账户必须精确绑定可申请的名称和方式。

CSR 合格，只能说明请求符合模板；订单成功，只能说明 CA 的签发流程完成。RFC 5280 的证书路径和 RFC 9525 的服务身份校验，可以回答客户端是否应接受所展示的身份。TLS 1.3 与 SNI 规定握手和名称选择。它们都不回答 HTTP 最终返回了哪个对象。

DNS 是另一根操作杠杆

RFC 9115 的委托对象支持 CNAME 映射；RFC 9538 还指出，未来更新可以纳入 SVCB/HTTPS。无论使用哪一种记录，域名到服务端点的投影都不是证书签发的副产品。

域名持有人可以保留 DNS 区域的唯一修改权。CAA 可限制 CA，RFC 8557 的 ACME 专用参数还能限制账户和验证方法。这些措施缩小签发权限，却不能证明解析器已经看见新记录、返回的地址属于预期机群，或所有用户路径已经收敛。

可靠的上线记录应当保存权威区变更、确切 RRset、TTL 与时间点，从多个网络观测解析，并把每个返回端点映射回部署清单。证书序列号不能代替这份证据。

STAR 与非 STAR 有两种终止时钟

RFC 8739 的 STAR 证书寿命短、自动续签、可反复下载。身份所有者取消续签后，已经签发并安装的最后一张证书不会瞬间消失；权限要到它过期才实际终止。事故时间线因此要同时记录取消确认、最后签发、最后下载、最后激活和最终过期。

非 STAR 证书则通过 ACME 吊销。上游可以向 CA 请求吊销；持有证书私钥的下游也可能直接吊销，只应在安全需要时绕过上游。CA 接受吊销请求仍不等于所有边缘都已清除证书，更不等于所有依赖方会在同一时刻拒绝它。

证书透明度 RFC 9162 可以让签发可观察，却不证明证书被安装、被选中或被移除。RFC 9325 提供 TLS 部署建议，也不能替代真实探测。

七张回执比一个“就绪”更有用

第一张回执来自内容提供者：精确域名、下游账户、授权期限和再委托规则。第二张保存委托对象与 CSR 模板哈希。第三张保存 CSR、公钥指纹、订单和 CA 授权结果。第四张记录证书序列号、SAN、链与有效期。第五张验证权威 DNS 及其外部投影。第六张把每个端点的已激活指纹和 SNI 规则与清单核对。第七张从独立网络验证 TLS、HTTP 和内容，并在续期、取消或吊销时重跑。

这些状态不应被压成一个颜色。“已签发、未安装”“92% 节点已收敛”“DNS 已切换、目标机群未齐”“STAR 已取消、最后证书还有效 47 分钟”，都比一句“安全”更能指导行动。

RFC 9538 没有声称一张证书等于完整交付。真正的错误发生在运营者让协议工件替运行现实作证的时候。

来源与边界

文档状态可由 RFC Editor 信息页、IETF 历史 和 勘误页复核。本文还依据 RFC 9538、9115、8739、8555、8006、8008、7336、9460、9325、9525、5280、8659、8557、8446、6066、9162及 IANA 登记表。本文没有检查任何具名 CDN 的生产部署、事故、端点清单或抓包，也不把一次探测外推为整套机群状态。