Repository navigation
Node uses an hardcoded list of certificate authorities #4175
Description
Activity
Indeed, a distribution like debian needs to work around that using that kind of patch.
I already asked this in
#3159
I suppose a pull request could make it now ? @fir4 feels like writing one ?I think the simplest thing to do is to have a configurable path as a build option - so that each distributor can point nodejs to the right place where it can find the system-installed root ca(s).
I don't think it's worth the time spent to be able to change that path at runtime.Yeah, those were simple ideas, in case you'd want more flexibility. Using a configurable path on ./configure step would be a great start, however I have literally zero idea how Certificates are handled on MacOS and Windows...
For Windows it's too complicated. It's not just a folder. I'm thinking of a solution... Have a download link to an automatically generated zip file with the CAs. Bundle the current version with each distribution of nodejs. Add an environment variable to nodejs to locate the CAs folder. The installer will extract CAs to a proper location and set the environment variable. For Unix-like systems, the installer may try to locate system CAs. If no installer, this will have to be done manually.
EDIT: By default, use a build option like kapouer mentionned.
+1
👍
This is a major issue for commercial deployment of nodejs and a major obstacle to our node based software being adopted by large organizations that have their own in-house PKI. It is also indicative of a problem with the node developers lack of understanding of the importance of doing security "right".
I am very interested in seeing this issue get resolved and if there are sensible ways I can contribute to its resolution, please someone from the NodeJS team let me know (yes, a PR, I realize, but if there is any guidance on how to put that together or other considerations/constraints...)
It is also indicative of a problem with the node developers lack of understanding of the importance of doing security "right".
Please.
yes, a PR, I realize, but if there is any guidance on how to put that together or other considerations/constraints...
Start with reading CONTRIBUTING.md. If you still have questions afterwards, I can probably answer them.
Please.
Please as in, "please fix this" or "please, it is a super good idea to hard code the list of certificate authorities? "
this is outright unusable... and i can't stress enough the security implications for many organisations.
+1.
Reacted by Nathan Phillip Brink, Stephen Pittman, Artёm Basov, Michael, Danilo Morães, Isaac Ortega and rob thijssenReacted by vonj and Ethan BrewsPlease as in, "please fix this" or "please, it is a super good idea to hard code the list of certificate authorities? "
I Think that was a "Please do not assume things".
I Think that was a "Please do not assume things".
Thank you for clarifying.
One major problem of security is, that most people do not know, how to do it right and do not see all the problems which may arise.
I agree. Thanks for taking the time to explain.
7 remaining items
I don't get that attitude. You feel strongly enough to complain about it on the bug tracker, apparently strongly enough to switch to a different language but not strongly enough to spend an hour or two on a pull request. The whole point of open source is that you can change it if you don't like what it does.
Reacted by Rich Trott, Aaron Zollman, Sander Tolsma, Pablo Fernandez, Gibson Fahnestock, Philip Jackson, Ian Taylor, Gavin Golden, Lloyd Brookes, Joachim Schirrmacher and 23 moreReacted by wcgcoder, Adam Quinn Snow, Sami and Fakhrulhilal MI have proposed a solution and I think it will be more productive if others do the same or make a pull request instead of just bumping the thread.
Had similar issues with this, have internal apps using an internally signed cert.
Opted to usehttps.globalAgentand set an array of CA's which are defined in a config and updated on an env basis.E.g.
const trustedCa = [ '/etc/pki/tls/certs/ca-bundle.crt', '/path/to/custom/cert.crt' ]; https.globalAgent.options.ca = []; for (const ca of trustedCa) { https.globalAgent.options.ca.push(fs.readFileSync(ca)); }
Reacted by Lsong, Chad Kirby, Enrico Regge, gannons, James Hedley, mohangopineni, Fabiel Leon and Noman MaqsoodReacted by Thomas Simoens, Ben Redman, Bardi Harborow, Enrico Regge and lorenzo-wang-98It turns out that
https.requestmodule withcaoption doesn't support having multiple certificates inpemfile. @DuBistKomisch solution solved this problem. I'm using node v4.Reacted by miguel, quetzalcoatl and gannons@jan-swiecki In #4175 (comment) you mention that
It turns out that https.request module with ca option doesn't support having multiple certificates in pem file
Its not clear if you are talking about a user-land module, but if you are talking about node's
https.request()method, I did a some testing, and it supports concatenated PEM certificates inoptions.cain node 6.x (which I expected from reading the code), but not node 4.x.If you can't upgrade, open an issue about it and make the case that this is a feature that should be back-ported to 4 from 6. I'm not sure what the current stance is on back-porting features, but if its low risk, it may be possible.
Reacted by Jan Święcki and Nathan GrassSetting https.globalAgent.options.ca works for connections to my own server but causes SSL errors for regular connections (which normally work when https.globalAgent.options.ca isn't set). Is there a way to get https.globalAgent.options.ca to append to the default list of certificates used by node?
Reacted by Quang Trung NGUYEN and vicharzbecherNot programmatically, but with env configuration it is: https://nodejs.org/api/cli.html#cli_node_extra_ca_certs_file
Reacted by Lukas Hauser and vicharzbecher@mwain just wanted to understand will
https.globalAgent.options.ca.push(fs.readFileSync(ca));override the globally trusted Nodejs certificates (the Mozilla certificates which come bundled with nodejs as default trusted CA) ?
and my second concern is will it impact some performance issue?Looking forward to your reply
Had similar issues with this, have internal apps using an internally signed cert.
Opted to usehttps.globalAgentand set an array of CA's which are defined in a config and updated on an env basis.E.g.
const trustedCa = [ '/etc/pki/tls/certs/ca-bundle.crt', '/path/to/custom/cert.crt' ]; https.globalAgent.options.ca = []; for (const ca of trustedCa) { https.globalAgent.options.ca.push(fs.readFileSync(ca)); }
Can anyone please explain something I'm not understanding about the rationale of bundling own CA store in Node as opposed to using the system CA store?
I see two reasons why Node might choose to use the Firefox's store:
- Not have to interface with individual OS's APIs for trust stores
- Be able to boot bad CAs in response to security-related events
I think Mozilla's reason for bundling the CA store is primarily the latter as described in this article: https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store
But, I do not think this applies to Node? Because since the store is bundled and Node doesn't not have a self-updater, no CA can be booted from an existing Node installation, correct? So if there was a bad CA to be removed, the Node installation at a user's server would have to be updated to the new version that removes the bad CA by updating the bundled store.
If that is the case, is the situation merely that Node bundles the Mozilla CA store so that it doesn't have to implement each OS's APIs for the trust store reading? And since
--use-openssl-cais supported, is that not kind of a moot point now? Could--use-openssl-cabe made the default? What would the downsides of that be? Is it not the default due to backcompat concerns?Very curious to learn more about this, thank you in advance.
Reacted by Nathan Phillip Brink, Thomas Runting, Nuno Vieira, Manuel Molina Cuberos, Erik LaBianca, Pablo Moleri, Maxime Bargiel, Nick Wassermann, SlurpTheo, Bradley Kreider and 4 moresince --use-openssl-ca is supported, is that not kind of a moot point now?
@TomasHubelbauer
--use-openssl-cais not supported on Windows since Windows has its own certificate store. But it might be made default elsewhere perhaps.Reacted by unpunnyfuns, Connor, Jan-Stefan Janetzky and Flurin FeuersteinThank you for sharing don't feel dumb found you can not know everything.
This is terrible and should be addressed, NOT closed. Why is
--use-openssl-castill not the default? What is the rationale behind hard-coding vs system compliance.Also: Stop asking people to put effort and time into patches when the first step is to address the WHY and HOW this came to be, you cannot just rewrite entire software and then having your "patch" rejected because it looks cool.
For macOS and Windows, node recently added
--use-system-caflag.
I was dumbfounded when I realized that Node uses a statically compiled, manually updated, hardcoded list of certificate authorities, rather than relying on the system's trust store, or even just a directory truststore of its own.
This causes a large amount of problems :
Now, I can see no practical use for that. While this is acceptable in a development environment, where you can make changes to your own application, this is outright unusable... and i can't stress enough the security implications for many organisations.
Proposed solutions :
TL;DR: CA Certificates are hardcoded in node. It may be OK for dev, but it sucks big time for ops.