TLS requires certificate verification, and an essential part of this is verification that a certificate was issued by a pre-known “trusted” certificate authority (CA).

Browsers have the well-known certificates of reliable certificate authorities built-in, as well as the certificates of some known unreliable authorities. So does Node.js, but we don’t attempt to curate our own list; we use Mozilla’s because they have a well-defined policy for managing it.

This generally works well, it doesn’t require explicit configuration by Node.js users and Node.js will trust the same CAs across platforms and environments, as well as having behaviour that is generally consistent with browsers.

However, in closed environments, self-signed or privately signed certificates are commonly used, and rejected by Node.js since their root CAs are not known. Node.js supports explicit configuration of the trusted CA certificates using the JavaScript APIs, but this requires source code modifications which can be onerous, or impossible if the application being used (such as npm) isn’t under your control.

As of Node.js 7.3.0 (and the LTS versions 6.10.0 and 4.8.0) it is now possible to add extra well-known certificates to Node.js with an environment variable. This can be useful in cloud or other deployment environments to add trusted certificates as a matter of policy (as opposed to explicit coding), or on personal machines, for example, to add the CAs for proxy servers.

See the CLI documentation for more information on using NODE_EXTRA_CA_CERTS, as well as the original pull-request.

2 comments on"How to extend Node’s built-in CA certificate store using NODE_EXTRA_CA_CERTS"

  1. … [Trackback]

    […] Find More Informations here: developer.ibm.com/node/2017/03/02/extend-nodes-built-ca-certificate-store-using-node_extra_ca_certs/ […]

  2. […] Addressing key pain points for our customers – Examples include being able to easily configure command line options with NODE_OPTIONS, bundling Node.js into existing binaries through support for building as a shared or static library, and improving certificate chain handling. […]

Join The Discussion

Your email address will not be published. Required fields are marked *