1. 报错现场先把问题看清楚1.1 两个报错到底长什么样做前端和 Node 开发的同学大概率都撞到过这么一堵墙npm install跑到一半控制台突然冒出一行红色 error头一句话就是npm ERR! request to https://registry.npmjs.org/xxx failed, reason: certificate has expired换成 yarn 也有对应版本报错信息反而更像“验证失败”而不是“下载失败”error An unexpected error occurred: https://registry.npmjs.org/xxx: certificate has expired.有些场景下你看到的变体还会是另外几行unable to verify the first certificate self-signed certificate in certificate chain certificate is not yet valid先说结论这绝不是“网络抽风”也不是 node_modules 损坏更不是某个包被删了。它属于非常典型的 TLS 证书校验失败而且既然 npm 和 yarn 同时报错大概率是这套运行环境里的证书信任链、系统时间或者注册源配置出了问题。你别急着去清缓存、换镜像、删 lock 文件先把报错读明白后面每一步才有的放矢。1.2 为什么 npm 和 yarn 会同时中招很多人的第一反应是npm 有问题那我试试 yarnyarn 有问题那我试试 cnpm 或者 pnpm。结果换了一遍全都倒在同一个坑里。这其实不是巧合。npm 和 yarn v1 都是跑在 Node.js 上的包管理器网络请求底层用的都是 Node 内置的tls模块。就算是经过重构的 yarn berry最终发起的 HTTPS 请求也还是落在 Node 的 HTTP 客户端上。也就是说它们共享同一套验证栈、同一个 CA 信任库、同一个进程里的时间判断。真正影响结果的往往是那些更“底层”的东西操作系统信任的根证书有没有更新、Node 进程拿到的证书链是不是完整、系统时间是否偏离真实世界。一旦其中任何一环出问题npm 和 yarn 都会表现出一模一样的“证书过期”症状。先明白这一点后面定位问题才能少走弯路。2. HTTPS 证书验证链路拆解2.1 TLS 握手时客户端到底在“验”什么HTTPS 不是简单地把 HTTP 包塞进加密通道里它首先要经过一次 TLS 握手。握手期间服务器会把自己的证书发给客户端客户端需要确认三件事证书是谁签发的、证书能不能用来证明眼前这个域名、证书当前是否有效。放在生活里类比就是你去一个单位办事对方递给你一张工牌。你要做的不是看这张工牌设计得多精致而是确认它是不是被授权机构签发、上面的姓名岗位是不是眼前这个人、以及这张工牌有没有过期。证书校验的关键动作发生在 TLS 握手的 Certificate 阶段。此时客户端拿到的不只是一张叶子证书还有一长串证书链。校验链路大致是叶子证书是否在有效期内叶子证书的签名是否由上一级 CA 证书签出逐级往上直到找到一个客户端本地信任的根证书域名是否匹配叶子证书中的 SAN 或 CN附带检查证书是否被吊销部分方式下。任何一步不通过整个 TLS 握手失败请求被终止。npm 和 yarn 看到的就是这个终止结果。2.2 证书信任链凭什么成立中间证书为什么容易掉链子证书链由三层构成根证书、中间证书、叶子证书。根证书一般预埋在操作系统或运行环境里中间证书由 CA 签发叶子证书才是真正绑定某个域名的那个。这里有个常见的坑服务器配置证书时只放了叶子证书没有把中间证书一并返回。客户端拿到叶子证书后发现它的签发者在本地没有记录又找不到下一级证书可以继续追查就只能报“unable to verify the first certificate”或“self-signed certificate in certificate chain”。哪怕本地根证书完全正常只要服务器没把完整的 chain 发过来验证照样失败。很多内网私有源就是这么出问题的换源时只看域名能 ping 通却忽略了证书链是否完整。2.3 有效期检查的时间到底是谁的时间证书里有两个时间字段notBefore和notAfter。前者表示证书什么时候开始生效后者表示证书什么时候作废。校验逻辑非常朴素取系统当前时间判断是否落在[notBefore, notAfter]这个区间内。问题就出在“系统当前时间”这六个字上。客户端比较用的不是某个权威时间服务器的标准时间而是本机系统时间。如果本机时间落后了一张还没到期的证书可能被判定为“已经过期”如果本机时间超前一张还没生效的证书也可能被判定成“尚未生效”。虚拟机环境尤其容易踩雷。宿主机休眠一段时间后虚拟机的时钟会漂移刚克隆出来的虚拟机时间没有同步某些容器镜像打包时间太早系统时间卡在几个月前。等npm install一执行日期对不上证书自然报效。3. npm/yarn 为什么对证书这么敏感3.1 包管理器不是简单的“下载文件”有人不理解我只是装个依赖包为什么会牵扯到证书过期换个角度想npm 和 yarn 从远程仓库拉取时走的是一整套 HTTPS 请求而不是普通 FTP 拷贝。它们要发送登录凭据、读取包元数据、校验完整性这些操作都建立在加密连接之上。更关键的是包管理器对安全的要求比普通浏览器更高。浏览器访问网站时哪怕证书警告很多人也会点“继续访问”npm 和 yarn 则默认开启严格验证只要证书栈报错请求就直接失败没有商量余地。这其实是故意设计的否则中间人可以在包传输过程中注入恶意脚本最终变成供应链攻击。所以前面我说别因为报错就急着猜测是包被删、镜像被封、网络断线先查证书本身。3.2 Node.js 到底信任哪些根证书由版本和环境共同决定老实说Node.js 在不同平台、不同版本上的根证书来源并不完全一致。在 Windows 和 macOS 上新一点的 Node 版本会倾向于直接对接系统证书库你用“证书管理器”往系统里加一根证书Node 进程通常也能感知而在 Linux 服务器上Node 的运行环境更依赖系统安装的 CA 证书包比如ca-certificates这个软件包。这就造成一个很微妙的差异同一张内网根证书Windows 上导入系统信任库之后 npm 立刻就好Linux 上却要等到 CA 包更新、环境变量重启之后才生效。再加上有些 Node 发行版使用预先内置的 CA 列表即使服务器上已经更新了系统证书Node 进程读的仍然是启动时加载的那份列表。所以升级 Node 版本后有时候会突然多出一批“找不到证书”的报错根因就在这里。3.3 内网代理和自建镜像放大了证书问题企业内网经常会把 npm 请求收敛到一个自建的仓库或代理中间层客户端配置指向内网域名而不是公网原生源。这种方案本身没问题问题往往出在这套内网域名自己的证书上。一种情况是内网域名用了一个自签根证书签发的证书客户端机器上却没有安装这个自签根证书。于是一连上去就报“unable to verify the first certificate”。另一种情况是内网证书原本没过期但签发它的中间证书过期了或者代理服务器更新后把中间证书漏配了结果表现仍然是“certificate has expired”。更隐蔽的是如果代理中间层之后还有一层代理每一层都有自己的证书信任判断任何一层时间偏了、证书链断了最终反馈到 npm 上都是同一句 certificate has expired。这也是为什么同一个项目同事电脑上好好的你这边就是不行因为本地信任库、系统时间、代理配置全都不一样。4. 三步定位证书过期问题4.1 第一步校准系统时间排除假警报先看时间往往是最省时间的排查动作。终端里执行date再顺手跑一下 UTC 时间date -u如果系统时间确实偏了而且差得不多立刻把自动同步打开。Linux 环境可以这样处理sudo timedatectl set-ntp trueWindows 用户直接打开“设置 → 日期和时间 → 自动设置时间”点一下同步就行。关键是同步完之后要让正在运行的 Node 进程重新加载因为有些进程会缓存系统时间单纯改了时间以后旧进程可能仍然沿用之前的判断。保险起见把当前正在跑 npm/yarn 的终端关掉重新开一个新的再试。这一步做完如果还是报错再往下走。4.2 第二步用 OpenSSL 直接探测目标证书不要只盯着 npm 和 yarn 的报错文案可以直接绕过它们用 OpenSSL 和注册源服务器做一次原始 TLS 握手把服务器实际下发的证书拎出来看openssl s_client -connect registry.npmjs.org:443 -servername registry.npmjs.org /dev/null 2/dev/null | openssl x509 -noout -dates -subject -issuer这段命令核心是-servername它会把 SNI 信息带上让服务器返回正确的域名证书。如果你漏了这一步直接连 IP服务器可能下发一张默认证书日期看起来对不上会误导排查方向。输出里会看到notBefore和notAfter两行拿它们和本机时间对一下立刻能判断是证书真过期了还是时间错了。如果当前访问的是内网注册源就把命令里的域名换成内网域名端口也根据实际配置改比如很多工具默认不走 443可能是 8443 或 8081。4.3 第三步按症状分类不折腾瞎操作拿到探测结果之后基本可以按下面这张表快速归位现象更符合哪一种原因后续动作证书notAfter已经是昨天或更早服务器证书确实过期联系维护方续期客户端临时换可用源恢复工作证书notBefore比当前时间还靠后本机时钟落后或服务器时钟超前校准时间重启 Node 进程再试OpenSSL 看证书没问题但 npm/yarn 报错中间证书缺失或本地信任库不完整补中间证书/根证书重试并重启终端同一个域名时好时坏负载均衡后面有多台节点其中一台证书过期逐一检查节点证书重点看冷门节点刚改过电脑时间紧接着就报错时间跳变导致证书有效期判断错乱同步时间后重启终端和历史进程这里要特别提醒一句很多人在“时好时坏”的情况下会反复换镜像其实换镜像等于绕开了原服务器症状当然会消失但真正有问题的节点还留在那儿下次一段请求打到它身上报错又会出现。定位问题时一定要先确认是不是多节点场景里的某一台掉链子。5. 解决方案全集与避坑参考5.1 服务器端证书确实过期怎么处理如果定位结果是注册源自己的证书过期那就不是本地能修复的了。你自己维护的仓库或代理中间层需要先给域名续期证书然后重新配置 Web 服务或仓库服务把完整的证书链加载进来。实操里建议把“服务器证书 中间证书”按顺序拼接成一个.pem文件再部署到 Web 服务器上。常见操作顺序是为域名重新申请证书拿到fullchain.pem确认里面不只包含叶子证书把证书文件上传到服务器的指定目录修改 Web 服务配置指向新证书和私钥重启服务再用openssl s_client探测一次确认notAfter已更新且verify返回正常。如果问题出在公共注册源你没有权限操作它的服务器那就只能等对方更换证书或者临时切换到一个证书状态正常的镜像源。切换前可以用同样的 OpenSSL 命令把新源的证书也验一遍别换了个有问题的源白折腾。5.2 内网根证书缺失把 CA 补进信任库内网自签或企业 CA 签发的证书客户端必须信任对应的根证书才可以释放报错。给系统补一根根证书操作并不复杂但平台不同写法不同。Linux 上把根证书存成.crt文件放到/usr/local/share/ca-certificates/然后执行sudo update-ca-certificatesWindows 上可以用证书管理单元导入运行certmgr.msc进入“受信任的根证书颁发机构”导入.crt文件。macOS 则是通过钥匙串访问把证书加到“系统”分类里并设为始终信任。如果不想动系统级信任库还有一个只对 Node 进程生效的办法使用NODE_EXTRA_CA_CERTS环境变量指向一个包含自制根证书的.pem文件。这样既不会影响本机其他软件又能在不污染全局配置的前提下让 npm/yarn 认识这根新 CA。export NODE_EXTRA_CA_CERTS/path/to/my-ca.pem注意这个变量只是“额外”追加信任证书不会替代默认的 CA 列表所以原来有效的证书验证依然有效。5.3 临时绕过 strict-ssl 的边界在哪里网上很多帖子会教你直接关掉严格验证npm 有npm config set strict-ssl falseyarn 有yarn config set strict-ssl false。这个操作确实能让报错瞬间消失但我必须诚实地说它没有解决任何实际问题只是跳过了验证环节。严格验证关闭后客户端在 TLS 握手阶段不再校验证书是否受信任。数据加密依然是加密的但客户端不再确认服务器身份中间人完全可以挂着相同域名把流量截走再伪装成合法服务。在安装依赖的场景下这等于把包内容的安全性拱手让人风险比普通网页访问大得多。如果你是做短期应急例如内网证书马上更新但当前任务不能等那请你把关掉验证当成一次“定点手术”而不是长期改配置。操作之后等任务结束立刻恢复npm config set strict-ssl true还有一点很容易被忽略strict-ssl false是存在用户配置文件里的不会随着某个项目结束自动变回来。等你把证书问题修复完如果忘了恢复那你的包管理器就会一直处于裸奔状态。这种默认不改回来的配置我看过太多人踩过。5.4 切换注册源时重点关注证书链而不只是访问延迟遇到证书过期很多人第一反应是切换到备用源。切换本身没问题但要在切换之前验明新源的证书状态而不是盯着下载速度一通操作然后继续报错。选新源时可以用 OpenSSL 把目标域名验一遍确认证书链完整再写入配置openssl s_client -connect your-mirror.example.com:443 -servername your-mirror.example.com /dev/null 2/dev/null | openssl x509 -noout -dates -issuer注意这里域名对证书也同样讲究。很多所谓“镜像”实际上是一个反代服务如果反代自己没有配好证书或者反代背后的源节点有问题即使名字看着没问题还是会在某一时刻报错。切换到新源之后顺手跑一次npm ping用真实请求验证整条链路比任何参数配置都靠谱。6. 长期习惯别让证书问题反复找上门6.1 用脚本定期给关键域名做证书“体检”证书过期这种事几乎不会提前写在某个面板的首页提醒你只会在一个月黑风高的部署夜晚突然冒出来。我自己的习惯是写一个小脚本定时检查几个关键域名的证书有效期低于阈值直接提醒自己。下面是一个简单的 Linux Bash 版本核心就是前面说的 OpenSSL 探测逻辑#!/usr/bin/env bash check() { local domain$1 local enddate expiry now left enddate$(echo | openssl s_client -connect ${domain}:443 -servername $domain 2/dev/null | openssl x509 -noout -enddate 2/dev/null) if [ -z $enddate ]; then echo [error] ${domain}: 无法获取证书 return fi expiry$(date -d ${enddate#notAfter} %s) now$(date %s) left$(( (expiry - now) / 86400 )) echo ${domain}: 证书有效期剩余 ${left} 天 } check registry.npmjs.org check your-mirror.example.com check github.com在 macOS 上date -d的语法不通用但你可以把enddate那行直接打出来看效果也一样。重点是让这个脚本进入自己的例行检查清单比如配合定时任务每周跑一次证书还剩一二十天的时候你就能提前准备续期而不是等它炸掉。6.2 升级 Node 之后留意 CA 行为变化Node 版本升级带来的不只是语法特性和性能提升还包括 TLS 相关行为的调整。不同版本对系统 CA 库的读取机制有差异同一个项目在旧版本上一切正常升完级之后突然报 certificate has expired这种情况并不罕见。原因往往是旧版本从固定的 CA 列表读取根证书新版本切换到系统证书库。如果你的内网根证书没有正确装进系统信任库新版本根本不认识它于是证书验证全部失败。解决办法不是降级 Node而是老老实实把内网 CA 装进系统信任库再用NODE_EXTRA_CA_CERTS做环境级兜底。我建议团队在升级 Node 版本前先在一个隔离环境里跑一遍完整的依赖安装流程把证书相关报错提前暴露出来。尤其是那些用了自建源、内网代理的团队这一步能省掉大批人员升级后集体卡在安装阶段的尴尬。6.3 一个反复出现的真相关掉验证不等于修复证书类报错最容易让人烦躁因为它的修复链条很长牵扯系统时间、本地信任库、服务器证书、代理配置好几层。很多人最后会选择“让我能装上东西就行”的策略于是永久关闭严格验证再顺手把这条经验写进团队文档。短期看问题确实没了长期看却是把风险埋在了每一次安装依赖的动作里。我更建议的做事方式是把这次报错的现场证据留下来比如 OpenSSL 探测的输出截图、系统时间状态、Node 版本、local CA 列表位置然后按第 4 节的三个步骤逐一排除。大多数时候结果并不复杂要么时间偏了要么中间证书丢了要么内网根证书没装。真正负责的修复方式是把这些根因对齐而不是让“跳过验证”变成团队的默认习惯。我在实际排查中还有一个挺管用的细节如果捣鼓了半小时仍然找不出原因就把本机时间、系统证书库状态和注册源域名摘出来放到三次验证里各测一遍大多数问题都能定位到这三者交界处。证书基础设施没有那么多玄学数据和链条摆清楚答案自然就会浮出来。