直接答案
证书错误是安全校验失败，不应通过关闭验证解决；先确认访问主机、系统时间、证书链和信任来源。
这篇内容解决什么问题
解决 certificate verify failed、unable to get local issuer certificate、CERT_HAS_EXPIRED 和主机名不匹配。
先确认症状与影响范围
客户端在发送 HTTP 请求前报告证书过期、未知签发者、主机名不匹配或证书链不完整。此时 API 通常没有收到业务请求。
浏览器能访问但 CLI 失败，可能因为两者使用不同信任库；只在企业网络失败，可能存在受管理的 TLS 检查代理。
- 确认 URL 主机名完全正确，没有使用临时 IP 或拼写错误域名。
- 检查系统 UTC 时间和时区是否准确。
- 确认错误只在某一运行时、容器或网络环境出现。
常见原因与责任边界
TLS 失败可能来自服务端证书链、客户端信任库、系统时间或企业代理。关闭证书验证会失去服务器身份保证并暴露 API Key。
- 证书过期、尚未生效或系统时间错误。
- 服务端未发送完整中间证书链。
- 请求主机名与证书 SAN 不匹配。
- 企业代理使用组织 CA，但当前运行时未安装受管信任链。
按层执行最小诊断
使用 openssl 或 curl 只检查公开证书元数据，不发送 API Key。记录 subject、issuer、SAN、有效期和验证结果，再与受影响运行时的 CA 配置对照。
企业网络中的自签或组织 CA 必须由管理员通过受管渠道安装，不能从错误页面下载未知证书后自行信任。
- 01确认时间检查系统 UTC 时间、NTP 和容器时间。
- 02确认主机使用公开接入文档中的 HTTPS 主机，不直接访问 IP。
- 03查看证书链记录签发者、SAN、有效期和 verify return code。
- 04对照信任库比较浏览器、系统、Node/Python 与容器使用的 CA。
HOST='<your-api-host>'
date -u
openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts </dev/null 2>/tmp/tls-debug.txt | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
tail -n 5 /tmp/tls-debug.txt
针对根因完成修复
服务端链不完整或证书过期应由服务运营方修复。客户端信任库过旧时通过官方系统或运行时渠道更新；企业 CA 由管理员按组织策略部署。
- 01纠正时间与域名恢复 NTP，并使用证书覆盖的正式主机名。
- 02修复证书链服务端配置完整 leaf 与 intermediate 链。
- 03更新信任库通过操作系统、容器基础镜像或运行时官方方式更新 CA。
- 04部署组织 CA仅由管理员分发和审计企业 TLS 代理证书。
验证修复而不是只看一次成功
验证应在原失败客户端、CI/容器和至少一个独立网络环境执行。所有环境都必须在开启证书验证时成功，并且证书 SAN 匹配目标主机。
- 系统时间正确，证书在有效期内。
- 证书链验证通过且 SAN 匹配主机。
- Node、Python、curl 和容器不依赖禁用验证的环境变量。
安全边界与升级证据
禁止使用 -k、--insecure、verify=False、NODE_TLS_REJECT_UNAUTHORIZED=0 作为修复。这些选项会让中间人读取 API Key 和业务数据。
- 不从聊天、网盘或未知网页安装根证书。
- 不把私钥或完整企业证书包上传工单。
- 临时调试设置在验证后立即删除。
官方来源与核验范围
本文以协议规范和客户端官方文档为事实依据。错误文案、重试头和配置字段可能随服务或客户端版本变化；执行前请核对来源，并对日志与请求样例脱敏。
查看技术核验方法