You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow Node to use certificates from the macOS Keychain when making HTTPS requests #39657
On macOS and iOS platforms, Node should integrate with the Keychain to source its certificates for TLS requests.
Is your feature request related to a problem? Please describe.
At work our IT department is setting up TLS traffic inspection using custom certificates. These certificates are preinstalled in the keychains of our corporate Macs.
Mac apps and some CLI programs - like the system curl - are built against the Apple Secure Transport or Network frameworks. These allow them to use certificates from the keychain when making TLS requests. As a result the custom certificates work without issue in these programs.
Meanwhile, other programs that don't use the Apple frameworks basically all break, unless application-specific workarounds are used. The most high-profile failure we see in Node apps is NPM failing to fetch dependencies because of certificate errors.
At the moment the workaround for Node is to export the root cert to the filesystem, and set the NODE_EXTRA_CA_CERTS variable. This is doable but it's annoying, and results in duplicates of the certificate that must be maintained going forward. It would be far easier if Node used one of the aforementioned Apple frameworks, so that it can use certificates from the keychain transparently.
I'm wondering if using the Network framework for HTTPS requests might tangentially be helpful for Electron apps, and other Mac apps that use Node...
If you submit an app to the App Store that is deemed to use cryptography, you normally have to do some extra export compliance paperwork. However there are exemptions if you're just using encryption that's built into the OS.
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
So perhaps if the Node https API was backed by URLSession (one of the main Network classes), we could benefit from the exemption.
Having done the US Dept Commerce export restrictions dance in a previous life working for a company that published our own build of Linux, I can confirm that leveraging the OS is a much easier route to go down.
Functionally, this enhancement is pretty important for organizations that are using technologies such as Cisco Umbrella - it spoofs DNS and is essentially a "corporate security approved man-in-the-middle", generating its own SSL certs on the fly. Right now, node apps running behind such a regime cannot connect successfully to any site that Umbrella is intercepting because the SSL certs that Umbrella generates have their own root cert installed in the Apple System keychain. (Note: not in the System Roots keychain). Node would need to look in both keychains to be successful in such an environment - easiest way to do this is via the OS framework.
This feature request comes up every 1.5 years or so. It's never been implemented and the chances of it happening this time are... let's say, no better than before.
The reason node works the way it does is consistency. Node version x.y.z works exactly the same on every platform. Important for apps and libraries.
Previous discussions also ran aground on questions like "what if there is more than one trust store?" (Case in point: my Linux box has two. Which one is leading?)
If there were easier ways to specify the extra CAs that might also be a
good compromise. Currently you must export an (exact) path to a specific
variable. There's no way, for example to use package.json or a shared
config file to set this up just once....
On Wed, 1 Jun 2022, 21:05 Ben Noordhuis, ***@***.***> wrote:
This feature request comes up every 1.5 years or so. It's never been
implemented and the chances of it happening this time are... let's say, no
better than before.
The reason node works the way it does is consistency. Node version x.y.z
works exactly the same on every platform. Important for apps and libraries.
Previous discussions also ran aground on questions like "what if there is
more than one trust store?" (Case in point: my Linux box has two. Which one
is leading?)
—
Reply to this email directly, view it on GitHub
<#39657 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJWOW6VUCQIYBMH7YZCG23VM667HANCNFSM5BRSNJ5Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
On Wed, 1 Jun 2022, 23:42 Sam Duke, ***@***.***> wrote:
If there were easier ways to specify the extra CAs that might also be a
good compromise. Currently you must export an (exact) path to a specific
variable. There's no way, for example to use package.json or a shared
config file to set this up just once....
On Wed, 1 Jun 2022, 21:05 Ben Noordhuis, ***@***.***> wrote:
> This feature request comes up every 1.5 years or so. It's never been
> implemented and the chances of it happening this time are... let's say, no
> better than before.
>
> The reason node works the way it does is consistency. Node version x.y.z
> works exactly the same on every platform. Important for apps and libraries.
>
> Previous discussions also ran aground on questions like "what if there is
> more than one trust store?" (Case in point: my Linux box has two. Which one
> is leading?)
>
> —
> Reply to this email directly, view it on GitHub
> <#39657 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJWOW6VUCQIYBMH7YZCG23VM667HANCNFSM5BRSNJ5Q>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
Uses the same library that Deno uses. Not yet published because I need to wrangle GitHub Actions into publishing the build artifacts somehow (it's a native library.)
If an Actions guru wants to chip in, that'd be very welcome.
#44532 attempted to add Windows keychain support but seems to have stalled. The fact it's Windows-only makes it less likely to get merged so maybe someone wants to adopt it and add macOS support?
Expectation management: I can't guarantee it's going to get merged but multi-platform support would definitely help strengthen its case.
@chriskilding since the native-certs is not yet on npm how could we use the library? I've tried to download the project and run the build command with cargo, but I'm not sure what I should do with the files on the target folder. Can I get some help with this please? A lib like that would be helpful for what I'm trying to achieve
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
No one stepped up to do the leg work and "be like curl" is too generic to be actionable. It doesn't seem like this feature request is going anywhere and it's best to let it die off in that case.
@timja Thank you so much for creating a PR for this. Hope it will be accepted and merged by the Nodejs team since it is a nice feature instead of manually setting up NODE_EXTRA_CA_CERTS environment variable
Activity
chriskilding commentedon Aug 5, 2021
Would be good to get some pointers on where to start building this, for anyone who is interested in doing so.
Am I right that the place to start would be the
httpsortlsmodules within Node core?targos commentedon Aug 5, 2021
Not sure, but I think it would probably have to be written in C++ somewhere in
src/cryptochriskilding commentedon Aug 5, 2021
I'm wondering if using the
Networkframework for HTTPS requests might tangentially be helpful for Electron apps, and other Mac apps that use Node...If you submit an app to the App Store that is deemed to use cryptography, you normally have to do some extra export compliance paperwork. However there are exemptions if you're just using encryption that's built into the OS.
Apple's docs (https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations) say:
So perhaps if the Node
httpsAPI was backed byURLSession(one of the mainNetworkclasses), we could benefit from the exemption.z3n-badam commentedon Feb 1, 2022
Having done the US Dept Commerce export restrictions dance in a previous life working for a company that published our own build of Linux, I can confirm that leveraging the OS is a much easier route to go down.
Functionally, this enhancement is pretty important for organizations that are using technologies such as Cisco Umbrella - it spoofs DNS and is essentially a "corporate security approved man-in-the-middle", generating its own SSL certs on the fly. Right now, node apps running behind such a regime cannot connect successfully to any site that Umbrella is intercepting because the SSL certs that Umbrella generates have their own root cert installed in the Apple System keychain. (Note: not in the System Roots keychain). Node would need to look in both keychains to be successful in such an environment - easiest way to do this is via the OS framework.
samskiter commentedon Jun 1, 2022
Working around this is a pain for anyone with a corporate machine/proxy - node should ideally respect the CAs installed on macos
bnoordhuis commentedon Jun 1, 2022
This feature request comes up every 1.5 years or so. It's never been implemented and the chances of it happening this time are... let's say, no better than before.
The reason node works the way it does is consistency. Node version x.y.z works exactly the same on every platform. Important for apps and libraries.
Previous discussions also ran aground on questions like "what if there is more than one trust store?" (Case in point: my Linux box has two. Which one is leading?)
samskiter commentedon Jun 1, 2022
samskiter commentedon Jun 1, 2022
bnoordhuis commentedon Jun 2, 2022
I put together a package that lets you use the system's trust store: https://github.com/bnoordhuis/node-native-certs
Uses the same library that Deno uses. Not yet published because I need to wrangle GitHub Actions into publishing the build artifacts somehow (it's a native library.)
If an Actions guru wants to chip in, that'd be very welcome.
chriskilding commentedon Jun 6, 2022
@bnoordhuis thanks for your contribution, and good to know it's the same as Deno under the covers. I'll see if I can rustle up a GitHub Action for you
2 remaining items
bnoordhuis commentedon Dec 29, 2022
#44532 attempted to add Windows keychain support but seems to have stalled. The fact it's Windows-only makes it less likely to get merged so maybe someone wants to adopt it and add macOS support?
Expectation management: I can't guarantee it's going to get merged but multi-platform support would definitely help strengthen its case.
diogoperes commentedon Mar 6, 2023
@chriskilding since the
native-certsis not yet on npm how could we use the library? I've tried to download the project and run the build command withcargo, but I'm not sure what I should do with the files on the target folder. Can I get some help with this please? A lib like that would be helpful for what I'm trying to achievechriskilding commentedon Mar 6, 2023
Hi @diogoperes, if you want to do this on your laptop this would be called a local module install. This uses the
npm linkcommand.More here: https://docs.npmjs.com/cli/v9/commands/npm-link
github-actions commentedon Sep 3, 2023
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
samskiter commentedon Sep 3, 2023
I think this should be kept open - it looks like there has been some progress toward something that may work...
As mentioned, use expectation would be that node works like curl - if you can curl the file you should be able to use npm to install it...
bnoordhuis commentedon Sep 3, 2023
No one stepped up to do the leg work and "be like curl" is too generic to be actionable. It doesn't seem like this feature request is going anywhere and it's best to let it die off in that case.
bnoordhuis commentedon Sep 27, 2023
Since there's been no follow-up and no new pull requests (edit: as far as I can see), I'll take the liberty of closing this.
timja commentedon Jan 14, 2025
I'm working on this, #56599
Would it be possible to re-open the issue please.
amjedomar commentedon Jan 23, 2025
@timja Thank you so much for creating a PR for this. Hope it will be accepted and merged by the Nodejs team since it is a nice feature instead of manually setting up
NODE_EXTRA_CA_CERTSenvironment variable