search

jfrog / jfrog-azure-devops-extension

Apache License 2.0
47 stars 61 forks source link

Azure Devops Extension not validating new Lets Encrypt Certs #274

Open andydkelly-ig opened 2 years ago

andydkelly-ig commented 2 years ago

Describe the bug Since LetsEncrypt changed their Root CA on Thursday 30th September, the Azure DevOps JFrog task is now failing with the error [Error] Get "https://artifactory.companyname.com/artifactory/api/system/version": x509: certificate has expired or is not yet valid: current time 2021-10-04T10:50:49+01:00 is after 2021-09-30T14:01:15Z ore can be read about the likely causes of this issue here and here. This is affecting all the JFrog tasks on ADO so presumably part of the underlying JFrog CLI in use.

To Reproduce Use LetsEncrypt cert to secure Artifactory server - ensure LetsEncrpyt cert uses the new ISRG Root X1 Root cert.

Expected behavior Task should work as expected, not fail with cert errors.

Screenshots If applicable, add screenshots to help explain your problem.

Versions

Additional context Add any other context about the problem here.

chatelain-io commented 2 years ago

We do have the same issues. Our Let's encrypt certificates are valid ISRG Root X1 and Sign by R3. We don't have any issue using curl or other tasks.

I've looked if the ca certificate installed on the agents was correct and it was in fact.

Versions:

eyalbe4 commented 2 years ago

@andydkelly-ig and @chatelain-io, Thanks for raising this issue. JFrog CLI is written in go, and it looks like go picks up the root certificates from the local file system - https://stackoverflow.com/questions/40051213/where-is-golang-picking-up-root-cas-from Do you know where this root certificate is located? We can then check if the latest go version has this path updated and if so, we can release JFrog CLI with this go version. If you happen to find this root certificate, you can also place it inside the security/certs directory, which is under jfrog-cli's home directory. JFrog CLI picks up the certificates from this directory.

chatelain-io commented 2 years ago

I also have the issue with the Task: ArtifactoryToolInstaller@1 which I guest don't use the jfrog-cli, but I might be wrong.

Failed while attempting to download JFrog CLI from https://aaa.abc.com/artifactory/jfrog-cli/1.51.1/jfrog-cli-linux-386/jfrog. If the chosen Artifactory Service cannot access the internet, you may also manually download version 1.51.1 of JFrog CLI and place it on the agent in the following path: /opt/hostedtoolcache/_jfrog/current/jfrog Error: certificate has expired For the certificate location:

It is probably to the sdk validating the certificate.

We're still investigating on our side.

UPDATE:

  1. The task works on our self-hosted agents (docker images) either hosted in Azure or on-premise but to not work for Microsoft hosted agents or our own hosted agent based on https://github.com/actions/virtual-environments
chatelain-io commented 2 years ago

Other than ArtifactoryToolInstaller@1, all the other Artifactory tasks work for us.

I'm still getting the error state above "Error: certificate has expired" on Microsoft Hosted agent and can't figure what is the issue.

Our workaround, was to install the cli manually.

RobiNino commented 2 years ago

Hi @andydkelly-ig , @chatelain-io , Thank you for helping us investigate.

From the information you provided, and similar issues opened on azure-pipelines's projects, it seems that the issue is with the handling of certificates used to download JFrog CLI, not with the usage of JFrog CLI itself. What the tasks have in common is the usage of the same utility function (exported from azure-pipelines-tool-lib) to perform the download.

Related issues: azure-pipelines-tool-lib#133, azure-pipelines-tasks#15367, azure-pipelines-tasks#15316. Note that some of them offer an unsecure workaround.

We'll keep on investigating and tracking the other issues and keep you posted.

chatelain-io commented 2 years ago

FYI, AGENT_USE_NODE10=true as variable will fix the issue on both windows and ubuntu agent.

similar issue: https://community.sonarsource.com/t/cert-has-expired-issue-on-sonarqube/25656

arp-mbender commented 2 years ago

@chatelain-io Is it possible to set that variable for all build self-hosted agent jobs running on a particular Windows server machine? We have quite a few pipelines and I'd rather not have to go through each to set one variable...

chatelain-io commented 2 years ago

@chatelain-io Is it possible to set that variable for all build self-hosted agent jobs running on a particular Windows server machine? We have quite a few pipelines and I'd rather not have to go through each to set one variable...

I haven't tested it, but you could try to add the variable as a System Environment Variables in windows and then reboot the machine, the agent might pick it up. You might need to update the agent environment variables.

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops#how-do-i-set-different-environment-variables-for-each-individual-agent