Hello,

I have the same issue since few days with my docker  jenkins/jenkins:2.235.4-lts-jdk11 and now with jenkins/jenkins:2.235.5-lts-jdk11.

I have tried to add certificate in cacerts for site  https://updates.jenkins.io/, but it redirect to another site with another missed certificate.

 Thanks for your help

I too am experiencing the same exact issue on Jenkins 2.235.5. Plugins are not able to be downloaded due to SSL errors.

Our instance is on a corporate network where we have an internal root authority for all external traffic. We are using the -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT option as our internal root CA is trusted on all servers on the network via Domain Policy.

I get the same highlights in my error log:

2020-08-27 21:14:09.973+0000 [id=308] SEVERE h.model.UpdateCenter$DownloadJob#run: Failed to install git-client2020-08-27 21:14:09.973+0000 [id=308] SEVERE h.model.UpdateCenter$DownloadJob#run: Failed to install git-clientsun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Caused: sun.security.validator.ValidatorException: PKIX path building failed

Caused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Caused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetCaused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

Caused: java.io.IOException: Failed to load https://updates.jenkins.io/download/plugins/git-client/3.4.2/git-client.hpi to C:\Program Files (x86)\Jenkins\plugins\git-client.jpi.tmp

Caused: java.io.IOException: Failed to download from https://updates.jenkins.io/download/plugins/git-client/3.4.2/git-client.hpi

I see the same thing at work, running under Windows. At home I have a Jenkins docker image running which updates just fine.

I also noticed that trying to open the https://get.jenkins.io/war-stable/2.235.5/ on that particular machine on Chrome works fine, but under IE I get:

"This page can’t be displayed

Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://get.jenkins.io again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator. "

Not sure if this is relevant but it seems strange. If I enable SSL 2.0 and SSL 3.0 the above error disappears, but I still get a 'This page can't be displayed'.

The Let's Encrypt certificate is from 23. aug which may or may not be the date the problem started (I first noticed the problem August 25th). My personal website also uses Let's Encrypt, and also had a new certificate on this day (but in the evening vs early in the morning for the Jenkins certificate) and that works fine in IE on the same machine, although I suppose that doesn't mean much.

Jenkins is bundled with it's own JRE, so you may be using it's very old JRE hence old trust certificates that have now expired. You can update it as follows

1. Go to your Jenkins Home Folder and open the jenkins.xml file: %Jenkins_Home%/jenkins.xml

1. You will find <executable>%BASE%\jre\bin\java</executable>. This could be really old/obsolete, so replace it with the system installed java runtime like <executable>%JAVA_HOME%\jre\bin\java</executable> or a specific version like <executable>C:\Program Files\AdoptOpenJDK\jdk-8.0.265.01-hotspot\jre\bin\java</executable>.

Now you should not have the issue since it'll pick up the newer trust certificates

My configuration was already set to system java:

<executable>%JAVA_HOME%\bin\java.exe</executable>

I did, however, import our corporate certificate into the system wide java store and that seemed to do the trick after restarting the Jenkins Service:

%JAVA_HOME%\bin\keytool -importcert -file 'C:\path\to\customrootca.pem' -trustcacerts -cacerts -v

Something changed with how Jenkins is downloading plugins because this was not necessary to do until recently.
The process to update updates should still inherit the Java arguments specified in jenkins.xml in my opinion. In my deployments, I want Jenkins to always use the Windows Certificate store when running on Windows for every https connection in all threads it spawns.

manish940 - I wish you the best of luck!

Thank you Madison,

Weird thing is I'm able to update and install plugins when ever i restart the entire server.

but have to figure out a solution.

also Jenkins needs to address this. 

That IS weird; good luck isolating when exactly it starts to fail. Maybe your security proxy doesn't kick in right away or something?

Completely agree that Jenkins needs to address this! Its not feasible to constantly update the JRE trust store (%JAVA_HOME%\lib\security\cacerts) every time the JRE/JDK is updated (regardless if we use the packaged version or not). While I could use Jenkins to automate it, I'm not going to have it fix itself on principle.

Hopefully someone can isolate the root cause of this issue!

Even After configuring it to the latest <executable>%JAVA_HOME%\jre\bin\java</executable> , I still see the issue.

Did you run the keytool command to trust the Root CA?

...specifically the Root CA issuing the cert when going to:

https://updates.jenkins.io/download/plugins/git/4.4.0/git.hpi

from your Jenkins server. You can check via Chrome or cURL or something.

No i have Not.

I solved it updating the JRE files in Windows:

• Install the latest Java Runtime Engine (in this case 1.8.0_261)
• Stop the Jenkins service
• Rename or delete the jre directory in the Jenkin's installation path.
• Copy the newly installed C:\Program Files (x86)\Java\jre1.8.0_261 to the Jenkins installation jre directory
• Restart the service

where is jre directory located in Jenkins installation path.

I fixed it also. The jenkins directory had this java:
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) Client VM (build 25.66-b18, mixed mode)

I installed a new one, now it identifies with:

openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)

This seems to have solved the problem. I changed the jenkins.xml to use this one (left the old jre directory as it was) but as it seems the new one is first on the path I suppose I could have left the jenkins.xml as it was.

I don't know where the original jre came from (it wasn't me that set the machine up at the time) but I'm guessing it was installed with the initial install of Jenkins.

Have the latest Enterprise cert. and Update to latest SDK and JRE.. after initial restart it was able to install and update but have to see if it holds up.

manish940: It'll be something like `c:\Jenkins\jre\` assuming you installed Jenkins into `c:\jenkins`. In other words, if you know where your `jenkins.xml` is, it's the `jre` folder at that same location.

Thanks SID, 

ours was missing for some weird reason. 

suffice to say i copied over latest jre installation to its path.

Well this is still not working out. After every change was able to update plugins but goes back to normal next . Hopefully there is a permanent solution somewhere

One user in another report noted that the CentOS and Red Hat Enterprise Linux rpm package manager will not overwrite user modified files when it updates a package. If someone modified the java.security file in your installation, updates are written as java.security.rpmnew and are ignored by Java. It might be worth a confirmation check that there are no files named '*.rpmnew' in your Java installation.

We fixed it at our windows instance (Windows Server 2012 R2 (amd64) ) as well using the method described by Jan-Jaap van der Geer

I'm seeing this issue on our Ubuntu 20.04 server.  I've tried using JREs from both OpenJDK 11 and OpenJDK 8.  Jenkins is running from behind a proxy.  Like others have stated, this issue started happening in mid-August.  Now that some of our extensions are being flagged as a security risk due to being out of date this is getting more critical.

I can reach https://updates.jenkins.io/download/plugins/ just fine from a web browser on the system jenkins is running on.

Any recommendations would be appreciated.

There are some other solutions mentioned in the related issue https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-63506

I think I've solved my issue.  I was using -Djava.net.ssl.trustStore=<keystore> to specify our company's internal certs.  However, this replaced the system trusted certs.  I've since been able to add our internal certs to the system's cacerts database and I can now download plugins again. 

 I have resolve this problem with new jdk,  jdk1.8.0_66—> jdk1.8.0_261

i start jenkins with java, so just use new version java will fix this problem

I am having the same issue on Windows machine. So suggestion is to upgrade Java.

Currently I am using java version "1.8.0_66". Because of new license agreement by Oracle, JRE is not free anymore. We cannot download the latest 8 version.

How do I get version  jdk1.8.0_261 ? 

I tried downloading Open JDK, but the latest Open JDK version 8 I can download is  openjdk version "1.8.0_41"  which looks older than my current version 1.8.0_66

laksh see https://adoptopenjdk.net/ to download a current Java version for Windows or Linux or PowerPC or s390x.

I am having the same issue on Windows machine.

Currently I am using Jenkins 2.235.2 along with java version "1.8.0_202". I tried to use version 1.8.0_261 and 1.8.0_271 still facing the same issue. 

Any idea ? 

Same error on Jenkins 2.270 with jdk: jdk1.8.0_271 (update site: https://updates.jenkins.io/update-center.json)

0k00l

> This is caused by out of date java installations not being able to handle let's encrypt certificates. Update your java version and / or trust store.

timja I've already updated jdk to 1.8.0_271 and it doesn't work. Which java version should i use then?
I've also tried to add all Lets encrypt certs ... same error - cannot download plugins

What operating system are you on?

Some users upgraded to java 11 and that was the easiest fix for them

timja Linux (RedHat) - will try with 11

timja Got it - it was our proxy fault(one of our admins change certificate for it and tell no one ). Thank you . Problem solved.