OneLinersCommand workbench
Verified diagnostic signature

npm UNABLE_TO_GET_ISSUER_CERT_LOCALLY

npm's actual TLS verifier could not find an acceptable issuer in its selected certificate path. This native code is not an npm account/password rejection, an HTTP status or proof that the registry itself is down. A complete intermediate chain can still fail when npm's effective CA selection does not trust its root; a missing intermediate is a separate possibility that needs evidence. Match this output from npm, then continue with sourced, read-only checks.

Confidence
high
Platforms
linux · macos · windows
Verified
2026-10-01
Recognized output

Signature matched locally

npm UNABLE_TO_GET_ISSUER_CERT_LOCALLY

OneLiners matches this pattern in your browser. Your pasted output is not stored or indexed.

Likely causes

What usually produces this signal

  1. An intended private registry or authorized inspection path uses a root absent from this npm process's effective trust inputs. In the executed fixture, the server supplied its intermediate, but the explicit cafile contained an unrelated root.
  2. The peer omitted a required issuer, or the process selected an incomplete, overridden or unintended ca/cafile configuration. A browser or a different Node request may use different trust inputs; their success does not settle npm's path.
  3. The failing process reached an unexpected registry, redirect, tarball host or proxy. Keep the original target and certificate evidence private and reconcile them with the owner before any CA distribution or credential entry.
Safe next checks

Collect evidence before changing the system

01

Identify the emitting npm runtime and its selected verification configuration

# Run in the affected process/project context; keep paths private.
node -p "JSON.stringify({node:process.versions.node,openssl:process.versions.openssl})"
npm --version
npm config get strict-ssl
npm config get cafile
# Privately review selected ca/config overrides; no config-list or environment dump.

Expected signal: The original event contains UNABLE_TO_GET_ISSUER_CERT_LOCALLY. Runtime/config reads identify which process is under review and whether an explicit cafile is selected; a path or strict-ssl=true alone does not prove that the correct CA was loaded.

Do not clear the npm cache, reinstall Node or change credentials based on this TLS code. Review project/user/global/environment/CLI overrides without copying .npmrc, auth values or credential-bearing proxy URLs. Explicit Node ca replaces its defaults; an extra-CA environment setting cannot be assumed to override that explicit selection.

02

Separate an unavailable issuer from the wrong approved trust root

# OpenSSL 3.x; captured PUBLIC certificates and independently approved roots only.
openssl verify -no-CApath -no-CAstore -CAfile approved-roots.pem -untrusted captured-intermediates.pem -purpose sslserver -verify_hostname registry.example.test leaf.pem

Expected signal: The offline check preserves a numeric error and depth, or validates the intended path under the explicitly approved roots. Our npm control needed only the correct test root: the same server already sent its intermediate. Leaf-only output in a separate control produced UNABLE_TO_VERIFY_LEAF_SIGNATURE, not this code.

OpenSSL is supporting evidence, not a reconstruction of every npm/proxy/Node policy. Do not trust a root just because the failing peer sent it, or claim the live chain matches a local file. Check the actual original process and endpoint after an approved targeted repair.

Reproducible example

Check the input against the result

Input and result

npm error code UNABLE_TO_GET_ISSUER_CERT_LOCALLY
# Actual npm 10.9.7 ping against an owned 127.0.0.1 HTTPS fixture.
# Server sends leaf + intermediate. Explicit unrelated-root.pem is trusted.
# Empty fixture user/global npmrc, private cache, no retries/auth/install.
# Paired control changes ONLY that process's cafile to its known test root.
# strict-ssl=true, IP SAN valid, no system CA or registry configuration change.
native_code=UNABLE_TO_GET_ISSUER_CERT_LOCALLY
wrong_root_exit=1 http_requests=0
server_intermediate_present=true
approved_root_control_exit=0 http_get_ping=1
root_file_unchanged=true strict_ssl=true

Executed native TLS refusal, followed by a successful credential-free GET /-/ping using the independently generated signing root. No HTTP reached the fixture on the failed handshake. This proves the selected-root boundary of this fixture, not that adding a root is the correct repair for every real issuer failure.

Evidence-led recovery

Correct only the demonstrated cause

Correct the demonstrated server-chain deployment or obtain the intended CA through its policy owner and configure only the affected process/project scope. Investigate unexpected endpoints first. Keep strict-ssl and normal Node hostname/time verification enabled; do not globally trust a downloaded peer certificate.

Verify: The original npm operation verifies the intended endpoint with the reviewed CA/configuration, without validation bypass or credential exposure. Check relevant redirects/tarball endpoints separately; the controlled ping proves neither package integrity nor production installation success.

Stop if: The intended root or target cannot be authenticated independently, config precedence is unknown, the chain is unexpected, or the proposed fix disables TLS verification or distributes a CA globally without policy review.

Related signals

Other output patterns from this error family

npm SELF_SIGNED_CERT_IN_CHAINnpm found a self-signed certificate in the candidate path but did not establish it as an approved trust anchor. That differs from a self-signed leaf and from a server supplying only a leaf. A root being self-signed is normal; receiving it over the failed connection does not grant trust. Identify the issuer and policy before importing anything.npm HTTPS request failed: local issuer unavailableThis npm request-level wrapper identifies a particular HTTPS hop whose TLS path could not be authenticated. It is not an HTTP error from the package API: in the executed issuer case no HTTP request reached the fixture. Read the original selected URL and underlying code privately; the configured default registry does not identify every possible artifact, redirect or scoped-registry hop.npm HTTPS request failed: self-signed path rootThe npm HTTPS wrapper ties a self-signed-path refusal to the selected request hop. It is not proof that every self-signed certificate is defective, nor that the package itself is unavailable. Compare the actual npm process's approved CA selection with that hop's public path before changing a proxy, registry or application bundle.npm issuer or self-signed certificate failureThis compatibility event preserves an npm TLS code without the full native code-line or request-reason frame. The two retained codes describe different path-building evidence: an unavailable issuer versus an untrusted self-signed candidate in the chain. Recover the original selected event before choosing a repair; compact metadata cannot prove which endpoint, trust scope or certificate was involved.