摘要

  • draft-ietf-acme-profiles-02 允许 ACME 服务端公布本地定义的证书 Profile，并把所选名称写进订单；它仍是标准轨道互联网草案，不是 RFC，也不是全球统一的 Profile 注册表。
  • Profile 字符串证明的是策略选择被服务端接受，而不是账户有资格、标识符已获授权、最终证书完全符合承诺、证书已正确上线或客户端必然信任。
  • 稳健做法是冻结下单时的 Directory 与说明文档，再检验实际 DER 证书、安装端点和真实依赖方结果。

自动续期系统显示绿色。订单里有 profile: "tlsserver"，ACME 请求签名正确，服务端在响应中回显了相同名称。若审计到这里结束，组织很容易把“选择成功”写成“证书符合策略”。

但真正的证书可能多了一个不应出现的 EKU；一半负载均衡节点可能仍在送出旧证书；某类终端可能走了另一条链并拒绝连接。Profile 名称无法回答这些问题。它只记录控制面的一次选择。

这正是 draft-ietf-acme-profiles-02 值得关注的治理边界。该文件日期为 2026 年 8 月 28 日，是 ACME 工作组的标准轨道互联网草案，仍可能更新、替换或到期。草案列出两个服务端与七个客户端实现，Let’s Encrypt 也公开描述了生产使用。这些是运行代码的有力证据，但不是 IETF 最终标准地位，也不是完整采用率调查。

它建立选择器，不建立全球产品目录

允许选择 Profile 的 ACME 服务端，会在 Directory 的 meta 中放入 profiles 对象。每个短名称对应一条可供人阅读的说明 URL，说明也可以内嵌为 data URI。客户端可在 newOrder 中提交 profile；服务端接受后，在订单对象中回显所选名称。

名称与含义都由服务端决定。classic、tlsserver、shortlived 或 profile1 不会因为拼写相同就在不同 CA 之间自动同义。草案也没有要求说明 URL 采用机器可判定的证书字段模型。订单中的字符串因此是“指向本服务端某套策略的选择器”，不是第三方签发的含义证明。

这已经足以改善 ACME。客户端不必把复杂策略意图塞进 CSR；CA 可以公布选择，而不必另造私有下单接口；Profile 会从建单一直绑定到最终签发。协议无需为了实现这些好处而接管每家 CA 的产品、价格、根计划或内部审批。

操作记录必须保留命名空间：Directory URL、响应哈希、获取时间、TLS 对端、说明文档字节与版本，以及影响资格的账户条款。只保留 tlsserver，等于把名称从其权威上下文中剥离。

从 CSR 移出的，是策略决定，不是公钥与标识符

RFC 8555 的 newOrder 可以指定标识符和有效期意图，最终阶段再送 CSR。CSR 能承载许多 X.509 字段与扩展，但 CA 对最终证书负有决定责任。若把客户端提交的扩展直接复制进证书，会扩大 ASN.1 解析面和策略错误面。

Profile 扩展把选择移到订单字段。草案的安全分析明确指出，除主题备用名称和主题公钥外，CSR 的其他内容不再需要参与这项策略选择。这让 CA 更容易根据自己的模板构造证书，而不是把 CSR 当作签发清单。

边界不能说过头。CSR 并非完全无关：公钥是证书核心，SAN 与订单授权的标识符相关。CA 仍须正确构造和签名证书、选择链、满足证书策略与适用的根计划要求，并在需要时提供透明度证据。

Profile 字段减少了共同协议所需的含混。最终是否做到，仍要看 CA 真正签出的字节。这正符合“最小初始规范”：共同层只规定必要的选择与错误语义，不把每个后续信任决定集中化。

客户端选择与服务端默认不是一件事

客户端显式提交 Profile 时，已签名的 ACME 请求能证明账户密钥授权了一份含该字符串的载荷。服务端仍须判断组合是否可接受。

当客户端省略 Profile、服务端又公布了多个选择时，草案建议服务端自行选定并绑定到订单。此时订单记录的是服务端默认，不是用户主动选择。界面若把两种路径都显示成“已选 Profile”，就抹去了决定权来源。

应记录 selector_origin：客户端还是服务端；同时保留客户端版本、配置来源、账户、请求载荷、订单响应、服务端策略版本，以及谁有权修改两侧配置。这样才能区分“订户主动提前迁移”与“客户端未变、默认策略在服务端改变”。

默认值的规模效应很大。Let’s Encrypt 用 Profile 分阶段移除 TLS Client Authentication EKU，并逐步引入更短证书寿命。早期使用者可以主动选择，之后默认 Profile 再变化。两种路径都可能合理，但责任主体与风险窗口不同。

账户资格、标识符控制和签发策略是三道门

若 Profile 与订单其余内容不兼容，服务端必须拒绝。草案举例包括：Profile 只适用于 TLS 服务证书，却搭配电子邮件标识符；或者账户不在相应 allowlist 中。建议的新错误类型是 invalidProfile。

这不是 ACME 域名授权本身。企业账户有资格使用私有 Profile，并不表示它已经证明每个域名的控制权；完成 DNS-01、HTTP-01 或 TLS-ALPN-01，也不表示账户有权申请受限的中间 CA 或过渡 Profile。

至少保存三份收据：为什么账户可用该 Profile；每个标识符如何被验证；CA 为何接受最终组合。外部账户绑定、合同、付费、事故审批或 allowlist 可以支持第一项；挑战记录支持第二项；实际证书与 CA 的签发记录支持第三项。

成功订单在用户眼中是一笔交易，在权力结构上却是一串不同授权。账户密钥的有效签名只证明 ACME 账户控制，不会自动证明域名控制或证书能力资格。

未公开 Profile 是有意保留的异常面

服务端“应当”拒绝未公布的名称，但草案允许特殊接受。例子包括事先线下约定的私有 Profile，以及大规模吊销期间为替换旧证书而临时接受已下线的 Profile。

这不是设计疏漏，而是连续性通道。它避免公共发现机制在企业协议或紧急替换时成为唯一权威。

由此可见，Directory 中不存在并不能证明 Profile 无效。公共目录和实际可接受策略可能有意不同。未公开订单需要更强收据：线下协议或事故编号、适用账户与标识符、批准者、起止时间、证书约束、替换目标、撤回路径，以及普通账户无法使用该通道的证据。

私有不等于违规；无从追溯才是治理风险。组织不必向所有客户端公开商业条款，但必须能在事后把异常签发连回一个有边界的授权决定。

Profile 退役有两只时钟

Profile 从 Directory 消失时，按它创建的订单可能仍未到期。草案直接处理这一冲突：如果 CA 在最终阶段已经不愿按该 Profile 签发，必须返回 invalidProfile；同时建议先让现存订单到期，再停止签发。

Directory 时钟描述新客户端此刻能发现什么。订单时钟从 newOrder 开始，经过授权直到最终签发，并有自己的期限。二者不能混为一谈。

迁移台账应记录：公布开始与停止、默认值变更、最后一次接单、最晚订单到期、最后一次成功签发、尚未完成的续期、替代 Profile 与客户端支持、紧急例外和实际失败。否则，客户端只会在流程尾部看到 invalidProfile，并误判为网络、CSR 或挑战问题。

更隐蔽的是名称不变而语义改变。CA 可在同一名称下调整寿命、EKU、授权复用或证书链。这可以是合理演进，却意味着旧文档截图无法证明新续期拿到了什么。每个订单都应冻结当时策略，并重新检查实际证书。

订单是承诺对象，DER 证书才是合规对象

被接受的订单说明服务端把名称绑定到交易。可独立检验的输出是证书本身。

合规检查应解析 DER，并与该 Profile 的版本化谓词逐项比较：SAN 集合与标识符类型、公钥算法和参数、Key Usage、Extended Key Usage、Basic Constraints、证书策略及 critical 标记、有效期、签发者、签名算法、可用链、序列号与编码规则、透明度材料，以及禁止或意外字段。

还要把证书连接回订单、授权记录与 CSR 公钥。否则只能证明“一张证书符合某策略”，不能证明“它就是这次订单的结果”。

面向人的说明足以帮助选择，却难以直接驱动自动验证。CA 可以额外发布机器可检查的 Profile 清单。这是本文提出的运行补充，不是草案要求。它不必把 Profile 变成中央目录，只需让订户用 CA 自己冻结的承诺检查 CA 输出。

每次续期都要重做。相同名称不保证相同策略版本、有效期、链或扩展集合。只验证 ACME 响应的自动化，验证了控制面，却跳过了凭证。

CT 与 CAA 是独立控制，不是缺失收据的替身

证书透明度可以证明证书或预证书进入日志。它不能证明订户选择了哪个 Profile、CA 是否遵守该 Profile，或证书是否上线。

CAA 可以限制哪些 CA 获准为域名签发，并在自身语义下约束账户或验证方法。它不选择 ACME Profile，也不证明签发结果的字段。

二者之所以有价值，正因为它们提供不同观察，而不是重复同一绿色状态。证书链也一样：CA 提供一条链，客户端可能根据本地信任库建立另一条路径。Profile 意图不能强迫依赖方接受。

上线以后，名称才遇到真实系统

签发后，证书必须与对应私钥一起到达正确端点。负载均衡、区域副本、密钥仓库、sidecar 与未重启进程会造成部分部署。续期任务成功，并不等于所有流量已换证。

把 DER 哈希与公钥哈希绑定到每个安装目标；从外部观察实际送出的证书；检查激活时间、SNI 或服务身份、链与旧证书退役；再用代表性依赖方测试。

完整链条是：发现 -> 冻结 -> 选择 -> 资格 -> 标识符授权 -> 绑定订单 -> 最终签发 -> 检查 -> 部署 -> 观察 -> 续期。

前一步可以完全有效，后一步仍可能失败。因此 Profile 不应生成一个总绿色灯，而应生成相互链接的收据。

Let’s Encrypt 证明迁移价值，也暴露时间问题

Let’s Encrypt 把 Profile 描述为验证流程与最终证书特征的集合。多数订户可让服务端自动选择，有特殊需求的操作者则可主动指定。

其 EKU 迁移先提供不含客户端认证 EKU 的 tlsserver，再改变默认 classic，并用临时 tlsclient 给需要更多时间的用户留出窗口。寿命迁移则让 45 天和 6 天证书先通过选择性 Profile 出现，之后再调整默认。

这是真实运行证据：Profile 可以把早期采用、默认迁移和有限兼容拆开，而不要求所有客户端同日升级。

它也说明标签必须带时间。寿命、授权复用、EKU 与可用性沿不同日程变化。现有资料不能证明每个订户都迁移成功，也不能证明每个列出的客户端支持所有 Profile。它证明的是一家 CA 正在把选择器用作迁移控制面。

建立 Profile 证据收据

收据应绑定 Directory 响应和说明哈希、Profile 名称与选择来源、账户及配置权限、标识符与公钥哈希、资格规则、ACME 授权记录、订单与到期时间、最终请求与 CSR 哈希、证书 DER、序列号、签发者、链、透明度材料、字段合规结果、安装目标、外部观察、客户端测试、续期日程、异常批准和回滚或吊销路径。

区分事实与结论。“订单回显 tlsserver”是事实；“证书符合 Profile 版本 X”是测试结果；“端点送出此 DER 哈希”是另一事实；“业务连续性目标达成”是更后面的运行结论。

共同协议可以继续保持小而清晰。每个参与者保存自己需要的证据。这比要求 IETF 注册表或 CA 名称替所有后续主体做决定更稳健。