I Renewed the SSL certificate in Jenkins server and it applied successfully. When I view the certificate from the Jenkins dashboard it reflects the old certificate details.
Related
Azure DevOps Server 2020 with self hosted agents on a different server
I have a build, which is creating an artifact in Azure Artifacts, then a release pipeline is triggered which should download this artifact and do something with it. Previously, the output of a build was on a file share and it work as expected. When I switched to Azure Artifacts - the download artifact task (which is added automatically by Azure DevOps) fails with following:
All other build tasks work on this server without a problem, and also this release pipeline works as expected on other servers. How I can start to troubleshoot this issue as I don't see any meaningful error message?
According to your screenshot, I could reproduce the similar issue in Azure Devops Server.
But in the task, I could see the error message:
Failed in getBuildApi with error: Error: self signed certificate.
If you have the same issue, you could try the following methods:
1.You could re-config the agent with the self signed certificate.
.\config.cmd --sslcacert ca.pem xxxx
Here is a ticket about the detailed steps, you could refer to it.
2.You could check if you have set the firewall. Firewalls could block the download of artifacts
3.You could set the system environment :NODE_TLS_REJECT_UNAUTHORIZED=0 and restart the agent services.
We had similar problem with self-hosted agents but there was a minor difference - our agents were deployed in vnet.
If that's the case make sure that in vnet's subnet you have enabled Microsoft.Storage service endpoint.
Hope this will save someone tons of time.
Im new on jenkins technologie.
I started with creating a jenkins job that pull code from gitlab to jenkins. this job did not worked as I had an issue tells that jenkins does not trusted the self signed certificate used by the gitlab server
issue in screenshot
Can I did some configuration from the jenkins inetrface (from web site) to allow cloning the self signed certificate.
Any help is really appreciated.
Thank you
Caution: To be used only by understanding the security issues that will crop-up by this behaviour.
My company is hosting github enterprise with a custom certificate and hence faced similar situation. Following is the work-around I've done to mitigate the issue.
Login to jenkins server as jenkins user (I've used sudo su jenkins to do this in my case).
Add the following lines to ~/.gitconfig and save.
[http]
sslVerify = false
Restart jenkins server.
From the image you haven't specified any credentials when trying to access your repo generally you would mention some form of credentials
apart from that your computer doesn't trust the certificate from gitlab you have to add the certificate into your git(installed location)
This link will give you a detailed explaination :)
server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
I need to run Jenkins over HTTPS.
I created the certificate and put it into the keystore. Then I launched Jenkins with the following options:
--httpsPort=8443 --httpsKeyStore=/etc/pki/java/cacerts --httpsKeyStorePassword=changeit
So far so good. But I had "peer not authenticated" error when deploying a file in the Artifactory.
According to a solution here I added my artifactory certificate to the keystore.
Now I can deploy files on Artifactory but Jenkins picked up the wrong entry from the keystore (the one of Artifactory). And I have a wrong certificate associated with Jenkins.
I was not able to specify the alias which should be used by Jenkins.
According to Jenkins docs it's possible to run Jenkins with the following options:
--httpsPort=443 --httpsCertificate=path/to/cert --httpsPrivateKey=path/to/privatekey
But in this case I'm not able to use my Artifactory certificate.
How can I run Jenkins with both Jenkins and Artifactory certificates ?
Trying different things I came to an idea to rename the alias of jenkins certificate.
The new alias is jenkins.
Strangely enough it solved my problem. For me it looks more like a hack than a solution. Put your real solution here and I'll accept it.
I am performing POC for my company using Jenkins, GitBlit integration.
I have installed GitBlit & Jenkins and followed below steps
Installed Jenkins & GitBlit
used authority.cmd for generating self signed certificate for using my ip address
created a ruby cucumber project in gitblit
in the edit -> receive selection of GitBlit repository added jenkins for pre-receive scripts
in the gitblit-1.7.1\data\groovy i have added my jenkins which is again hosted on localhost
here are my urls
Jenkins :- http://localhost:8080/
GitBlit :- https://--.--.---.100:8443
GitBlit repo url :- https://--.--.---.100:8443/r/testGit.git
in jenkins, i have created freestyle project
in the source code management added repo url
i am facing issue here jenkins is not able to connect and below is the error message and screenshot
Failed to connect to repository : Command "git.exe -c core.askpass=true ls- remote -h https://--.--.---.100:8443/r/testGit.git HEAD" returned status code 128:
stdout:
stderr: fatal: unable to access 'https://--.--.---.100:8443/r/testGit.git/': SSL certificate problem: self signed certificate in certificate chain
Your choices are...
Switch to http:// rather than https://
Switch to ssh:// rather than https://
Switch to git:// rather than https://
Purchase a signed SSL certificate
Instruct Jenkins Git to not verify certificates
I´ve installed the Skip Certificate Check plugin on our Jenkins server, re-downloaded slave.jar & jnlp to the agent, but when I start them, I still get the message about the untrusted SSL certificate.
Any advice?
Thanks in advance,
Christian
Add -noCertificateCheck to the arguments for slave.jar.
If I understand the Skip Certificate Check Plugin correctly (I haven't used it) it makes the Jenkins Master process skip cert checks. E.g. to ignore the warning, when checking for updates, if you have a self-signed cert for your Subversion server.
If I understand your problem, it seems to be to get the slave to connect to the master when the master has a self-signed cert. The switch above makes the slave-process ignore cert warnings when it's connecting to the master.