-
-
Notifications
You must be signed in to change notification settings - Fork 33.9k
Description
- Version: v14.0.0-pre
- Platform: Windows 10 Version 1903 64-bit (OS Build 18362.657)
- Subsystem: crypto / tls
What steps will reproduce the bug?
Test Case 1: CRL
- Set
NODE_EXTRA_CA_CERTSenvironment variable to a root certificate file. - Call
tls.connect()and target a host that has a certificate signed off of the root certificate. Supply thecrloption.
Test Case 2: PFX
- Set
NODE_EXTRA_CA_CERTSenvironment variable to a root certificate file. - Call
tls.connect()and target a host that has a certificate signed off of the root certificate. Supplypfxoption.
Test Case 3: CA
- Set
NODE_EXTRA_CA_CERTSenvironment variable to a root certificate file. - Call
tls.createSecureContext() - Call
context.addCACerton the new secure context, passing it a different root certificate than the one specified inNODE_EXTRA_CA_CERTS. - Call
tls.connect()and target a host that has a certificate signed off of the root certificate specified inNODE_EXTRA_CA_CERTS. Supply thesecureContextoption.
How often does it reproduce? Is there a required condition?
Reproduces 100% of the time.
What is the expected behavior?
Root certificates specified in NODE_EXTRA_CA_CERTS should always exist in a SecureContext whenever the Node.js hardcoded root certificates exist.
What do you see instead?
In all three test cases, the TLS connection will incorrectly fail due the root certificate being untrusted. This occurs even though the necessary root certificate was specified in NODE_EXTRA_CA_CERTS.
Additional information
node_crypto.cc has multiple bugs where calls to SecureContext::AddCACert, SecureContext::AddCRL and SecureContext::LoadPKCS12 will create a new OpenSSL X509_STORE and fail to include the extra certificates.
These functions call NewRootCertStore(), which only loads the static root certificates and path-based system certificates.
I'll submit a PR with reproduction unit tests and a bug fix.