Automatic import of private CA certificates in Windows.

[Cesar-DC]

Summary

This PR adds a Windows-specific preflight step to improve handling of private PKI certificates in JFrog CLI.

When a command includes a target URL, the CLI:

1. Performs a TLS handshake using the Windows trust store
2. Extracts the verified certificate chain
3. Writes the certificates (leaf, intermediate, root) into:
   ~/.jfrog/security/certs
4. Continues execution

Motivation

On Windows, JFrog CLI may fail with:

even when the certificate is already trusted by the OS.

Manually exporting the site certificate from a browser and placing it in ~/.jfrog/security/certs resolves the issue.

This patch automates that process.

Behavior

• Windows only
• Triggered when --url or JFROG_URL is provided
• Writes:
  • leaf.pem
  • intermediate.pem
  • root.pem

Testing

Validated locally:

jf.exe rt ping --url=https://<host>/artifactory

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

CULOT CÉSAR seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[RemiBou]

add tests

[RemiBou]

add tests

[RemiBou]

why do we need to persist the chain ?

[Cesar-DC]

Go on Windows can validate a certificate against the CAs available in the Windows certificate store (typically managed by a corporate PKI team).

If the connection is successfully validated by Go, we can safely extract and copy the certificate chain into the location expected by JFrog CLI (~/.jfrog/security/certs).

This approach avoids a full rewrite of the CLI to directly support the Windows certificate store. Instead, it preserves the existing mechanism (manual placement of private CA certificates), while leveraging Go’s ability to interact with the system certificate store to ensure the chain we import is trusted.

[RemiBou]

It should be handled in https://github.com/jfrog/jfrog-client-go/blob/master/auth/cert/sslutils_windows.go

[Cesar-DC]

Even better, we have a 5 lines fix then

https://github.com/jfrog/jfrog-client-go/blob/master/auth/cert/loader.go

replace:
caCertPool, err := loadSystemRoots()

with:
caCertPool, err := x509.SystemCertPool()
if caCertPool == nil {
caCertPool = x509.NewCertPool()
}

Tested locally.
might be a fix for : #2309