NODE_EXTRA_CA_CERTS vs strict-ssl=false for corporate proxy certificate errors

Question

When encountering SSL certificate validation failures while connecting to a private npm registry through a corporate intercepting proxy, two primary configuration paths exist to restore connectivity.

One approach involves setting strict-ssl=false in the .npmrc file to bypass certificate validation entirely. An alternative approach is to maintain strict validation but provide the proxy's root certificate via the NODE_EXTRA_CA_CERTS environment variable, allowing Node.js to trust the specific intercepting authority.

The primary constraint is balancing deployment speed against security posture in a production CI/CD pipeline where man-in-the-middle risks must be mitigated.

Which method is preferred for maintaining a secure chain of trust without disabling global SSL verification?
  Does NODE_EXTRA_CA_CERTS fully resolve validation issues for all npm registry interactions, or are there specific registry configurations where strict-ssl=false remains the only viable bypass?

Tasadduq Burney · Answer

Preferred approach
For a corporate intercepting proxy, the recommended way to restore trust while keeping SSL verification active is to set the NODE_EXTRA_CA_CERTS environment variable to the proxy’s root CA certificate (in PEM format). This tells Node.js to extend its built‑in trust store with that authority, so all TLS handshakes—including those made by the npm CLI—succeed without disabling verification.
Steps to apply

Obtain the proxy’s signing certificate (often available from your network team or by exporting it from a browser).
  Save it as a PEM file, e.g., /etc/ssl/certs/proxy-ca.pem.
  Set the environment variable before running Node or npm:
    # Linux/macOS
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/proxy-ca.pem
# Windows (cmd)
set NODE_EXTRA_CA_CERTS=C:\path	o\proxy-ca.pem
# Windows (PowerShell)
$env:NODE_EXTRA_CA_CERTS='C:\path	o\proxy-ca.pem'

Run your npm command or Node application again and confirm that the UNABLE_TO_VERIFY_LEAF_SIGNATURE (or similar) error disappears.

When strict-ssl=false might still be considered
Setting npm config set strict-ssl false disables verification only for HTTPS requests made by the npm CLI. It does not

You cannot obtain the proxy’s CA certificate (e.g., the proxy is managed by a third party that refuses to share it).
  You have verified that the proxy is not performing a man‑in‑the‑middle attack on the npm registry traffic (which is rarely safe to assume).

In most corporate environments where the proxy’s signing certificate is available, NODE_EXTRA_CA_CERTS fully resolves validation issues for all npm registry interactions, because npm relies on Node.js’s TLS stack. No additional bypass is needed.
Missing diagnostic detail
To be certain that NODE_EXTRA_CA_CERTS alone suffices, confirm whether the SSL error occurs only when running npm commands or also when your application makes outbound HTTPS requests (e.g., to internal APIs). If the error appears only for npm, the same proxy CA will still fix it; if it appears for other services, you may need to add additional CA certificates to the same variable.

NODE_EXTRA_CA_CERTS vs strict-ssl=false for corporate proxy certificate errors

1 answer

Preferred approach

Steps to apply

When strict-ssl=false might still be considered

Missing diagnostic detail

Your perspective belongs here.

1 question comment

When the corporate CA isn’t the system CA

But npm can point directly to a CA file too

When you still need `strict-ssl=false`

NODE_EXTRA_CA_CERTS vs strict-ssl=false for corporate proxy certificate errors

1 answer

Preferred approach

Steps to apply

When strict-ssl=false might still be considered

Missing diagnostic detail

Your perspective belongs here.

1 question comment

When the corporate CA isn’t the system CA

But npm can point directly to a CA file too

When you still need strict-ssl=false

When you still need `strict-ssl=false`