Skip to content

Unable to use private PKI certificate #2309

@fourpastmidnight

Description

@fourpastmidnight

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:

  1. Using the Jfrog DotNet Core task:
    1. 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
    2. Place only the chain of trust (so, excluding the Artifactory server certificate) into the same file in the same location as above
    3. Repeat tests 1 and 2 above, but this time using the path $(Agent.ToolsDirectory)/_jf/security.
    4. 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)
    5. Repeating test 4 above, but appending a / to the environment variable value.
  2. Using the Jfrog CLI V2 task:
    1. Recreate the command executed by the Jfrog DotNet Core task, and re-execute all 4 tests above under §1
    2. 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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleAn outdated issue lacking engagement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions