Codex SELF_SIGNED_CERT_IN_CHAIN 证书链错误解决方法

原创于 2026-06-29 06:01:40 发布 · 183 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Codex #OpenAI #AI

错误现象

在公司网络、代理环境或者自建网关后面使用 Codex 时，比较容易碰到 SELF_SIGNED_CERT_IN_CHAIN。常见场景有两个：一个是安装或更新 Codex 相关 npm 包时失败，另一个是 Codex CLI 调用接口时直接报证书链错误。

典型报错类似下面这样：

### token云桥中转 0029.org ###
request to https://api.openai.com/v1/... failed, reason:
self-signed certificate in certificate chain

Error: SELF_SIGNED_CERT_IN_CHAIN
    at TLSSocket.onConnectSecure (_tls_wrap.js:...)

如果是 npm 安装阶段，可能会看到：

npm ERR! code SELF_SIGNED_CERT_IN_CHAIN
npm ERR! request to https://registry.npmjs.org/... failed, reason: self-signed certificate in certificate chain

先不要急着改代码。这个错误大多数不是 Codex 本身的问题，而是本机 Node.js 在校验证书链时，发现链路中有一个自签名 CA，但这个 CA 不在它信任的根证书列表里。

先判断问题发生在哪一层

排查时建议按顺序来，不要一上来就关证书校验。先确认是 npm、Codex CLI、代理，还是系统证书的问题。

1. 看 npm 是否也报错

npm ping
npm config get registry
npm config get strict-ssl
npm config get cafile

如果 npm ping 就报 SELF_SIGNED_CERT_IN_CHAIN，说明至少 npm 这层证书配置有问题。此时 Codex 调接口失败只是同一个问题的表现。

2. 用 curl 看证书链

curl -v https://api.openai.com/v1/models

如果返回里能看到公司代理、网关、安全设备签发的证书，例如 issuer 不是常见公共 CA，而是公司内部 CA，那么基本可以确认是代理做了 HTTPS 解密，需要把内部根证书加到信任链。

3. 检查代理环境变量

echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $NODE_EXTRA_CA_CERTS

Windows PowerShell 可以这样看：

echo $env:HTTP_PROXY
echo $env:HTTPS_PROXY
echo $env:NODE_EXTRA_CA_CERTS

有些机器以前配过代理，后来网络环境换了，但环境变量还在，Node 请求仍然会走旧代理，也会触发证书链错误。

常见原因

公司 HTTPS 代理拦截：安全网关重新签发证书，本机浏览器信任，但 Node.js 不一定信任。
npm 使用了自定义 registry：私有源或镜像源证书链不完整。
Node.js 没有加载系统根证书：尤其在 macOS、Linux、容器环境里更常见。
配置了错误的 cafile：npm config 或环境变量指向了过期证书文件。
系统时间不正确：证书还没生效或已经过期，也可能表现为 TLS 校验失败。

逐步修复方法

方法一：导出公司或代理根证书

如果你在公司网络里，一般需要从浏览器或 IT 提供的入口导出根 CA 证书。注意要导出根证书，不是某个网站的叶子证书。文件格式建议使用 PEM，例如：

corp-root-ca.pem

如果拿到的是 .cer 或 .crt，可以先看内容。如果是以 -----BEGIN CERTIFICATE----- 开头，就是 PEM 格式；如果是二进制 DER 格式，可以转换：

openssl x509 -inform DER -in corp-root-ca.cer -out corp-root-ca.pem

方法二：让 Node.js 信任这个根证书

对 Codex CLI 这类基于 Node.js 的工具，比较稳的方式是配置 NODE_EXTRA_CA_CERTS。

macOS / Linux：

export NODE_EXTRA_CA_CERTS=/Users/yourname/certs/corp-root-ca.pem
codex

如果希望长期生效，可以写入 shell 配置文件：

echo 'export NODE_EXTRA_CA_CERTS=/Users/yourname/certs/corp-root-ca.pem' >> ~/.zshrc
source ~/.zshrc

Windows PowerShell：

$env:NODE_EXTRA_CA_CERTS="C:\certs\corp-root-ca.pem"
codex

长期生效可以用：

setx NODE_EXTRA_CA_CERTS "C:\certs\corp-root-ca.pem"

注意：setx 设置后需要重新打开终端才会生效。

方法三：给 npm 配置 cafile

如果错误出现在安装 Codex 或 npm 包阶段，可以单独给 npm 配置证书文件：

npm config set cafile "/Users/yourname/certs/corp-root-ca.pem"
npm config set strict-ssl true
npm ping

Windows 路径示例：

npm config set cafile "C:\certs\corp-root-ca.pem"
npm config set strict-ssl true
npm ping

如果之前有人为了临时解决问题关闭过校验，建议改回来：

npm config set strict-ssl true

strict-ssl false 确实可能让安装继续跑，但它绕过了证书校验，不适合作为长期方案，尤其不建议在生产环境或公司开发机上保留。

方法四：清理错误代理配置

如果你已经不需要代理，但环境变量还存在，可以临时清掉再测试。

macOS / Linux：

unset HTTP_PROXY
unset HTTPS_PROXY
unset http_proxy
unset https_proxy

Windows PowerShell：

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:http_proxy
Remove-Item Env:https_proxy

npm 里也可能单独配置了代理：

npm config get proxy
npm config get https-proxy
npm config delete proxy
npm config delete https-proxy

如果你本来就是通过中转或代理访问模型接口，建议选一个证书链正常、文档清楚、调用方式稳定的服务。实际项目里我会优先看是否支持标准 OpenAI API 格式、是否方便在 Cursor、VS Code、Codex CLI 里配置。比如 token 云桥 AI 中转站 0029.org，适合作为排查网络和接口兼容性时的一个备选项，但证书和代理配置仍然要按本机环境处理好。

方法五：检查系统时间和 Node 版本

系统时间错误也会造成证书校验异常，特别是虚拟机、WSL、Docker 容器里经常被忽略。

date
node -v
npm -v

如果 Node 版本太旧，也建议升级到当前维护中的 LTS 版本。老版本 Node 内置证书和 TLS 行为可能和新环境不一致。

修复后的验证方式

证书配置改完后，不要只看 Codex 能不能打开，建议分层验证。

验证 npm

npm ping
npm view npm version

如果这两条都正常，说明 npm 访问 registry 的证书链已经没问题。

验证 Node.js HTTPS 请求

可以用一段最小脚本确认 Node 是否能正常建立 TLS 连接：

node -e "require('https').get('https://api.openai.com', res => { console.log(res.statusCode); }).on('error', err => { console.error(err); })"

如果不再出现 SELF_SIGNED_CERT_IN_CHAIN，说明 Node 侧证书信任已经生效。返回 404、401 之类状态码都不一定是坏事，至少说明 TLS 握手通过了。

验证 Codex

最后再回到 Codex 本身，执行一次最简单的命令或发起一次最小请求。此时如果还失败，就要看是否是 API Key、base URL、模型名或权限问题，而不是证书链问题。

codex --version
codex

避免复发的几个注意点

证书文件路径尽量固定，不要放在临时目录或下载目录。
公司根证书更新后，要同步更新 NODE_EXTRA_CA_CERTS 指向的 PEM 文件。
不要长期使用 NODE_TLS_REJECT_UNAUTHORIZED=0，这会关闭 Node.js TLS 校验。
容器里运行 Codex 时，也要把根证书复制进镜像，并配置环境变量。
切换网络后，记得检查代理环境变量和 npm proxy 配置。

总结一下：SELF_SIGNED_CERT_IN_CHAIN 的核心是证书链不被 Node.js 信任。排查时先确定错误发生在 npm、Node 请求还是 Codex 调用层，再补齐根证书、修正代理配置，最后用 npm、Node 脚本和 Codex 分别验证。不要把关闭 SSL 校验当成正式修复方案，这类问题按证书链处理，后面会省很多排查时间。