摘要

  • ACME 工作组于 2026 年 9 月 21 日把 draft-ietf-acme-profiles-02 提交 IESG；当前状态是 Publication Requested，而非 IESG 已批准，更不是 RFC 已发布。
  • 草案把证书特性选择移到 newOrder.profile，同时保留本地广告、私有例外、账户资格判断和后续 invalidProfile 失败。名称是订单选择器，不是发证回执。

设想三个带有相同 profile 名称的订单。第一个名称正在 CA 的 ACME Directory 中公开。第二个没有被 Directory 广告，但服务器按双方私下约定接受。第三个建单时被接受，到了 finalize，CA 已不愿再按该 profile 发证，于是返回 invalidProfile。

这三条路径都在 ACME Profiles 草案允许的边界内。它的价值正在于把证书特性选择变成明确的协议动作，同时承认政策并不总是公开、静态或可跨机构移植。因此，名称可以帮助关联一次交易，却不足以单独证明资格、完成或部署。

这是一项发布请求，不是完成的标准

9 月 21 日，ACME 工作组把第 02 版从 Working Group Last Call 推进到“Submitted to IESG for Publication”。Datatracker 的 IESG 状态是“Publication Requested”，预期标准级别为 Proposed Standard，负责的 Area Director 是 Deb Cooley，页面没有列出 telechat 日期。文档 shepherd Mike Ounsworth 在工作组最后征求意见通过后发送了发布请求。

这是程序上的重要节点，但不等于 IESG 批准。该草案仍不是 RFC。shepherd write-up 把共识描述为 weak consensus：扩展被认为简单，明确表示强烈支持的回复不多，同时没有记录争议或申诉。草案列出了若干实现并说明 Let’s Encrypt 已部署。这些是有限的实现证据，不能外推为全行业采用。

选择从 CSR 前移到订单

RFC 8555 的 ACME 流程先创建订单，之后在 finalize 提交证书签名请求。新草案在 Directory metadata 中增加可选的 profiles 对象：键是短而唯一的 profile 标识，值是供人阅读的说明 URL，也允许 data URL。

客户端可在 newOrder 中放入 profile 字符串。服务器接受后，会在返回的 Order 中回显所选名称。证书特性的选择因此早于 CSR。草案的安全分析认为，这能简化 CA 政策实现，减少 ASN.1 解析与复制，让 CSR 继续聚焦公钥与 subjectAltName。

扩展没有改变账户管理和标识符验证，也没有定义一套全球通用的 profile 名称。Directory 是特定端点的广告；说明 URL 提供的是可读文本，而不是带有加密版本约束的永久语义对象。

选择、资格与完成是三项判断

当 profile 与订单不兼容时，服务器必须返回 invalidProfile。草案举出的例子包括：用 TLS server-authentication profile 申请电子邮件标识符，或账户不在该 profile 的许可名单内。

所以，看见名称并选中它，不代表账户有资格。Directory 可以公开产品入口，实际政策仍会判断哪些账户和标识符能够使用。

广告也不是完整的许可清单。客户端不应请求未广告的名称，服务器也应拒绝；但草案允许在例外情况下接受，例如双方另行约定的私有 profile，或大规模吊销之后替换旧证书。只保存 Directory，会漏掉合法的私有路径；只保存已接受的名称，又会丢掉允许它的理由。

客户端不填写 profile 也不是“没有选择”。实现该扩展的服务器被建议自行选择并绑定一个 profile。因此，证明实际选择的是 Order 响应，而不仅是请求。

建单成功仍不等于完成。如果 CA 在 finalize 前不再愿意按该 profile 发证，就必须返回 invalidProfile。草案建议服务器在停用前让已有订单自然过期，以尽量避免这种结果；但错误路径依然存在，因为政策和可用性可能在订单生命周期内变化。

名称属于具体运行环境

Let’s Encrypt 当前的 profile 文档把这种本地性写得很清楚：当前 Directory 端点才是权威列表；不同环境可能提供不同 profile，有些还受 allowlist 限制。其 classic、tlsserver 和 shortlived 在授权复用期、订单寿命、证书寿命、标识符类型与证书字段上均有差异。

可用性与含义也会演进。Let’s Encrypt 说明 tlsclient 自 2026 年 7 月 8 日起已不可用；tlsserver 已于 5 月 13 日改为 45 天证书；其公开路线图还安排了 classic 的后续寿命调整。这只能证明一家运营者会改变自身名称所对应的政策，不能证明其他 CA 使用相同名称或相同语义。

自动化系统因而应把 profile 名称限定在 Directory URL、抓取时间和账户上下文内。脱离这些信息的一行 tlsserver 配置并不能自我解释。

把证据链拆开保存

可审计的记录首先保存 Directory 响应原始字节和抓取时间；随后保存说明 URL，以及当时所读内容的哈希。这两层说明端点广告了什么、说明文本写了什么，却都不能证明某个账户有资格。

下一层记录 CA 端点、账户引用、请求名称和标识符，再保存资格结果以及回显 profile 的 Order 响应。finalize 要有独立记录，包括 CSR 指纹、响应状态和任何 ACME problem type。成功发证后，还应保存证书指纹与解析出的关键属性，证明 CA 实际签了什么。

部署又是另一个事件。证书可以已经签发，却尚未安装到目标服务。如果业务需要证明部署，就应以时间、观测位置和证书指纹另行记录线上结果。

这样的分层避免两种相反的错误：既不把广告升级为授权，也不抹掉草案明确允许的私有、随时间变化的路径。profile 名称仍然有用——它是一次有证据交易中的连接键——但不必承担协议从未赋予它的权威。

来源

  1. IETF Datatracker：ACME Profiles 当前状态
  2. IETF Datatracker：文档历史
  3. draft-ietf-acme-profiles-02 正文
  4. 发送至 ACME 邮件列表的发布请求
  5. 文档 shepherd write-up
  6. RFC 8555：ACME
  7. Let’s Encrypt profile 文档
  8. Let’s Encrypt：ACME Profiles 公告
  9. Let’s Encrypt 证书寿命路线图
  10. ACME 工作组最后征求意见公告
  11. 工作组最后征求意见结论
  12. Boulder 实现跟踪
  13. IETF 126 ACME 会议记录