OpenAI mTLS 和 X.509 工作负载身份验证正式发布：每个网关运营商必须审计的清单

8 月 29 日，OpenAI 将双向 TLS（mTLS）和 X.509 工作负载身份联合（Workload Identity Federation）面向所有 API 组织正式发布。这两项功能默认处于关闭状态，属于主动选用。但只要组织管理员开启，所有转发该组织 API 流量的代理或网关就会变成必须持有证书的参与方。失败的表现不是 401 错误，而是 TLS 握手被直接拒绝，发生在常规凭据检查之前。

8 月 29 日正式发布了什么

OpenAI 同时发布了两个相互关联的安全特性。

双向 TLS 在 API 请求上增加了客户端证书验证。信任锚点上传并激活后——可在项目级或组织级生效——该范围内的所有请求必须通过 mTLS API 主机发送，并在 TLS 握手中出示被接受的客户端证书。OpenAI 先验证证书，再进行常规的 API 密钥或访问令牌检查。

X.509 工作负载身份联合复用上述 mTLS 信任锚点完成令牌交换。工作负载出示证书，换取短期 bearer token；后续请求同时携带该 token 和客户端证书访问 mTLS 主机。整个流程无需在工作负载中存储静态 API 密钥。

两项功能均通过新的 RBAC 权限（api.mtls.read、api.mtls.write）和一套证书管理端点进行管理：

• POST /v1/organization/certificates — 上传信任锚点
• GET /v1/organization/certificates — 列出组织内所有证书
• GET | POST | DELETE /v1/organization/certificates/{certificate_id} — 查询、更新或删除单个证书

启用前值得理解的五个运营后果

1. API 主机地址发生变化。 mTLS 强制执行依赖独立的 mTLS API 主机；指向标准 api.openai.com 的连接不受证书检查约束。需要出示客户端证书的网关必须将 base_url 或上游地址更新为 mTLS 主机，否则强制执行实际上被绕过，而不是被应用。

2. 网关必须持有私钥。 出示 TLS 客户端证书的工作负载必须能安全访问对应的私钥。终止 TLS 并向后端转发 HTTP 请求的网关需要自行管理这个密钥。透明 TCP 代理如果不终止 TLS，理论上可以透传证书，但必须专门配置才能做到。

3. CEL 过滤器实现工作负载级访问隔离。 每个信任锚点可以附带 CEL 过滤器，约束哪些已验证的客户端证书会被接受——表达式作用于 api.mtls.subject_dn（主题可分辨名称）和 api.mtls.san（主题备用名称）。这让运营商能在同一组织内将不同网关节点限制到特定的组织单元或主机名模式，而无需使用不同的 API 密钥。

4. 没有吊销检查机制。 OpenAI 不执行 AIA、CRL 或 OCSP 检查。证书泄露后的唯一处置路径是通过控制台或 DELETE /v1/organization/certificates/{certificate_id} 停用证书，轮换到新的信任锚点，然后重新部署持有旧私钥的所有网关实例。整个过程完全手动，需要跨网关节点协调。

5. 多项目网关必须将证书与项目对应。 OpenAI 先检查项目级证书，再检查组织级证书。同时为多个项目路由流量的网关，要么在独立的 TLS 连接上出示各自正确的项目级证书，要么统一回落到组织级证书。路由逻辑需要明确每个请求落入哪个证书作用域。

与 Anthropic 和 Google 认证模型的横向对比

对同时路由多个后端的网关运营商来说，跨服务商的对比有参考价值。

Anthropic 采用基于 OIDC 的工作负载身份联合：无需客户端证书，短期令牌直接从云身份提供商（AWS、GCP、Azure）换取。网关不持有私钥，持有的是可联合的云 IAM 身份。

Google Vertex AI 和 Amazon Bedrock 使用云原生 Managed Identity 或服务账号 JSON，模式相同：身份存在于云 IAM 平面，而非本地管理的证书中。

OpenAI mTLS 在基础设施层面要求最高——需要证书颁发机构、向每个网关节点分发密钥，以及在没有吊销支持的情况下进行手动轮换。但它对已有 PKI 基础设施的环境移植性最强：企业证书颁发机构、HashiCorp Vault PKI、AWS Private CA 或 GCP Certificate Authority Service 都可以直接对接。已经运营 PKI 并且有强气隙隔离或本地部署工作负载的团队，在这里能获得真实价值。

无密钥路径：X.509 工作负载身份的实际意义

对于愿意接受 PKI 要求的网关运营商，X.509 工作负载身份联合从根本上改变了架构选择。网关将自身证书提交给 OpenAI 令牌交换端点，换取短期 bearer token，再用这个 token 发起 API 调用——整个过程不存储任何静态 OpenAI API 密钥。密钥轮换变成证书轮换，大多数成熟基础设施环境已有现成工具链处理这件事。

这是本次正式发布中最值得关注的架构变化。仅使用 mTLS 路径，是在现有 API 密钥基础上增加第二因素；使用 X.509 工作负载身份，是彻底消除 API 密钥。

现在需要审计的路由配置

mTLS 默认关闭。除非你计划启用，或组织管理员在未与网关团队协调的情况下开启，否则当前不需要采取任何行动。但这个特性带来了一类新的静默错误配置。

将 base_url 硬编码为标准 api.openai.com 的网关，不会出示客户端证书，也不会被要求出示——它实际上绕过了强制执行。这既是故障模式（网关无法获得 mTLS 保护），也是无意中的逃生通道（组织启用 mTLS 后网关不会崩溃）。这个取舍是否可接受，取决于你的威胁模型。

计划采用 mTLS 的团队，建议按以下顺序操作：建立或复用证书颁发机构，为每个网关节点生成客户端证书，通过 POST /v1/organization/certificates 上传信任锚点，先在非关键项目上激活，再通过 mTLS API 主机发送测试请求，验证通过后才扩展到生产项目。

在任何组织管理员开启这项功能并造成意外硬性故障之前，把 mTLS 主机配置和客户端证书字段加入你的服务商凭据规范中。TheRouter 的服务商配置文档包含自定义服务商 TLS 设置的可用字段。