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_CERTS
environment variable to a root certificate file. - Call
tls.connect()
and target a host that has a certificate signed off of the root certificate. Supply thecrl
option.
Test Case 2: PFX
- Set
NODE_EXTRA_CA_CERTS
environment variable to a root certificate file. - Call
tls.connect()
and target a host that has a certificate signed off of the root certificate. Supplypfx
option.
Test Case 3: CA
- Set
NODE_EXTRA_CA_CERTS
environment variable to a root certificate file. - Call
tls.createSecureContext()
- Call
context.addCACert
on 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 thesecureContext
option.
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.
Activity