The intercepting proxy does a number of things, one example is scanning incoming payloads for virus/malware signatures. Similarly if we follow other recommendations to use npm config set registry to use HTTP instead of HTTPS. That's one reason we want to correctly complete the trust chain - if we say 'ignore SSL errors' - then it opens a larger security hole (albeit, only internal to the network, but still). It's just hard to determine because of how much noise is on the Interwebs because of npm switching from a self-signed cert to not using one back in I think that's really only a concern if you have the private key to the intercepting proxy's CA cert. Maybe what we've come up with as workarounds is the best that can be done. Our npm operations are typically run via grunt or by the CI server, if that helps. Is there a way of having node/npm use the system's ca-bundle instead of something that's built-in? I've found while googling around for this, but I'm not sure how to use this to inject the custom cert. In general, we install the intercepting cert in /etc/pki/tls/certs/ca-bundle.crt and that makes things like curl and wget perfectly happy when accessing HTTPS URLs. In this case, the phantomjs module respects npm's strict-ssl setting, so using npm config set strict-ssl=false gets us around this, but that setting exists for a reason and that doesn't seem like a good idea, in general. That works until a module (like phantomjs) uses request during it's install process and complains the same as npm when it sees the intercepting cert (this time the URL is against bitbucket). I can use npm config set proxy to point at the non-SSL registry. Out of the box, npm complains about a self-signed cert.

I'm trying to figure out a 'good' way of handling the presence of an intercepting SSL proxy on our network.

Npm config set cafile