More and more updates are released and they give me the same error: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:159)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2041)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1145)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1388)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1416)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1400)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2739)
at sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2651)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1830)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:3061)
at java.net.URLConnection.getHeaderFieldLong(URLConnection.java:629)
at java.net.URLConnection.getContentLengthLong(URLConnection.java:501)
at java.net.URLConnection.getContentLength(URLConnection.java:485)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentLength(HttpsURLConnectionImpl.java:412)
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1264)
Caused: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1950)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1945)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1944)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1514)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:268)
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1280)
Caused: java.io.IOException: Failed to load https://updates.jenkins.io/download/plugins/junit/1.32/junit.hpi to /var/lib/jenkins/plugins/junit.jpi.tmp
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1287)
Caused: java.io.IOException: Failed to download from https://updates.jenkins.io/download/plugins/junit/1.32/junit.hpi (redirected to: https://get.jenkins.io/plugins/junit/1.32/junit.hpi)
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1321)
at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1869)
at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:2147)
at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1843)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:118)
at java.lang.Thread.run(Thread.java:748)

Could someone please help understand what might have happened and hwo we can sort it out?

Seeing same issue while updating plugins on windows

The Jenkins update center JSON file switched last weekend from providing HTTP URLs to providing HTTPS URLs for plugin download. There appear to be some cases where Java fails to follow the redirect that it receives. danielbeck may have more insights to offer or guesses of what might be causing the failure.

Can you report the value of the Jenkins update center on your system (from the Plugin Manager advanced tab) and the precise version and distribution of Java that you're using?

I was unable to duplicate the problem with Jenkins 2.254 using the default Update Center URL https://updates.jenkins.io/update-center.json and AdoptOpenJDK 1.8.0_262 running on Alpine Linux 3.12.0. I installed git client plugin 3.4.1 by uploading it through the advanced tab and then confirmed that the plugin manager then showed an available update to git client plugin 3.4.2. The update installed successfully when I selected it.

I also installed junit plugin 1.29 by uploading it through the advanced tab, then confirmed that the upgrade to 1.32 was offered correctly. The junit plugin upgrade from 1.29 to 1.32 was also successful.

Not a redirect problem, but the stack trace suggests that after the redirect it attempts to connect to the HTTPS URL but your Java setup doesn't like the LetsEncrypt SSL deployed at the endpoint.

Relevant clues online include:

https://stackoverflow.com/questions/59786946/javax-net-ssl-sslhandshakeexception-received-fatal-alert-handshake-failure-for

https://bugs.openjdk.java.net/browse/JDK-8221674

https://community.openhab.org/t/ssl-error-how-to-import-the-lets-encrypt-certificates-in-the-java-truststore/64671

Someone closer to the Jenkins implementation may be able to suggest suitable adjustments. This is unlikely to be Jenkins-specific, so there should be some generic solution out there that's applicable.

Suggestion :-

The LE cert has a "Digital Signature Trust Co." (DST Root CA X3) as its root, so you can check on a CentOS/RH system to see that this is present in the systems certs:

awk -v cmd='openssl x509 -noout -subject -dates' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep -i -A 2 dst

You should see something like this:

subject=O = Digital Signature Trust Co., CN = DST Root CA X3
notBefore=Sep 30 21:12:19 2000 GMT
notAfter=Sep 30 14:01:15 2021 GMT

You can do similar tests with the cacerts used by your Java installation:

awk -v cmd='openssl x509 -noout -subject -dates' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt | grep -i -A 2 dst

Adjust paths/filenames accordingly.