intermediate CA certificate can be not trusted.

[kadinwu]

• Version: 12.18.2
• Platform: Linux
• Subsystem:

What steps will reproduce the bug?

1. Only add server intermediate CA certificate to trusted certs.
2. Trying to Connect to this server over tls, but got below error:

Error: unable to get issuer certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1496:34)
at TLSSocket.emit (events.js:315:20)
at TLSSocket._finishInit (_tls_wrap.js:938:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:696:12) {
code: 'UNABLE_TO_GET_ISSUER_CERT'
}

if add root CA certificate to trusted certs, then can connect to server.

How often does it reproduce? Is there a required condition?

What is the expected behavior?

Able to connect server over tls with server intermediate CA certificate trusted.
Or provider any option to support openssl partial_chain verify:
https://www.openssl.org/docs/manmaster/man1/openssl-verification-options.html

What do you see instead?

Additional information

[Trott]

@nodejs/crypto

[kaizhu256]

was bitten by this at work for couple months (during which disabled NODE_TLS_REJECT_UNAUTHORIZED=0 when i didn't know better).

eventually stumbled on solution trying to get curl to work as well. not sure whether this should be fixed or not, b/c curl has the same behavior (although both nodejs and curl need better documentation telling users they need to include the root-certifcate as well).

[mildsunrise]

This is expected behaviour and not a Node.js decision, but an OpenSSL one.
OpenSSL expects trust anchors to be self-signed certificates and ignores intermediate ones.
It can be changed with the X509_V_FLAG_PARTIAL_CHAIN flag which was added in v1.1.0:

The X509_V_FLAG_PARTIAL_CHAIN flag causes non-self-signed certificates in the trust store to be treated as trust anchors, in the same way as self-signed root CA certificates. This makes it possible to trust self-issued certificates as well as certificates issued by an intermediate CA without having to trust their ancestor root CA. With OpenSSL 1.1.0 and later and X509_V_FLAG_PARTIAL_CHAIN set, chain construction stops as soon as the first certificate contained in the trust store is added to the chain, whether that certificate is a self-signed "root" certificate or a not self-signed "intermediate" or self-issued certificate. Thus, when an intermediate certificate is found in the trust store, the verified chain passed to callbacks may be shorter than it otherwise would be without the X509_V_FLAG_PARTIAL_CHAIN flag.

Curl decided to enable it by default a year ago, see curl/curl#4655 for discussion. For curl it makes more sense because it's more agnostic of the TLS implementation, and the other backends do support intermediate certs as trust anchors.

Node.js is tied to OpenSSL, and changing a setting like this would have security implications, it would have to be semver-major at least IMHO.

[kadinwu]

This is expected behaviour and not a Node.js decision, but an OpenSSL one.
OpenSSL expects trust anchors to be self-signed certificates and ignores intermediate ones.
It can be changed with the X509_V_FLAG_PARTIAL_CHAIN flag which was added in v1.1.0:

The X509_V_FLAG_PARTIAL_CHAIN flag causes non-self-signed certificates in the trust store to be treated as trust anchors, in the same way as self-signed root CA certificates. This makes it possible to trust self-issued certificates as well as certificates issued by an intermediate CA without having to trust their ancestor root CA. With OpenSSL 1.1.0 and later and X509_V_FLAG_PARTIAL_CHAIN set, chain construction stops as soon as the first certificate contained in the trust store is added to the chain, whether that certificate is a self-signed "root" certificate or a not self-signed "intermediate" or self-issued certificate. Thus, when an intermediate certificate is found in the trust store, the verified chain passed to callbacks may be shorter than it otherwise would be without the X509_V_FLAG_PARTIAL_CHAIN flag.

Curl decided to enable it by default a year ago, see curl/curl#4655 for discussion. For curl it makes more sense because it's more agnostic of the TLS implementation, and the other backends do support intermediate certs as trust anchors.

Node.js is tied to OpenSSL, and changing a setting like this would have security implications, it would have to be semver-major at least IMHO.

Thanks for the quick reply.
By Default, X509_V_FLAG_PARTIAL_CHAIN flag is disabled is make sense for me. It is more secure, but it doesn't mean enable it is not secure. I just want nodejs can expose a way to set this flag.
just to confirm, in latest nodejs, there is no way to configure X509_V_FLAG_PARTIAL_CHAIN flag and pass to openssl, right?
If so, do you have any plan to support it?

[zipou]

Hello, I just bumped into this issue when I was trying to discover why my nodejs apps throw "UNABLE_TO_GET_ISSUER_CERT" with my certificate design (CA / Client Cert / Server Cert)

So to just ask agin the question of @kadinwu , will be any way of passing this the X509_V_FLAG_PARTIAL_CHAIN flag in a future release of nodejs ?

I did not find anything mentionning that in the documentation, but may be I missed it ?

Regards,

[mildsunrise]

AFAIK we have never exposed options for certificate verification (X509_VERIFY_PARAM) such as the flags in this case.
a priori I see it feasible and simple enough to do, but I haven't been very active at the project and I'm worried if it hasn't been done yet there's a reason for it. I couldn't find issues or PRs talking about it, so maybe there's just not been enough demand.

[bnoordhuis]

One reason is that it's practically guaranteed people are going to misuse it: google error message, copy first stack overflow answer, move on, herp derp, not understanding or caring about the security implications.

I mean, look at how often people abuse NODE_TLS_REJECT_UNAUTHORIZED to get around certificate errors. Adding it as an escape hatch when I turned on TLS verify-by-default is probably the biggest regret I have over the last 12-13 years.

[mildsunrise]

understandable, but by that rule we also shouldn't have exposed SSL options, protocol version, global keylog, etc. I'm not sure to what extent it's good to prevent perfectly legitimate use cases to protect users from themselves... maybe a middle ground here would be to only expose flag constants that have reduced potential for misuse, such as CRL_CHECK*, X509_STRICT, CHECK_SS_SIGNATURE, PARTIAL_CHAIN, but users would probably hardcode other constants anyway.

[galaxyfeeder]

+1 to expose an option that enables setting this flag for allowing trusting intermediate CAs

[schaefec]

This is very much needed in our product as well. We're making use of different TLS implementations. Looks like in all our cases we can configure a non-root certificate as a trust anchor (e.g. JSSE from Java allows this, the crypto/tls package in golang seems to support this, etc.) but nodejs doesn't.

+1 for exposing a parameter or a way to configure nodejs (snd with that openssl underneath) to accept non-root certificates as trust anchors.