OneLinersCommand workbench
Verified diagnostic signature

npm issuer or self-signed certificate failure

This 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. Match this output from npm, then continue with sourced, read-only checks.

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

Signature matched locally

npm issuer or self-signed certificate failure

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

Likely causes

What usually produces this signal

  1. A log collector retained the symbolic code but omitted the original npm logger's request/reason line. The code is useful evidence, not proof of a complete causal diagnosis or of the default registry being the affected host.
  2. An explicit ca/cafile or configuration override selects an unintended trust set. In the actual paired experiments, different served lists produced different native codes against the same unrelated trust root; both succeeded with the independently known signing root.
  3. A collector or pasted excerpt conflates separate attempts, runtimes or hops. Keep timestamp, process and original code together; a foreign tool's similar words or a source label on another line must not establish npm provenance.
Safe next checks

Collect evidence before changing the system

01

Recover one original native event rather than treating the combined label as a root cause

# Original bounded private excerpt only; do not reproduce a mutating install.
node -p "JSON.stringify({node:process.versions.node,openssl:process.versions.openssl})"
npm --version
# Record the exact code, matching request reason, timestamp and runtime locally.
# A manually condensed npm diagnostic line is not an additional native npm log.

Expected signal: The owner can distinguish UNABLE_TO_GET_ISSUER_CERT_LOCALLY from SELF_SIGNED_CERT_IN_CHAIN and reconcile the request stage. A generic npm-related line or a collector summary without this original evidence cannot establish the failing CA/hop.

Native full code-line and request-reason entries have their own specific answers. This established fallback URL remains useful for short metadata, but does not authorize password changes, cache wipes, trust imports or TLS bypasses. Do not submit whole stderr, config or environment captures.

02

Establish the affected trust scope before distributing any certificate

# SAME affected npm context; metadata reads, not config writes.
npm config get strict-ssl
npm config get cafile
npm config get userconfig
# CA approval comes from its owner, not a failed connection or a copied chain.
# No npm config set, global trust import or retry of an unapproved endpoint.

Expected signal: The configuration owner can reconcile the selected process/project trust inputs with the independently approved CA and the original event. Null cafile does not mean verification is absent, and a non-null path does not prove correct contents or precedence.

Review CLI/environment/project/user/global overrides privately. First determine whether serving intermediates or distributing an intended CA is the demonstrated fix. The controlled root-selection examples preserve strict-ssl=true and do not establish real registry/proxy configuration.

Reproducible example

Check the input against the result

Input and result

npm diagnostic: UNABLE_TO_GET_ISSUER_CERT_LOCALLY
# Owner-written compact metadata from the actual isolated native issuer case.
# This first line is NOT claimed as an extra npm-emitted console format.
# Paired native code/request events and HTTP-stage counters were kept separately.
issuer_native=UNABLE_TO_GET_ISSUER_CERT_LOCALLY failed_http=0
peer_root_native=SELF_SIGNED_CERT_IN_CHAIN failed_http=0
leaf_only_native=UNABLE_TO_VERIFY_LEAF_SIGNATURE failed_http=0
self_signed_leaf_native=DEPTH_ZERO_SELF_SIGNED_CERT failed_http=0
approved_root_controls=2 verified_http_gets=2
compact_metadata_is_not_original_native_log=true

The four actual native failures had different served paths/trust inputs and sent no HTTP; the two approved-root controls reached the fixture GET. This explicit comparison explains why a combined label needs its original event. No code is fabricated as a production observation or silently normalized into another error.

Evidence-led recovery

Correct only the demonstrated cause

Route the confirmed original native code/reason to the relevant issuer/path investigation and review the demonstrated change with its configuration/trust owner. Preserve this legacy URL and default verification; do not choose a broad trust workaround from a condensed label.

Verify: The original npm context and affected hop validate with intended policy, and the evidence records which original code disappeared and which operation actually succeeded. A changed collector label or our isolated ping does not prove production package/recovery success.

Stop if: Only combined metadata remains, the source/runtime/hop cannot be established, different attempts are mixed, or a proposed action disables TLS checks, publishes credentials or changes global trust without approved scope and rollback.

Related signals

Other output patterns from this error family

npm UNABLE_TO_GET_ISSUER_CERT_LOCALLYnpm'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.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.