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
We use an internal/private PKI. We are attempting to use the JFrog Azure DevOps Server marketplace add-in, which under the covers uses this Jfrog CLI.
The documentation states that when using a private PKI, one must make the certificate(s) available to the Jfrog CLI because the Jfrog CLI is currently incapable of using the Windows Certificate Store (for Windows platforms). According to the documentation, the certificate must be located at ~/.jfrog/security/certs (though, I have seen other documentation suggest the location ~/.jfrog/security).
For the purposes of the Azure DevOps Extension, the actual location of the Jfrog CLI (e.g. the Home directory) is $(Agent.ToolsDirectory)/_jf.
In an attempt to get a working build pipeline, the following tests were performed:
Using the Jfrog DotNet Core task:
Place the full certificate chain, including the Artifactory server certificate, into $(Agent.ToolsDirectory)/_jf/security/certs in a file named custom.crt in PEM format
Place only the chain of trust (so, excluding the Artifactory server certificate) into the same file in the same location as above
Repeat tests 1 and 2 above, but this time using the path $(Agent.ToolsDirectory)/_jf/security.
Setting the JFROG_CLI_HOME environment variable to $(Agent.ToolsDirectory)/_jf since it appears from the source code of the Azure DevOps Server add-in task that this environment variable is not set by that task, therefore resulting in the "default location" of the Jfrog CLI home directory being used, causing the certificate to potentially not be found. (A bug issue has been filed on the Jfrog Azure DevOps Server extension repository)
Repeating test 4 above, but appending a / to the environment variable value.
Using the Jfrog CLI V2 task:
Recreate the command executed by the Jfrog DotNet Core task, and re-execute all 4 tests above under §1
Add the --insecure-tls argument to the command in test 1 immediately above. NOTE: This is the only test that succeeded.
From looking at the source code of the Jfrog CLI V2 task for the Azure DevOps add-in, it appears that the JFROG_CLI_HOME environment variable is set, but I still tried to manually set it when tests 1.1-1.3 still didn't work. Again, I filed a bug with the Jfrog Azure DevOps extension repository. However, it appears that there may be an issue with the Jfrog CLI, since no matter what I tried, I was unsuccessful in getting the Jfrog CLI to validate my private CA-issued certificate.
Note
I am able to use openssl to validate that my certificate is valid, both as a single file containing the entire chain of trust from endpoint entity to the root CA, and as two files, one containing just the endpoint entity, the other containing the CA chain of trust certificates.
Current behavior
The Jfrog CLI is not using the supplied PEM certificate under either the $JFROG_CLI_HOME/security or $JFROG_CLI_HOME/security/certs path. (Perusing the documentation at the jfrog-cli-core repo, I see that the correct directory since v1.37.0 is $JFROG_CLI_HOME/security/certs—either way, my PEM certificate was not found and/or used.)
The build always fails unless I use the --insecure-tls command-line switch.
Reproduction steps
See the description.
Expected behavior
I expect that placing any arbitrarily named file having the contents of a valid PEM certificate chain of trust (I'm still not sure if this file should include the Artifactory server certificate in addition to the chain-of-trust CA certificates), that the Jfrog CLI will use the file located in $JFROG_CLI_HOME/security/certs to validate the Artifactory server certificate.
Furthermore, frankly, I expect that the Jfrog CLI would be able to use the Windows Certificate Store when executing on the Windows platform.
Describe the bug
We use an internal/private PKI. We are attempting to use the JFrog Azure DevOps Server marketplace add-in, which under the covers uses this Jfrog CLI.
The documentation states that when using a private PKI, one must make the certificate(s) available to the Jfrog CLI because the Jfrog CLI is currently incapable of using the Windows Certificate Store (for Windows platforms). According to the documentation, the certificate must be located at
~/.jfrog/security/certs(though, I have seen other documentation suggest the location~/.jfrog/security).For the purposes of the Azure DevOps Extension, the actual location of the Jfrog CLI (e.g. the Home directory) is
$(Agent.ToolsDirectory)/_jf.In an attempt to get a working build pipeline, the following tests were performed:
$(Agent.ToolsDirectory)/_jf/security/certsin a file namedcustom.crtin PEM format$(Agent.ToolsDirectory)/_jf/security.JFROG_CLI_HOMEenvironment variable to$(Agent.ToolsDirectory)/_jfsince it appears from the source code of the Azure DevOps Server add-in task that this environment variable is not set by that task, therefore resulting in the "default location" of the Jfrog CLI home directory being used, causing the certificate to potentially not be found. (A bug issue has been filed on the Jfrog Azure DevOps Server extension repository)/to the environment variable value.--insecure-tlsargument to the command in test 1 immediately above. NOTE: This is the only test that succeeded.From looking at the source code of the Jfrog CLI V2 task for the Azure DevOps add-in, it appears that the
JFROG_CLI_HOMEenvironment variable is set, but I still tried to manually set it when tests 1.1-1.3 still didn't work. Again, I filed a bug with the Jfrog Azure DevOps extension repository. However, it appears that there may be an issue with the Jfrog CLI, since no matter what I tried, I was unsuccessful in getting the Jfrog CLI to validate my private CA-issued certificate.Note
I am able to use
opensslto validate that my certificate is valid, both as a single file containing the entire chain of trust from endpoint entity to the root CA, and as two files, one containing just the endpoint entity, the other containing the CA chain of trust certificates.Current behavior
The Jfrog CLI is not using the supplied PEM certificate under either the
$JFROG_CLI_HOME/securityor$JFROG_CLI_HOME/security/certspath. (Perusing the documentation at the jfrog-cli-core repo, I see that the correct directory since v1.37.0 is$JFROG_CLI_HOME/security/certs—either way, my PEM certificate was not found and/or used.)The build always fails unless I use the
--insecure-tlscommand-line switch.Reproduction steps
See the description.
Expected behavior
I expect that placing any arbitrarily named file having the contents of a valid PEM certificate chain of trust (I'm still not sure if this file should include the Artifactory server certificate in addition to the chain-of-trust CA certificates), that the Jfrog CLI will use the file located in
$JFROG_CLI_HOME/security/certsto validate the Artifactory server certificate.Furthermore, frankly, I expect that the Jfrog CLI would be able to use the Windows Certificate Store when executing on the Windows platform.
JFrog CLI version
2.50.4
Operating system type and version
Windows Server 2019
JFrog Artifactory version
7.63.7
JFrog Xray version
No response