Codex CERT_HAS_EXPIRED 证书过期错误处理

错误现象

在使用 Codex 命令行或者通过 Codex 相关 SDK 调接口时，偶尔会遇到CERT_HAS_EXPIRED。这个错误一般不是代码逻辑问题，而是 HTTPS TLS 握手阶段证书校验失败。

常见报错长这样：

### token云桥中转 0029.org ### Error: certificate has expired code: 'CERT_HAS_EXPIRED' FetchError: request to https://api.openai.com/v1/... failed, reason: certificate has expired UNABLE_TO_VERIFY_LEAF_SIGNATURE CERT_HAS_EXPIRED

我一般先不急着改业务代码，先查三件事：本机时间、访问链路里有没有代理、系统 CA 证书是否过旧。多数问题都出在这三个地方。

先判断是不是本机时间问题

TLS 证书都有有效期。如果本机时间快了几个月，或者容器里的时间不对，正常证书也会被判断为过期。

Linux / macOS 查看时间

date date -u

如果是在服务器上，顺手看一下时区和 NTP 状态：

timedatectl timedatectl status

如果时间明显不对，先同步时间：

sudo timedatectl set-ntp true sudo systemctl restart systemd-timesyncd

macOS 可以在“系统设置 - 日期与时间”里打开自动设置，也可以检查：

sudo sntp -sS time.apple.com

如果是 Docker 容器里报错，要先确认宿主机时间正常。容器通常跟随宿主机，宿主机时间错了，容器里也会错。

确认到底是谁的证书过期

CERT_HAS_EXPIRED不一定表示 OpenAI 或 Codex 服务端证书过期，也可能是公司代理、抓包工具、网关、防火墙替换了证书。排查时要看实际拿到的证书链。

用 openssl 查看证书有效期

openssl s_client -connect api.openai.com:443 -servername api.openai.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

正常会看到类似：

subject=... issuer=... notBefore=... notAfter=...

重点看issuer和notAfter。如果 issuer 是公司内网 CA、代理软件 CA、某个安全网关，而不是公共 CA，那说明请求经过了 HTTPS 中间代理。这个时候修复方向就不是更新 Codex，而是处理代理证书。

用 curl 看握手细节

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

没有 token 时返回 401 是正常的，说明 TLS 至少通过了。真正需要关注的是前面有没有：

SSL certificate problem: certificate has expired

如果 curl 都过不了，Codex 基本也过不了。先修系统环境，不要在应用层绕。

常见原因和修复顺序

1. 系统 CA 证书太旧

老服务器、精简 Docker 镜像、很久没更新的开发机，比较容易出现 CA 根证书过期或缺失。

Debian / Ubuntu：

sudo apt update sudo apt install --reinstall ca-certificates sudo update-ca-certificates

CentOS / RHEL：

sudo yum reinstall ca-certificates sudo update-ca-trust force-enable sudo update-ca-trust extract

Alpine：

apk add --no-cache ca-certificates update-ca-certificates

macOS 如果是 Homebrew 环境，可以更新证书包和相关依赖：

brew update brew upgrade ca-certificates openssl

修完之后重新打开一个终端再试，避免旧进程还拿着旧环境变量。

2. Node.js 使用的证书链有问题

不少 Codex CLI 或调用脚本跑在 Node.js 里。Node 的 TLS 校验可能受环境变量影响，比如NODE_EXTRA_CA_CERTS、HTTPS_PROXY、SSL_CERT_FILE。

先检查环境变量：

env | grep -i proxy env | grep -i cert

如果看到类似：

NODE_EXTRA_CA_CERTS=/path/to/old-company-ca.pem SSL_CERT_FILE=/tmp/expired.pem HTTPS_PROXY=http://127.0.0.1:7890

就要重点看这些文件和代理。尤其是公司 CA 文件，很多人离职交接、换电脑、换 VPN 后一直没更新，最后表现出来就是CERT_HAS_EXPIRED。

临时排查时可以开一个干净 shell：

unset NODE_EXTRA_CA_CERTS unset SSL_CERT_FILE unset HTTPS_PROXY unset HTTP_PROXY unset ALL_PROXY

然后再运行 Codex 命令。如果恢复正常，就说明问题在代理或自定义证书链。

3. 代理或抓包工具证书过期

如果你使用 Clash、Charles、Fiddler、公司网关、VPN 代理，经常会碰到代理签发的本地证书过期。浏览器可能已经信任新证书，但命令行环境未必同步。

处理思路：

• 更新代理软件到较新版本；
• 重新生成并安装代理根证书；
• 确认 Node.js 或系统命令行能读取到这个根证书；
• 不需要代理时，先关闭代理再验证一次。

如果只是为了稳定调用接口，也可以考虑走一个维护较好的中转服务。我自己在排查网络和证书问题时，会把 token云桥AI中转站 0029.org 作为备选链路测试一下，至少能快速判断问题是在本机证书链，还是出站网络本身不稳定。

Codex 侧的检查

如果系统证书和网络都确认没问题，再看 Codex 工具本身是否过旧。先查看版本：

codex --version node -v npm -v

如果 Codex 是通过 npm 安装的，可以尝试更新：

npm update -g npm install -g @openai/codex

如果项目里固定了依赖版本，则在项目目录里更新：

npm outdated npm update

注意不要为了“先跑起来”直接设置：

NODE_TLS_REJECT_UNAUTHORIZED=0

这个变量会关闭 TLS 证书校验，只适合极短时间定位问题，不建议写进脚本、Dockerfile、CI 配置或系统环境变量。否则后面真正遇到中间人攻击或错误域名证书时，程序也会照样放行。

修复后的验证方式

修完不要只看 Codex 命令是否不报错，建议按顺序验证：

1. 验证系统 TLS

curl -I https://api.openai.com

能看到 HTTP 响应头即可，401、404 都不代表 TLS 失败。

2. 验证证书有效期

openssl s_client -connect api.openai.com:443 -servername api.openai.com </dev/null 2>/dev/null | openssl x509 -noout -dates

确认notAfter是未来时间。

3. 验证 Node.js HTTPS

node -e "fetch('https://api.openai.com').then(r=>console.log(r.status)).catch(e=>console.error(e.code,e.message))"

如果这里不再出现CERT_HAS_EXPIRED，说明 Node 的证书校验已经正常。

4. 再运行 Codex

codex --version codex

或者执行你原来报错的命令。此时如果变成鉴权失败、额度不足、模型不存在等错误，说明证书问题已经过去了，需要按新的错误继续排查。

避免复发的几个习惯

• 服务器和开发机开启自动时间同步，不要手动改系统时间后忘记恢复；
• 基础镜像里显式安装ca-certificates，不要用过旧镜像长期不更新；
• 公司代理证书到期前统一更新，命令行环境也要同步信任；
• CI/CD 里不要固定很老的 Node.js 和系统镜像；
• 不要长期保留NODE_TLS_REJECT_UNAUTHORIZED=0这类临时变量。

总结

Codex 遇到CERT_HAS_EXPIRED，优先按“本机时间、系统 CA、代理证书、Node 环境变量、Codex 版本”这个顺序排查。大多数情况下，问题不在业务代码，而在 TLS 证书链或出站网络链路。修复后用curl、openssl、Node fetch 和 Codex 原命令逐层验证，能更快确认问题是否真正解决。