Repository navigation
Tracking issue: custom CA certificate support #58990
Description
Activity
- addedtlsIssues and PRs related to the tls subsystem.Issues and PRs related to the tls subsystem.cryptoIssues and PRs related to the crypto subsystem.Issues and PRs related to the crypto subsystem.metaIssues and PRs related to the general management of the project.Issues and PRs related to the general management of the project.
on Jul 8, 2025 will use-system-ca default to true in next major ?
Node.js is the only software I know doesn't respect system CA, really weird behavior.
Currently this still has a non-trivial performance overhead on the first TLS connection. We'll need to check and see if that can be mitigated or reduced.
Reacted by Arthur MooreNode.js is the only software I know doesn't respect system CA, really weird behavior.
Python requires that
trustorebe installed, and pip only recently stopped requiring an experimental flag.I do agree it's a bit of a pain though. Especially in corporate environments.
I found a way to minimize the performance impact - #59550 with this I think there would be a much smaller performance impact to enable it by default.
- added a commit that references this issue
on Aug 25, 2025 - added a commit that references this issue
on Aug 26, 2025 - added a commit that references this issue
on Sep 20, 2025 I found this really annoying for enterprise user, if user have enterprise cert installed globally, so fetch won't work. Maybe also add a runtime check or env check since --use-system-ca not by default?
It's unclear to me what runtime checks etc. means. There are runtime APIs for querying and setting certificates that users can invoke, but from a runtime point of view, Node.js has no way of knowing what the system certificates are. Most systems likely have some certificates different from the Mozilla bundle, so if the signal is that there is some difference then practically it's enabling by default.
github-actions commented
on Aug 12, 2026 on Aug 12, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Aug 12, 2026 - addednever-staleIssues and PRs exempt from automated stale handling.Issues and PRs exempt from automated stale handling.and removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Aug 12, 2026
Trying to track the recent changes that allow easier configuration of custom CA certificate for constrained environments and the backports
--use-system-cafor macOS feat: added support for reading certificates from macOS system store #56599--use-system-cafor Windows crypto: support --use-system-ca on Windows #56833--use-system-cafor other Unix-like platforms: crypto: support --use-system-ca on non-Windows and non-macOS #57009--use-system-cain certificate errors: Suggest --use-system-ca when a certificate error occurs #57362--use-system-cacrypto: fix X509* leak in --use-system-ca #56832--use-system-caa per-env option so that workers can enable/disable them individually Make --use-system-ca per-env rather than per-process #60678node/src/crypto/crypto_context.cc
Lines 647 to 648 in 5623194
--use-system-caby default