OpenAI API 开始支持 mTLS：API Key 没有消失，机器身份多了一道门

OpenAI API 开始支持 mTLS：API Key 没有消失，机器身份多了一道门

OpenAI 在 8 月 29 日将 Mutual TLS 和 X.509 workload identity federation 标记为 GA。常见 OpenAI API 调用验证服务端证书，再用 API Key 识别调用方；mTLS 增加客户端证书校验，使服务端还能确认请求来自企业认可的工作负载。

这项能力面向能安全保管私钥的服务器、Kubernetes 工作负载和企业网关，不适合把证书放进浏览器或移动应用。mTLS 不会自动替代 API Key、服务账号凭据或工作负载 Token；证书建立机器身份边界，Bearer 凭据仍负责调用授权。

mTLS 是双重校验，不是把 Key 换成证书

启用证书后，请求需要发送到 mtls.api.openai.com、美国区域的 mtls-us.api.openai.com 或欧洲区域的 mtls-eu.api.openai.com。客户端在 TLS 握手中提交证书链，同时像过去一样发送 Authorization 头。证书可在组织或项目层激活，项目级规则先于组织级规则检查；还可以用 CEL 对组织单位、DNS SAN 等证书属性做额外限制。

[OpenAI mTLS 文档](https://developers.openai.com/api/docs/guides/mutual-tls)提醒，区域 mTLS 主机的 API 路由和模型可用性可能不同，部署前要逐一测试实际使用的接口。OpenAI 不会从 AIA 地址补取中间证书，也不执行 CRL 或 OCSP 吊销检查。企业需要发送完整证书链，并通过停用、轮换和自有证书生命周期系统处理泄漏或离职等事件。

X.509 联邦才负责移除长期 API Key

若企业希望工作负载不再保存长期 OpenAI API Key，可以使用[X.509 工作负载身份联邦](https://developers.openai.com/api/docs/guides/workload-identity-federation/x509)。服务先用客户端证书在 mtls.auth.openai.com 交换一个短期 Bearer Token，再携带这个 Token 和符合策略的客户端证书调用 mTLS API。Token 最长一小时，不提供 refresh token，也不会超过证书剩余有效期。

身份联邦需要把证书属性映射到 OpenAI 项目中的服务账号，并仅授予工作负载需要的模型权限。它替换的是长期 API Key，调用阶段仍然同时验证 Token 与证书。文档还指出 Bearer Token 没有与某张证书做密码学绑定，因此证书私钥和短期 Token 都应被视为敏感凭据，日志不能记录证书内容、私钥或访问令牌。

当前 X.509 联邦面向 OpenAI API，Codex 不支持这条路径。Codex 工作负载应使用 OIDC Token 或 SPIFFE JWT-SVID，并遵循对应身份指南。团队若同时运行自研 API 服务和 Codex Agent，需要分别设计凭据流程，不能用一份 X.509 配置覆盖所有 OpenAI 产品。

经过 AI 中转站时，要问清证书终止在哪里

应用接入统一模型网关后，通常由网关代替业务服务调用上游模型。此时 OpenAI 看到的客户端是网关，mTLS 证书也应由网关的安全运行环境持有。业务服务到网关的身份验证属于另一段链路，可以使用企业内部 mTLS、OIDC 或签名 Key。把客户端证书内容塞进 HTTP Header 转发既不能完成上游 TLS 握手，也会扩大密钥暴露面。

采购或自建 AI 中转站时，应确认它是否支持上游 mTLS、私钥托管、项目隔离、无中断轮换和证书错误观测。若不支持，仅修改 Base URL 无法完成客户端证书握手。

AnyAIS 的统一模型接口可以减少多供应商差异。企业使用 OpenAI mTLS 前，应先核对网关能力和证书责任边界，在非关键项目完成重叠轮换与故障演练，再扩到组织级策略。机器身份还需与最小权限、短期凭据和审计共同生效。