Our working environment is Azure DevOps. We actually use PowerShell scripts to upload our artifacts to Artifactory.
Right now we are trying to download those artifacts using the Artifactory Service Connection in Azure DevOps, but not the PowerShell script. So now we are having the error
[error] Post https://art..... : x509 certificate signed by unknown authority
How can we solve this issue?
It seems that you are accessing Artifacory via HTTPS and with a Self-signed certificate therefore the Artifactory service connection is not trusting the certs. I would recommend referring to this JFrog Wiki and by adding the certs to the trusted directory of the JFrog CLI which is used in most of the Artifactory Azure tasks.
Related
I am creating New Kubernetes service connection in Azure DevOps Server 2020 Update 1 via KubeConfig.
When I click to Verify that the connection it says that Verification Failed with the generic error:
Failed to query service connection API: 'https://ekm.mpu.cz/k8s/clusters/c-qmcrb/api/v1/nodes'. Error Message: 'An error occurred while sending the request.'
Please note that the Kubernetess instance is in the other domain.
I have the notion that the error could be with the certs are not imported somewhere on the machine, where the Azure DevOps is hosted, but I am unsure where. The MS documentation is silent about that as well.
So far I've tried to:
Import CA certs to the MMC under trusted publishers.
Import CA certs under cacerts in JAVA-HOME via keytool.
Import CA certs into azureTrustsStore.jks in JAVA-HOME via keytool.
For all 3 I've checked that the CA certs are imported correctly. But to no avail. Could you please advice or redirect me to the method, how to do it?
Additional Info:
While I cannot Verify and Save the connection, I still can Save it and then use it in the pipeline and it works OK! (sucesfully connect and execute the command).
Connection issues can occur for many reasons, but the root cause is often related to an error with one of these items: Network, Authentication, Authorization. You may refer to Basic troubleshooting of cluster connection issues for detailed troubleshooting steps.
When I try to run TerraformInstaller to install terraform in azure pipelines, I get the following error message.
##[error]Error: Failed to download Terraform from url https://releases.hashicorp.com/terraform/1.2.4/terraform_1.2.4_linux_amd64.zip. Error Error: self signed certificate in certificate chain
When I browse the link in server where self-hosted agent is installed, I am able to get to the link fine and download the zip file but only getting this error when I am running the pipeline in Azure DevOps. Firewall port 443 is obviously open and I think this error has to do with cert not being placed in the correct location? Do I need to configure self-hosted agent with cert?
I was recently ordered by our IT team to disable the NAT pools on my service fabric cluster due to security risks. The only way I could do this was to deploy a new cluster with all its components.
Because this is a test environment I opt to use a self signed cert without a password for my cluster, the certificate is in my vault and the cluster is up and running.
The issue I have now is when I try to deploy my application from an Azure Devops Release Pipeline I get the following message:
An error occurred attempting to import the certificate. Ensure that your service endpoint is configured properly with a correct certificate value and, if the certificate is password-protected, a valid password. Error message: Exception calling "Import" with "3" argument(s): "The specified network password is not correct.
I generated the self signed certificate in Key Vault, downloaded the certificate and used Powershell to get the Base64 string for the service connection.
Should I create the certificate myself, with a password?
With the direction of the two comments supplied, I ended up generating a certificate on my local machine using the powershell script included with service fabric's local run time.
A small caveat here is to change the key size in the script to a large key size than the default, because ke vault does not support 1024 keys.
I then exported the pfx from my user certificates added a password(this is required for the service connection) and impoted the new pfx into my key vault.
Redeployed my cluster and it worked.
I'm trying to push docker image to registry on nexus using azure pipeline.
my nexus uses self signed certificate.
when I tried to push I got the following error:
x509: certificate signed by unknown authority
Since I don't have root privileges on the pipeline agent,
I CANNOT (for example) create a 'command line script' task to run the commands:
openssl s_client -showcerts -connect myserver:port < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /usr/local/share/ca-certificates/ca.crt
update-ca-certificates -f
how can I make the agent to trust my self signed certificate?
Generally, we can use the Secure Files to store the signing certificates. Secure files are defined and managed in the Library tab in Azure Pipelines.
Then we can use the Download Secure File Utility task to consume secure files within a Build or Release Pipeline. You can have a try for that.
If that doesn't work. I am afraid that you have to setup a self-hosted agent to do that.
We've been successfully using TeamCity and Octopus on a single machine, and now we have added a new build agent due to growing number of simultaneous builds. I have set up a new Octopus Tentacle and verified that Tentacle is reachable from the Octopus server in Listener role. However,any build that uses Octopack fails when executed on the new TeamCity agent. Here is an extract from the build log:
Running command: octo.exe create-release --server
servername:8443 --apikey SECRET --project NRK Bridge (Legacy)
--enableservicemessages --version 0.0.0.662 --deployto Dev --waitfordeployment --package=NRK.Bridge.Web:0.0.0.662 --packageversion=0.0.0.662
[12:06:02]Creating Octopus Deploy release
[12:06:02]Octopus Deploy Command Line Tool, version 2.0.8.22
[12:06:03]Handshaking with Octopus server: servername:8443
[12:06:06]The following certificate errors were
encountered when establishing the HTTPS connection to the server:
RemoteCertificateChainErrors
[12:06:06]Certificate subject name: CN=servername
[12:06:06]Certificate thumbprint: 79C26(...)
[12:06:07]The following certificate errors were encountered when
establishing the HTTPS connection to the server:
RemoteCertificateChainErrors
[12:06:07]Certificate subject name: CN=servername
[12:06:07]Certificate thumbprint: 79C26(...)
[12:06:08]The following certificate errors were encountered when
establishing the HTTPS connection to the server:
RemoteCertificateChainErrors
What I noticed is that the certificate thumbprint in the build log is different from thumbprints shown in Octopus server machine page. I tried to generate a new API key and re-register a Tentacle. Am I overlooking something here?
Did you copy the Api key into Team City? The api key is different to thumb prints. Api Key can be found in Octopus Admin section, under users tab.