x509: certificate signed by unknown authority

[rsouthgate]

This seems similar to already closed issue #44 But specifically I cannot get the agent to respect our company root cert (not self-signed).

I have added the root cert to ~/.jfrog/security for the user under which the agent is running and also to /path_to_agent/_work/_jfrog/.jfrog/security

I am not sure of the correct format for the root cert so I've added the .cer, .pem and .der.

As far as I can tell the CLI is Go and Go should respect the keychain anyway (the root cert is added to the keychain and always trusted).

Regardless of what I do I get the error: x509: certificate signed by unknown authority.

Version 1.6.2 jfrog CLI version: 1.26.2

Full log with some info redacted:

2019-10-11T01:28:04.5299030Z ##[section]Starting: Build from pom
2019-10-11T01:28:04.5680390Z ==============================================================================
2019-10-11T01:28:04.5704160Z Task         : Artifactory Maven
2019-10-11T01:28:04.5728050Z Description  : Build with Apache Maven, while resolving dependencies and deploying artifacts from and to Artifactory and while allowing to collect build-info. The collected build-info can be later published to Artifactory by the "Artifactory Publish Build Info" task.
2019-10-11T01:28:04.5752020Z Version      : 1.6.2
2019-10-11T01:28:04.5774050Z Author       : JFrog
2019-10-11T01:28:04.5796460Z Help         : [More Information](https://www.jfrog.com/confluence/display/RTF/Maven+Repository)
2019-10-11T01:28:04.5819440Z ==============================================================================
2019-10-11T01:28:05.2173040Z Found tool in cache: jfrog 1.26.2 x64
2019-10-11T01:28:05.2207650Z Running jfrog-cli from /Users/robin/Downloads/vstsagent/_work/_tool/jfrog/1.26.2/x64/jfrog.
2019-10-11T01:28:05.2816500Z JFrog CLI version: 1.26.2
2019-10-11T01:28:05.2852730Z M2_HOME is not defined. Retrieving Maven home using mvn --version.
2019-10-11T01:28:05.7536900Z The Maven home location: /usr/local/Cellar/maven/3.3.9/libexec
2019-10-11T01:28:05.7712390Z [Info] Encrypting password...
2019-10-11T01:28:05.7726620Z
2019-10-11T01:28:06.2294260Z [Error] Get https://webappartifactory.asbbank.co.nz/artifactory/api/security/encryptedPassword: x509: certificate signed by unknown authority
2019-10-11T01:28:06.2431360Z ##[error]Error: Command failed: /Users/**********/vstsagent/_work/_tool/jfrog/1.26.2/x64/jfrog rt c --url="https://********************/artifactory" --user=*** --password=***
2019-10-11T01:28:06.2536110Z [Info] "****************-deployer" configuration could not be found.
2019-10-11T01:28:06.2636290Z [Info] "undefined" configuration could not be found.
2019-10-11T01:28:06.2691110Z Collecting environment variables...
2019-10-11T01:28:06.2806980Z [Info] Collecting environment variables...
2019-10-11T01:28:06.2861250Z [Info] Collected environment variables for *************************
2019-10-11T01:28:06.3791860Z ##[section]Finishing: Build from pom

[eyalbe4]

@rsouthgate, Is it a p12 certificate you're trying to use? If so, then https://github.com/jfrog/jfrog-cli/pull/464 adds this functionality to JFrog CLI. This PR is still under review, but if you're able to build the code from this PR, you can test it with your certificate. Please let us know if you need assistance with creating the CLI binary.

[rsouthgate]

@eyalbe4 I think that is talking about client creds. I'm talking about the SSL cert used for our domain... https://www.ourdomain.com/arifactory. In this instance the SSL cert has a root cert authority that is also 'us'. For a bunch of other system that ultimately rely on this root cert I have had to add it to trusted profiles - like in java I add it to the keystore so javacan do the SSL handshake with hosts that use it.

[dfal]

Deprecated task JFrog.jfrog-artifactory.jfrog-artifactory-deployer-build-task.JFrogArtifactoryDeployer@2 on the same agent doesn't have this problem. Probably it uses older version of jfrog CLI.

[eyalbe4]

@dfal and @rsouthgate, It is not easy to reproduce this issue. JFrog CLI includes tests for self-signed-certificates and they pass. Can you please see if you can reproduce this issue with a standalone JFrog CLI (outside of Azure DevOps)? We can then work together, and if needed add more verbose logging, to figure this one out.

[dfal]

@eyalbe4 , yes I can constantly reproduce it starting with oldest available for download version 1.13.0 up to the latest one.

[eyalbe4]

@dfal, When using cUrl, with the same certificate you put the security directory of JFrog CLI, as follows:

curl --cacert cacert.pem ....

does it works for you?

[rsouthgate]

@eyalbe4 This might be two distinct issues. From my perspective I did some more digging around our cert chain via openssl and discovered the cert was only providing the end part of the chain with a feature call Authority Information Access which allows browsers to discover the rest of the cert (and was the reason why I assumed our cert was valid.

More info in the accepted answer here https://stackoverflow.com/questions/7587851/openssl-unable-to-verify-the-first-certificate-for-experian-url

But the short answer is once we switched to a full chain cert the issue was resolved.

The longer answer might be that the CLI could benefit from the same discovery features as implemented by browsers but I assume that is actually a language feature and not something you can build on top.

[eyalbe4]

Great finding @rsouthgate and thanks so much for sharing this information!

Following your finding, I came across https://github.com/golang/go/issues/31773 which proposes adding Authority Information Access to Go. If added, we'd sure like to add it to JFrog CLI.

@dfal - could this be the cause of your issue as well?

[dfal]

@eyalbe4 , probably yes. But which version of jfrog CLI is used by deprecated JFrogArtifactoryDeployer@2 task? Is it written in GO as well?

[eyalbe4]

@dfal - it used version 1.4.1 released in July 2016. I can't think of an explanation for how it could have worked with this version. Maybe the REST API that worked wasn't fired by JFrog CLI.

[eyalbe4]

@dfal, I'm closing this issue for now, but do let me know if you'd like us to discuss this further.