Point npm at the certificate authority that signed your mirror's certificate, using the cafile setting, and leave strict-ssl on. Turning strict-ssl off silences the error by disabling certificate validation for registry requests, which also removes your protection against someone impersonating the mirror.
Why the error appears
Your mirror probably uses a certificate from an internal authority, or a self-signed one. npm, like other clients, validates the server certificate against trusted authorities. If the internal authority is not in that trust store, validation fails and the install stops.
The settings involved
The npm config documentation lists these:
| Setting | Default | Meaning |
|---|---|---|
| strict-ssl | true | Whether to validate the certificate on https requests to the registry |
| cafile | none | Path to a file with one or more certificate authority signing certificates |
| ca | none | The authority certificate trusted for registry connections, PEM formatted with newlines written as backslash n |
| registry | public default | Base URL of the registry |
The cafile route is easier to maintain than the ca value, since you point at a normal PEM file and do not need to escape newlines.
The fix, step by step
- Get the root or intermediate certificate for your internal authority from whoever runs the mirror. You need the public certificate, never a private key.
- Save it as a PEM file in a stable path, for example under the user's config directory.
- Set cafile to that path in the user config for laptops, or in the CI image for pipelines.
- Run an install with a fresh cache to confirm it succeeds with strict-ssl untouched.
npm config set cafile /etc/ssl/internal/ca.pem
npm config get strict-ssl
npm view lodash version
The second command should print true. If a teammate's guide says to set it to false, replace the advice.
Why disabling validation is a bad trade
With validation off, npm will accept any certificate. On a hostile network, someone who can intercept traffic can present their own certificate and serve you modified packages. The integrity checksums in your lockfile help against changed tarballs, but not for new installs, new versions or metadata. Fixing trust takes ten minutes and removes the temptation.
Other tools have their own switches. The Node runtime offers a similar environment variable to disable certificate checks for a whole process, and its docs strongly discourage using it. If you see that variable in a Dockerfile or CI file, treat it as a finding.
Keep it tidy for a small team
- Distribute the authority certificate in your base image and laptop setup, so nobody has to improvise.
- Search repositories and CI definitions for strict-ssl set to false, and for the Node variable that disables checks.
- Put an expiry reminder for the mirror certificate in the team calendar. Many sudden CI failures are expired certificates.
- Prefer a certificate from an authority your tools already trust, if your mirror is reachable from a public name.
Where Safeguard fits
Safeguard's policies and gates can flag risky configuration changes in pull requests alongside dependency changes, so a disabled TLS check does not slip through unseen. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is strict-ssl false ever acceptable in CI?
Avoid it. Trust the authority instead, so CI keeps validating the mirror like every other client.
Should I commit the authority certificate to the repository?
A public certificate is not secret, but ship it in your base image so every project shares one copy.
Sources
Last reviewed: 19 October 2026.
