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.