-
Bug
-
Resolution: Won't Fix
-
Critical
-
None
-
Jenkins 2.254 running on CentOS 7 (OpenJDK8) with macOS agents
Recently, the plugin update functionality is returning the following error for all plugins I try to update when trying to download and installed the plugin updates:
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/plugin-util-api/1.2.3/plugin-util-api.hpi to /var/lib/jenkins/plugins/plugin-util-api.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/plugin-util-api/1.2.3/plugin-util-api.hpi (redirected to: https://get.jenkins.io/plugins/plugin-util-api/1.2.3/plugin-util-api.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)
I do not see any change nor have been informed of any company network configuration change (where the CentOS based VM with the Jenkins root node installed on is located) that could explain it.
The core of the error seems to be this part (it might be a red herring though... has it always been redirecting?): "Caused: java.io.IOException: Failed to download from https://updates.jenkins.io/download/plugins/plugin-util-api/1.2.3/plugin-util-api.hpi (*redirected to: https://get.jenkins.io/plugins*/plugin-util-api/1.2.3/plugin-util-api.hpi)"
Edit: the "preparation checks" Jenkins does before attempting to update each plugin succeed and I had been able to update plugins regularly up until this week:
"Preparation
Checking internet connectivity
Checking update center connectivity
Success"
- is related to
-
-
- Closed
-
[JENKINS-63506] Unable to update plugins (ssl error downloading plugin)
Goffredo Marocchi
added a comment - Could someone please help understand what might have happened and hwo we can sort it out?
Goffredo Marocchi
added a comment - Could someone please help understand what might have happened and hwo we can sort it out? 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://bugs.openjdk.java.net/browse/JDK-8221674
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.
Goffredo Marocchi
added a comment - Hello markewaite,
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?
Update Center URL: http://updates.jenkins-ci.org/update-center.json
Java version:
| java.runtime.name | OpenJDK Runtime Environment |
| java.runtime.version | 1.8.0_262-b10 |
| sun.java.command | /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --httpPort=8082 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20 |
Goffredo Marocchi
added a comment - Hello markewaite ,
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?
Update Center URL: http://updates.jenkins-ci.org/update-center.json
Java version:
java.runtime.name
OpenJDK Runtime Environment
java.runtime.version
1.8.0_262-b10
sun.java.command
/usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --httpPort=8082 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20
Changed the update center URL to the one you specified above and I am still getting 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.GeneratedConstructorAccessor512.newInstance(Unknown Source) 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/blueocean-display-url/2.4.0/blueocean-display-url.hpi to /var/lib/jenkins/plugins/blueocean-display-url.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/blueocean-display-url/2.4.0/blueocean-display-url.hpi (redirected to: https://get.jenkins.io/plugins/blueocean-display-url/2.4.0/blueocean-display-url.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.Futu
Goffredo Marocchi
added a comment - - edited Changed the update center URL to the one you specified above and I am still getting 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.GeneratedConstructorAccessor512.newInstance(Unknown Source)
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/blueocean-display-url/2.4.0/blueocean-display-url.hpi to / var /lib/jenkins/plugins/blueocean-display-url.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/blueocean-display-url/2.4.0/blueocean-display-url.hpi (redirected to: https://get.jenkins.io/plugins/blueocean-display-url/2.4.0/blueocean-display-url.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.Futu
Goffredo Marocchi
added a comment - [j@ ~]$ 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 unable to load certificate 140240419768208:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE 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 [jenkins@ldnci21 ~]$ awk -v cmd='openssl x509 -noout -subject -dates' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep -i -A 2 dst unable to load certificate 139712196855696:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE 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 [j@ ~]$
Goffredo Marocchi
added a comment - rotan
[j@ ~]$ 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
unable to load certificate
140240419768208:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
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
[jenkins@ldnci21 ~]$ awk -v cmd= 'openssl x509 -noout -subject -dates' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep -i -A 2 dst
unable to load certificate
139712196855696:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
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
[j@ ~]$
panajev, if you add "-Djavax.net.debug=ssl" to the java command that starts your server, you should get SSL-related debug information in the output, and therein you should find a line like:
truststore is: <some/path/to/cacerts>
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
You need to make sure that your openssl tests are examining the certs file that your Java is using, not other versions of the file(s) that other tools/platforms on your system are using.
I encountered the same problem after updating to Jenkins 2.235.5 running on CentOS 7. I was also running java-1.8.0-openjdk. I tried apennding the -Dhttps.protocols option to JAVA_OPTS, but that didn't do it. Out of desperation, I upgraded to OpenJDK 11 and it worked.
Here is what I did:
[user@jenkins ~]$ sudo yum install java-11-openjdk [user@jenkins ~]$ sudo update-alternatives --config java There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- *+ 1 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/jre/bin/java) 2 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el7_8.x86_64/bin/java) Enter to keep the current selection[+], or type selection number: 2 [user@jenkins ~]$ java -version openjdk version "11.0.8" 2020-07-14 LTS OpenJDK Runtime Environment 18.9 (build 11.0.8+10-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode, sharing) [user@jenkins ~] sudo systemctl restart jenkins
After restarting Jenkins, I went to Manage Jenkins -> Manage Plugins and was able to update as expected.
If you attempt the above and it doesn't work, and you'd like to switch back to OpenJDK 8, run sudo update-alternatives --config java again and select correct version.
Jim
added a comment - - edited I encountered the same problem after updating to Jenkins 2.235.5 running on CentOS 7. I was also running java-1.8.0-openjdk . I tried apennding the -Dhttps.protocols option to JAVA_OPTS , but that didn't do it. Out of desperation, I upgraded to OpenJDK 11 and it worked.
Here is what I did:
[user@jenkins ~]$ sudo yum install java-11-openjdk
[user@jenkins ~]$ sudo update-alternatives --config java
There are 2 programs which provide 'java' . Selection Command
-----------------------------------------------
*+ 1 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/jre/bin/java)
2 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el7_8.x86_64/bin/java)
Enter to keep the current selection[+], or type selection number: 2
[user@jenkins ~]$ java -version
openjdk version "11.0.8" 2020-07-14 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.8+10-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode, sharing)
[user@jenkins ~] sudo systemctl restart jenkins
After restarting Jenkins, I went to Manage Jenkins -> Manage Plugins and was able to update as expected.
If you attempt the above and it doesn't work, and you'd like to switch back to OpenJDK 8, run sudo update-alternatives --config java again and select correct version.
As far as I can tell, this is now resolved as much as it can be from the Jenkins infrastructure. The transition from http to https for plugin downloads is complete. panajev, dshanks, and scuttlebutt, can you confirm that you can download plugin updates?
Goffredo Marocchi
added a comment - Hello markewaite I have worked with our IT/DevSupport team to ensure the root Jenkins nodes accepts the Let's Encrypt Root Cert in the available trust stores (CentOS 7 VM running Jenkins's latest version) and we are still getting the same error as before:
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.GeneratedConstructorAccessor318.newInstance(Unknown Source) 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/ldap/1.25/ldap.hpi to /var/lib/jenkins/plugins/ldap.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/ldap/1.25/ldap.hpi (redirected to: https://get.jenkins.io/plugins/ldap/1.25/ldap.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)
Can you link us to the work where the transition to https for plugins was completed with? Maybe it is as simple as us still needing to make a very very simple but critical change to our VM to accept the certificate the plugins are signed with.
Goffredo Marocchi
added a comment - Hello markewaite I have worked with our IT/DevSupport team to ensure the root Jenkins nodes accepts the Let's Encrypt Root Cert in the available trust stores (CentOS 7 VM running Jenkins's latest version) and we are still getting the same error as before:
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.GeneratedConstructorAccessor318.newInstance(Unknown Source)
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/ldap/1.25/ldap.hpi to / var /lib/jenkins/plugins/ldap.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/ldap/1.25/ldap.hpi (redirected to: https://get.jenkins.io/plugins/ldap/1.25/ldap.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)
Can you link us to the work where the transition to https for plugins was completed with? Maybe it is as simple as us still needing to make a very very simple but critical change to our VM to accept the certificate the plugins are signed with. Here are some of the links to the work that transitioned the Jenkins update center from HTTP to HTTPS. The transition was part of the switch from using outdated and unmaintained "mirrorbrain" to "mirrorbits". Changes included:
- https://github.com/jenkins-infra/update-center2/pull/429
- https://github.com/jenkins-infra/update-center2/pull/430
- https://github.com/jenkins-infra/update-center2/pull/431
- https://github.com/jenkins-infra/update-center2/pull/432
- https://github.com/jenkins-infra/update-center2/pull/433
- https://github.com/jenkins-infra/update-center2/pull/436
- https://github.com/jenkins-infra/update-center2/pull/437
Those were all part of the transition process that now allows us to use HTTPS to download plugins and to see the mirror status through URL's like https://updates.jenkins.io/latest/git.hpi?mirrorlist
Since an earlier comment mentions that the user resolved it on CentOS 7 by running OpenJDK 11, you might consider that option, or you might try downloading and installing AdoptOpenJDK 8. Those two solutions may provide newer certificate definitions than the CentOS 7 certificate definitions.
Hello markewaite , we updated to OpenJDK 11 and that apparently fixed the issue for us too. Still very very perplexed :/.
Thank you for your help!
Goffredo Marocchi
added a comment - - edited Hello markewaite , we updated to OpenJDK 11 and that apparently fixed the issue for us too. Still very very perplexed :/.
Thank you for your help! That is good news panajev. I still feel some concern that this may indicate that the OpenJDK 8 provided with CentOS 7 is reading different CA certificate definitions than OpenJDK 11 provided with CentOS 7. However, JDK 11 is supported by the Jenkins project, works very well, and is regularly covered by automated tests on ci.jenkins.io.
updated to oracle JDK 11, still not able to download plugins. Getting the below error:
 Failure -sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.build(Unknown Source) at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source) at java.security.cert.CertPathBuilder.build(Unknown Source) Caused: sun.security.validator.ValidatorException: PKIX path building failed at sun.security.validator.PKIXValidator.doBuild(Unknown Source) at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at sun.security.validator.Validator.validate(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) Caused: javax.net.ssl.SSLHandshakeException at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.Handshaker.fatalSE(Unknown Source) at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source) at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source) at sun.security.ssl.Handshaker.processLoop(Unknown Source) at sun.security.ssl.Handshaker.process_record(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source) at java.net.URLConnection.getHeaderFieldLong(Unknown Source) at java.net.URLConnection.getContentLengthLong(Unknown Source) at java.net.URLConnection.getContentLength(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentLength(Unknown Source) at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1227) Caused: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source) at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1243) Caused: java.io.IOException: Failed to load https://updates.jenkins.io/download/plugins/credentials/2.3.11/credentials.hpi to E:\Apps\Jenkins\plugins\credentials.jpi.tmp at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1250) Caused: java.io.IOException: Failed to download from https://updates.jenkins.io/download/plugins/credentials/2.3.11/credentials.hpi at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1284) at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1832) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:2110) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1806) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:111) at java.lang.Thread.run(Unknown Source) |
dshanks you may want to review all the comments in case one of them helps you with your investigation. I'm reasonably confident the issue is not something that the Jenkins project can resolve for you.
Nick Sonneveld
added a comment - G'day, I had the exact same issue (centos7, jdk8, jenkins-stable) but was reluctant to upgrade from jdk8 to 11.
Turns out we had modified our `java.security` file sometime in the past, so yum was carefully putting the updated policy file (configured with all the newer ciphers,etc) in `java.security.rpmnew`. My fix was to overwrite our `java.security` file with the up to date `java.security.rpmnew`. You may want to see what changes you made to your original and translate them across.
Might also be worth checking for any other left over `.rpmnew` files in your openjdk directory.
Example fix steps (adjust for your environment):
$ cd /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.222.b10-0.el7_6.x86_64/jre/lib/security/ $ ls blacklisted.certs cacerts java.policy java.security java.security.rpmnew local_policy.jar nss.cfg policy US_export_policy.jar # sanity check $ diff java.security java.security.rpmnew $ mv java.security java.security.20200917 $ mv java.security.rpmnew java.security
Nick Sonneveld
added a comment - G'day, I had the exact same issue (centos7, jdk8, jenkins-stable) but was reluctant to upgrade from jdk8 to 11.
Turns out we had modified our `java.security` file sometime in the past, so yum was carefully putting the updated policy file (configured with all the newer ciphers,etc) in `java.security.rpmnew`. My fix was to overwrite our `java.security` file with the up to date `java.security.rpmnew`. You may want to see what changes you made to your original and translate them across.
Might also be worth checking for any other left over `.rpmnew` files in your openjdk directory.
Example fix steps (adjust for your environment):
$ cd /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.222.b10-0.el7_6.x86_64/jre/lib/security/
$ ls
blacklisted.certs cacerts java.policy java.security java.security.rpmnew local_policy.jar nss.cfg policy US_export_policy.jar
# sanity check
$ diff java.security java.security.rpmnew
$ mv java.security java.security.20200917
$ mv java.security.rpmnew java.security
Nick Sonneveld
added a comment - I don't know if this is worth documenting in the Jenkins LTS Upgrade Guide? Or performing a sanity check before initiating an update download? These new infrastructure changes might trip up people who have long-lived jenkins servers but not realise their package manager hasn't been keeping their modified java security policy up to date.
Nick Sonneveld
added a comment - I don't know if this is worth documenting in the Jenkins LTS Upgrade Guide? Or performing a sanity check before initiating an update download? These new infrastructure changes might trip up people who have long-lived jenkins servers but not realise their package manager hasn't been keeping their modified java security policy up to date. I like the idea very much sonneveld.
Is the existence of `java.security.rpmnew` a reliable indicator that the RPM package manager detected user changes and intentionally avoided overwriting the user changes?
Is there a Java command that could be executed to show that the current java.security configuration does not recognize the SSL certificate from https://updates.jenkins.io/ and could then be used to confirm that the updated `java.security` file now allows it?
Nick Sonneveld
added a comment - markewaite I tried to find some more official documentation but the best I could find was https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html which describes the .rpmnew/.rpmsave behaviour and https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/ which offers some advice. Basically an rpm can define config files, and if it was modified (and depending on the options specified) then the config file can be replaced (and the original saved as .rpmsave), or the config file is left as if (and the new config is saved as .rpmnew).
In regards to a java command, there could be a better option, but I put together a test java program based on some sample code:
import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.net.HttpURLConnection; import java.net.URL; public class DownloadWebpageExample { public static void main(String[] args) { try { URL url = new URL("https://updates.jenkins.io/download/plugins/plugin-util-api/1.2.5/plugin-util-api.hpi"); HttpURLConnection con = (HttpURLConnection) url.openConnection(); readStream(con.getInputStream()); // Give output for the command line } catch (Exception e) { e.printStackTrace(); } } private static void readStream(InputStream in) { char[] buf = new char[1024]; try (BufferedReader reader = new BufferedReader(new InputStreamReader(in));) { while (reader.read(buf, 0, 1024) != -1) { } } catch (IOException e) { e.printStackTrace(); } } }
And ran like so:
$ javac DownloadWebpageExample.java $ java -Dhttps.proxyHost=proxyhostname -Dhttps.proxyPort=80 -cp . DownloadWebpageExample
Nick Sonneveld
added a comment - markewaite I tried to find some more official documentation but the best I could find was https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html which describes the .rpmnew/.rpmsave behaviour and https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/ which offers some advice. Basically an rpm can define config files, and if it was modified (and depending on the options specified) then the config file can be replaced (and the original saved as .rpmsave), or the config file is left as if (and the new config is saved as .rpmnew).
In regards to a java command, there could be a better option, but I put together a test java program based on some sample code:
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
public class DownloadWebpageExample {
public static void main( String [] args) {
try {
URL url = new URL( "https: //updates.jenkins.io/download/plugins/plugin-util-api/1.2.5/plugin-util-api.hpi" );
HttpURLConnection con = (HttpURLConnection) url.openConnection();
readStream(con.getInputStream());
// Give output for the command line
} catch (Exception e) {
e.printStackTrace();
}
}
private static void readStream(InputStream in)
{
char [] buf = new char [1024];
try (BufferedReader reader = new BufferedReader( new InputStreamReader(in));) {
while (reader.read(buf, 0, 1024) != -1) { }
} catch (IOException e) {
e.printStackTrace();
}
}
}
And ran like so:
$ javac DownloadWebpageExample.java
$ java -Dhttps.proxyHost=proxyhostname -Dhttps.proxyPort=80 -cp . DownloadWebpageExample
I encountered this problem to, using Fedora20, and java 1.8.0_45-b14. There is no option to go to Java 11 on Fedora 20, So Java upgrade is not a solution for me. Neither is OS upgrade due to government requirements. Options?
I succeeded by changing over to Adoptopenjdk 8.
This was suggested in a comment, and I found there was a linux archive available that I could use with Fedora.
John Rocha
added a comment - - edited I encountered this problem to, using Fedora20, and java 1.8.0_45-b14. There is no option to go to Java 11 on Fedora 20, So Java upgrade is not a solution for me. Neither is OS upgrade due to government requirements. Options?
I succeeded by changing over to Adoptopenjdk 8.
This was suggested in a comment, and I found there was a linux archive available that I could use with Fedora. java 1.8.0_45-b14
New Jenkins installs have required a newer JRE than this for the last three years, see changelog for 2.77.
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.
shashank chouksey
added a comment - please help me also i am using latest version of jenins and latest ubuntu version 20.04 but still ssl connection problem
shashank chouksey
added a comment - please help me also i am using latest version of jenins and latest ubuntu version 20.04 but still ssl connection problem shashank2244 asking for help on a closed issue that is unlikely related to your issue is not very effective. Most of the people who might be able to help will not see your request.
The Jenkins community forum https://community.jenkins.io/ is a much better place to ask questions and request help.
In the case that you're describing, it could be that your operating system needs to be updated to the latest package versions (ca-certificates is a package that can cause this type of message if it is too old). It could be that a corporate proxy is doing some harm. It could be that you're running a Java version that is too old. All those things are not issues with Jenkins and are best handled by posting a good question on the community forum with lots of background information. Others will need to know the Jenkins version you are running, the Java version you are running, and will want your confirmation that you've updated the operating system will all the latest patches. If you are behind a corporate proxy, they may need
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)