TLS Auth supports accessing windows certificate store for the private key with the id of the private key

[xiananfan]

Feature Description

Currently, the TLS Auth section of the Options inside the javascript only supports clear text private key. This is generally considered insecure in a production environment.

  tlsAuth: [
    {
      domains: ['example.com'],
      cert: open('./mycert.pem'),
      key: open('./mycert-key.pem'),
    },
  ]

For the Windows platform, usually, the certificate is installed into the windows local certificate store. I would like to request that K6 supports accessing the Windows certificate store for accessing the private key instead of providing a cleartext private key.
For example, something like below:

  tlsAuth: [
    {
      domains: ['example.com'],
      cert: open('./mycert.pem'),
      keyid: 'LocalMachine/My/1cdb52270cde175e62e876551bcd56b21bad84c4',
    },
  ],

On a Windows machine, this Powershell command can be used to list all the certs installed in the local machine's certificate store:
Get-ChildItem -path cert:\LocalMachine\My
And the thumbprint string from above output for a specific cert would be the string to use in the configuration.

A library I have found online implemented in GO seems to have this functionality already: https://github.com/google/certtostore/blob/master/certtostore_windows.go

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

[mstoykov]

This likely will need an outside PR as I don't think any of the core developers is using Windows which will make working on this a lot harder.

I have also close to zero experience with certificate stores and can't even tell you if this is only a windows feature or should we be supporting other stores as well.

Additionally, tlsAuth is obviously not great ... having only 1 certificate per the whole instance. So if this turns out to be really complicated we might not want to add it to tlsAuth but instead to a new API that is more versatile 🤔

[mstoykov]

In grafana/k6-docs#616 I am exploring some workaround using outside tools.

Can you maybe try to figure out if this is viable alternative for your case as well 🙇 ?

[xiananfan]

Hi @mstoykov , thank you very much for spending time for finding alternative solutions for me! However, I would assume if we pass certificate as environment variables, we would still need to have access to clear text certificate, and load them into terminal environment variables. However, for our production system, it's simply forbidden to export clear text private certificate once it's imported into the system certificate store. So this still won't work for us.

Again, much appreciated for your effort for researching this!

In my opinion, this will be a very useful feature if implemented. Similar to windows, I believe MacOS also has keychain which stores certs. If K6 can support making TLS https requests by accessing system-wide cert store, it will improve K6's security drastically.

[aftertaf]

Hi,
The ability to leverage the Windows keystores would be great.
a good reference point, though dedicated to java, is this : https://bugs.openjdk.org/browse/JDK-8286790

this was a long standing bug/gap in java, fixed recently.
it allows accessing multiple stores inside the windows "Certificate stores".

from the Java code commit :
"The Windows KeyStore support in the SunMSCAPI provider has been expanded to include access to the local machine location. The new keystore types are:

• "Windows-MY-LOCALMACHINE"
• "Windows-ROOT-LOCALMACHINE"

The following keystore types were also added, allowing developers to make it clear they map to the current user:

• "Windows-MY-CURRENTUSER" (same as "Windows-MY")
• "Windows-ROOT-CURRENTUSER" (same as "Windows-ROOT")

[olegbespalov]

After an internal discussion, k6 core decided to close this issue for now since we are unlikely to work on this shortly.