Summary: Facing a mysterious ‘CERT_HAS_EXPIRED’ npm error in your build pipeline? I’ll break down the real cause and provide three solutions, from the emergency hack to the permanent architectural fix every senior engineer should know.

Why Your CI/CD Pipeline Just Exploded: A Senior Engineer’s Guide to Expired Certificates

I remember it like it was yesterday. It was a Thursday night, around 10 PM. We were pushing a critical security patch for our main API. Everything passed QA, UAT, and my local machine. I merged the PR, grabbed my coat, and watched the GitLab CI pipeline kick-off. Green, green, green… then a soul-crushing red on the `npm-install` step. The error was cryptic and infuriating: npm ERR! code CERT_HAS_EXPIRED. The junior engineer on call immediately started pointing fingers at a new package we’d added. But my gut told me something else was wrong. This wasn’t a code problem; it was an infrastructure problem. This was the ghost in the machine, and it lived on our build runner, `prod-runner-us-east-1-c-spot-03`.

So, What’s Actually Happening Here? The Chain of Trust is Broken.

When your build agent runs npm install, it reaches out to a registry like registry.npmjs.org. That connection is secured with TLS/SSL. Your server needs to trust the certificate presented by the NPM registry. It doesn’t just blindly trust it; it verifies it against a list of trusted “Certificate Authorities” (CAs) stored on its own operating system. This is the “chain of trust.”

The problem is, these root CA certificates have expiration dates. When one of them expires, any SSL certificate that relies on it suddenly becomes invalid in the eyes of your un-patched server. It’s a silent, ticking time bomb. This is exactly what happened a few years ago when the DST Root CA X3 from Let’s Encrypt expired, breaking builds worldwide. Your code is fine. NPM is fine. But the trust store on your build agent is stale, and it’s refusing to make the connection.

And for the record, this has nothing to do with using jQuery in 2026. That’s a different, sadder conversation about tech debt we can have over beers sometime.

How to Fix This Mess: From Desperation to DevOps Excellence

I’ve seen this handled three ways in the wild. Let’s walk through them, from the one that gets you home at 3 AM to the one that ensures you’re never called at 3 AM for this again.

Solution 1: The “Get Me Out of This PagerDuty Alert” Fix

This is the quick and dirty way. You tell npm to just… not check the certificate. You’re essentially telling your package manager to close its eyes and trust whatever server it’s talking to. It’s fast, but it’s dangerous.

You can do this by running a command in your CI script right before npm install:

npm config set strict-ssl false
npm install

Darian’s Warning: I can’t stress this enough. This is a massive security risk. It opens you up to man-in-the-middle attacks where a malicious actor could impersonate the npm registry and inject compromised packages into your build. Only use this as a temporary measure to unblock a critical deployment, and create a high-priority ticket to implement a real fix immediately.

Solution 2: The “Do It Right on Monday Morning” Fix

The real problem is the stale list of CAs on your build server. The proper fix is to update it. You need to SSH into the specific build agent (e.g., `prod-runner-us-east-1-c-spot-03`) and update the certificate bundle using the OS package manager.

For Debian/Ubuntu systems:

sudo apt-get update
sudo apt-get install --only-upgrade -y ca-certificates

For RHEL/CentOS/Fedora systems:

sudo yum update -y ca-certificates

This will install the latest root certificates, re-establish the chain of trust, and your builds will start working again. This is a solid solution, but it’s reactive. It also means you treated that server like a pet, not cattle. What happens when the next runner spins up from the old, stale image?

Solution 3: The “Cloud Architect” Permanent Fix

This is where we move from being firefighters to being architects. The root cause wasn’t just an expired certificate; it was a mutable, unmanaged build environment. The permanent solution is to ensure your build infrastructure is built from regularly updated, immutable images.

The Strategy: Golden Image Pipeline

Instead of patching running servers, you create a separate pipeline that builds your “golden image” (whether it’s an AWS AMI, a GCP Image, or a Docker container) on a schedule.

1. Automate Image Creation: Use a tool like Packer or a simple Dockerfile.
2. Patch on Build: The very first step in your image-building script should be to update the OS and its packages, including ca-certificates.
3. Version and Deploy: Your new image gets a version tag (e.g., `my-app-runner:2024-05-21`). Your CI/CD configuration (like your EC2 Auto Scaling Group’s Launch Template or your Kubernetes Deployment manifest) is updated to use this new image.
4. Cycle the Fleet: Old runners are gracefully terminated and new runners are launched from the fresh, patched image.

Your Dockerfile might look this simple:

FROM ubuntu:22.04

# Run updates first thing to get latest security patches and certs
RUN apt-get update && apt-get install -y ca-certificates nodejs npm && rm -rf /var/lib/apt/lists/*

# The rest of your build agent setup...
COPY . .

This approach means you’re never more than a week (or whatever your build schedule is) away from having the latest patches. The “expired certificate” problem ceases to exist for your team.

Comparing The Approaches

At the end of the day, that late-night error was a gift. It was a painful but powerful lesson that your infrastructure is just as important as your application code. Treat it that way. Automate your patching, build immutable infrastructure, and you’ll sleep a lot better.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions