[Feature] Support for system certificate store

[mungojam]

• I'd be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

When running yarn or yarn install to bring packages down in a corporate environment with proxy certificates, we generally get the common error about self-signed certificates. We end up setting NODE_EXTRA_CA_CERTS on all developer machines as a workaround but it means extra maintenance because sometimes the internal certificates get renewed, perhaps more often once the browser certificate lifetimes reduce.

Describe the solution you'd like

I understand from elsewhere that since Node.js v22.15.0 one can use this to pick up the system certs:

import { globalAgent } from 'https'
import { getCACertificates } from 'node:tls'

globalAgent.options.ca = getCACertificates('system')

I'd like it if this was automatically implemented where the node version was high enough.

Describe the drawbacks of your solution

Some code complexity with the version check, not aware of any other downsides.

Describe alternatives you've considered

The alternative is to continue using NODE_EXTRA_CA_CERTS.

[NormalGaussian]

Would setting your script in a globally readable location, and then setting NODE_OPTIONS to have --require <script> work?

This would have the benefit of working with all tools and not just yarn.

n.b., with NODE_OPTIONS its best to append to it rather than override.

I'll note that --require is better than --import in that it runs synchronously:

As for version checks, you can get the version from process.versions.node (https://nodejs.org/docs/latest/api/process.html#processversion), or you can just check for existence of the function.

const tls = require('tls');
if (typeof tls.getCACertificates === 'function') {
  const globalAgent = require('https').globalAgent;
  globalAgent.options.ca = tls.getCACertificates('system');
}

[mungojam]

Would setting your script in a globally readable location, and then setting NODE_OPTIONS to have --require <script> work?

I wasn't aware of that feature thank you, that would definitely be an improvement on our current workaround so we may look into that.

This would have the benefit of working with all tools and not just yarn.

Node isn't our main toolset, we only really use yarn for serverless framework so the bigger benefit would be if it started to be the default behaviour in the very few node tools we use like yarn. Though really I wish it just became the node default, but I guess that is unlikely.

[NormalGaussian]

well quite! I should have said all node tools :)

CA configuration is a huge PITA for sure.

I was thinking a little about this during the day - I have a preference to have all such things committed into the repo itself, particularly so that it doesn't affect other repos on the same machine. I'd be remiss to not also suggest using a custom yarn plugin - this might be useful in your case . Vendoring a plugin that is installed and committed to the repo.

This may not be your preferred direction - its certainly more complex - but I've fleshed it out for my own satisfaction and future reference.

There are a couple of ways this can be set up; depending on where you want to certs to be present, and if there is anywhere you don't want them present. Doing the certificate assignment in the factory portion of the plugin rather than the hooks would set this for all yarn commands, doing it in a hook like validateProject before the install would only set it for commands downstream of the hook - validateProject precedes an install. Doing it in a hook like setupScriptEnvironment would precede child processes (which wouldn't inherit the CA settings, so ENV needs updated) so would get 'everything' downstream of yarn. Here is an untested example (I don't have a test loop set up for certs), you'd need to configure the where variable:

// .yarn/plugins/system-ca.install.js
const tls = require('tls');
if (typeof tls.getCACertificates === 'function') {
  const globalAgent = require('https').globalAgent;
  globalAgent.options.ca = tls.getCACertificates('system');
}

// .yarn/plugins/system-ca.js
const where = []; // ("yarn" | "install" | "children")
module.exports = {
  name: 'system-ca',
  factory: () => {
    if(where.includes("yarn")) {
      require('./system-ca.install.js');
    }

    return {
      validateProject: () => {
        if(where.includes("install")) {
          require('./system-ca.install.js');
        }
      },
      setupScriptEnvironment: (_, env) => {
        if(where.includes("children")) {
          const path = require('path');
          env.NODE_OPTIONS = `${env.NODE_OPTIONS || ''} --require "${path.join(__dirname, 'system-ca.install.js')}"`;
        }
      }
    };
  },
};

// .yarnrc.yml
plugins:
  - path: .yarn/plugins/system-ca.js

[mungojam]

Thank you for giving it lots of thought. I'll definitely consider the plugin approach, it would be handy to have in our template repos and as you say it would save us from having to roll things out to devs.

We'd need to roll it out to all repos but that's often the case with various tooling changes.

[clemyan]

We have the httpsCaFilePath setting, but the best way to set it depends on your setup and it may not be adequate for your use case?

corporate environment with proxy certificates

Do you proxy all requests? Or do you use an internal package registry?

because sometimes the internal certificates get renewed, perhaps more often once the browser certificate lifetimes reduce

What is your current workflow for that? Based on the feature request do you send the new root certificate to devs and have them install it into the system certificate store? How many dev and repos does this affect? Would an actual CA setup be better for your use case?