Seeing the same issue with Oracle JDK 1.8.0_66-b17 but on openSUSE 13.1. Rolling back to 1.8.0_60 fixes the issue.

The message I see is similar to https://issues.jenkins-ci.org/browse/JENKINS-30739.

I wonder whether this in the patch notes is related:

MD5 must not be used for digital signatures where collision resistance is required. In order to prevent the usage of MD5 as digital signature algorithm during X.509 certificate operations, MD5 is added to jdk.certpath.disabledAlgorithms security property. For those applications that still using MD5 signed certificate, please upgrade the weak certificate as soon as possible.

Unfortunately it doesn't look like we have an MD5 cert…

Could you tell me the contents of the file jre/lib/security/java.security (should be /Library/Java/JavaVirtualMachines/jdk1.8.0_XX.jdk/Contents/Home/jre/lib/security/java.security on OS X), specifically the entries jdk.certpath.disabledAlgorithms and jdk.tls.disabledAlgorithms?

Could you try to change this property to see whether it works then by removing one of the values?

The properties were not changed in java.security: https://gist.github.com/ArloL/69d40f1fd21cf1749986

But when I add MD5 to jdk.certpath.disabledAlgorithms in 8u60 then I get the same error message.

Signature verification failed in update site 'default' (show details)

with the log containing these entries: https://gist.github.com/ArloL/ba77b0d4208c7fea1a4e

same on me. Centos. jsk1.8.0_65

The data I have is this:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

I tried adding MD5 to the exclusion list for tls, restarted but no change. Did same for certpath, again no change.

Try removing one of or both of the RSA/DH keySize < N entries. This is the list of what's prohibited, after all (so it can't get better when adding to it).

I tried it myself, and the workaround is to remove , RSA keySize < 1024 from the value of jdk.certpath.disabledAlgorithms in the aforementioned file.

We're still investigating the cause of this and are looking for a real solution.

Another option is to disable the signature check for the update site metadata downloaded by Jenkins, by setting the system property hudson.model.DownloadService.noSignatureCheck to true, but of course that's a stupid idea in general since it breaks trust in the data you download.

Rather than removing that option entirely, it seems to work if I change it to , RSA keySize < 512

KK fixed the key used to sign the update site metadata, and we're currently regenerating the files. Expect this to start working again in a few hours.

Please confirm whether this works ~12 hours from now so we can resolve this.

I think this is caused by the fact that we've used 512-bit RSA key to sign our update center metadata. This low bit key was chosen back then to live within the JRE key length limitation imposed by the export control.

I cannot find the record, but I believe back then we had 1024bit key limit. danielbeck thinks the current JVMs do not have any limitation, and there are documents that seem to back that up, but I'm too lazy to find out exactly when the policy has changed, so I'm sticking with 1024bit key for now.

https://ci.jenkins-ci.org/view/Infrastructure/job/infra_update_center_v3/2083/ uses a new key. This change should not have any user visible impact.

Hi there,

I saw no change so I thought.. OK.. maybe it's caching of some sort. Let's restart my server.

Much better progress. The initial signature error is gone and doesn't show any exceptions in the logs for the original problem.. However,

That first message has gone away to now be replaced by a new one.... (1.634,java 1.8.0_66-b17, ubuntu 14.04).

Strangely, there is no error in the jenkins.log.

I get the following in the jenkins.log

Oct 24, 2015 9:32:43 AM hudson.model.UpdateSite updateData
INFO: Obtained the latest update center data file for UpdateSource default

followed by the following in the web interface...

at /pluginManager/checkUpdatesServer
Signature verification failed in downloadable 'hudson.tasks.Maven.MavenInstaller' (show details)

Would you like me to open a ticket somewhere or just consider this message to be sufficient ? (which module if so).

Not sure.. same (related) problem or different one?

Thanks

Different but related issue, as the tool installer metadata is generated by a different process.

Reusing this issue for this problem. Looks like kohsuke needs to provide new secrets to the infra_backend_crawler project.

the issue "Signature verification failed in downloadable 'hudson.tasks.Maven.MavenInstaller' (show details)" is not gone....

any News on this?

For now, use the workaround by changing the Java security
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

to
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 512

jre/lib/security/java.security (should be /Library/Java/JavaVirtualMachines/jdk1.8.0_XX.jdk/Contents/Home/jre/lib/security/java.security on OS X),

I'm still having a problem with the original issue for this thread. On a fresh install of Jenkins Version 1.635 java version "1.7.0_79" when I try to do a manual update it gives me the "Signature verification failed in update site 'default' (show details)" error.

Jenkins.log shows:

SEVERE: ERROR: Signature verification failed in update site 'default' <a href='#' class='showDetails'>(show details)</a><pre style='display:none'>java.security.cert.CertPathValidatorException: timestamp check failed<br> at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:159)<br> at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(PKIXCertPathValidator.java:353)<br> at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:191)<br> at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279)<br> at org.jvnet.hudson.crypto.CertificateUtil.validatePath(CertificateUtil.java:93)<br> at jenkins.util.JSONSignatureValidator.verifySignature(JSONSignatureValidator.java:76)<br> at hudson.model.UpdateSite.verifySignature(UpdateSite.java:219)<br> at hudson.model.UpdateSite.updateData(UpdateSite.java:198)<br> at hudson.model.UpdateSite.updateDirectlyNow(UpdateSite.java:170)<br> at hudson.PluginManager.doCheckUpdatesServer(PluginManager.java:956)<br>

If I try to refresh the url http://172.16.25.157:8081/pluginManager/checkUpdatesServer
I get the error: POST is required for hudson.PluginManager.doCheckUpdatesServer

Sorry disregard my post, the timezone wasn't configured properly for the server I installed it on which caused problems with the update.

Thanks, the temporary fix on java.security works well, I've just released a [small image extension](https://hub.docker.com/r/dacr/jenkins-extended/) with it and now the issue is gone

Just adding that this also affects Ubuntu 14.04.3 LTS, running the JRE 1.8.0_65-b17 and Jenkins 1.635 .

Replacing jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024 with jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 512 in the file $JRE_HOME/lib/securityjava.security has resolved this for me as well.

Hi there,

For me, I find that if I just ignore the error, I can see the new modules (updates) by just going back to the root url.

I personally don't feel comfortable going in and forcing a lower encryption level when a key rey-gen could apparently fix this.. This will complicate java upgrades, docker containers of jenkins servers, potentially puppet and chef builds of servers, etc.

More importantly, I don't see that there will be an easy way to know when to "unhack" the setting, leaving the lower level of key setting potentially forever. I can't imagine going in and playing with the setting after every Jenkins version upgrade.

It's awesome for those that need workarounds right now, but please remember, you'll need a way to remember to set it back some day in the future.

Maybe it's no big deal, but I think I'm being responsible to ask this question at least once?

Making a workaround in a docker image for jenkins image and reverting in back in the next "tag" is as easy as anything in docker.
Anyway, I think this is a critical issue for Jenkins users.
I would love to help to investigate, but given kohsuke comment, it will be probably hard to reproduce "outside" with totally different certs and infra.

For me, I find that if I just ignore the error, I can see the new modules (updates) by just going back to the root url.

The update site itself has been fixed a month or so ago. Now the problem is with the tool metadata for when you select a version of a tool like Maven or Ant to be downloaded. So unless you expect to use recent versions of any auto-installed tools, you won't be affected (other than the error message).

unless you expect to use recent versions of any auto-installed tools, you won't be affected

But users of new installations without cached tool metadata would also be affected, right?

But users of new installations without cached tool metadata would also be affected, right?

Correct!
On a clean install I had to apply the 1024 -> 512 fix so that the NodeJS plugin could find the nodejs.org installers (JENKINS-31485).

So as I understand i.e. for a docker-spawned fresh instances this problem still exists.
Daniel, could you give some insights on the "fix" that was applied and/or why this still happens for fresh installs?

warden Please review my previous comments.

Thanks
I remember the previous comments about the the workaround, I just wanted to understand why the workaround doesn't work for tool metadata?

warden I don't understand your comment.

The workaround of only requiring 512 bit keys should work for everything. See the comment by methodgrab for confirmation.

The fix of actually having a longer key was however only applied to the update site metadata (i.e. plugins and core updates), but not to the tools metadata – which is why the latter still fails to update/download unless you apply the workaround.

Your last sentence answers exactly my question and explains why this is still an issue, thanks!

warden Was supposed to be explained in this comment I linked to earlier.

Right, sorry, I missed the second word linked of your comment. Anyway I am sure that will help others also to see this at glance now!

New signature is verified on tool metadata.

Adding data in the event others search for this error and find this thread.

I did a fresh install yesterday (2016.01.21):
Mac OS X Yosemite 10.10.5
Java: jdk-8u71-macosx-x64.dmg
Jenkins: jenkins-1.644.pkg
The above versions still exhibit the Signature verification failed message.
Setting java.security line 509 to "jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 512" still exhibits this error.
My fix was to temporarily remove “MD5,” from line 509 of java.security

$ pwd
/Library/Java/JavaVirtualMachines/jdk1.8.0_71.jdk/Contents/Home/jre/lib/security
$ diff java.security java.security.orig
509c509
< jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
—
> jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

A previous fresh install on a different machine using
Mac OS X El Capitain 10.11.2
Java: jdk-8u66-macosx-x64.dmg
Jenkins: jenkins-1.635.pkg
Did not exhibit this issue, line 509 of java.security included "jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024”

I believe this issue should not be marked as resolved because the change of the Java security file is only a workaround. Clean installation of the latest stable Jenkins server still requires to change the Java security file. Is there a proper fix on Jenkins side for this issue?

This issue was definitely fixed, but Java updates keep changing the rules, thereby moving the goalposts.

proper fix would be to change the MD5 cryptographic hash algorithm to something else

Definitely happening soon(ish), it's just that everyone with the necessary access to the secrets is traveling right now for FOSDEM this weekend (where I will continue to harass them about this).

I'm just saying this is a new issue, affecting a different version of Java, with a different problem (MD5 algorithm rather than RSA key size), and therefore should be tracked separately.

Is there a ticket about the change of the cryptographic hash algorithm? If not, could you please create one? If yes, could you please link it to this ticket?

Please let me know if you need more people to convince the team about the importance of this change and I can join your discussion in Brussels this weekend ;o)

I filed INFRA-553 for this, as its not an issue in Jenkins itself.

jtyr Come say hi at http://www.meetup.com/jenkinsmeetup/events/227464036/

I've been faced with this issue when installing Jenkins 2.1. Proposed solutions on this ticket didn't work for me. I've had to edit /etc/default/jenkins and add the following to JAVA_ARGS:

-Dhudson.model.DownloadService.noSignatureCheck=true

I'm not sure if this is considered a different bug.

Environment:

Ubuntu 14.04
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14)
Jenkins 2.1

gortazar Please file a new bug, and provide more information (relevant jenkins.log excerpts, full error messages, etc.)

danielbeck I've been trying to reproduce this issue on a fresh new Ubuntu 14.04.3, 14.04.4 and 16.04 and was unable to reproduce it. It may be something specific with our machine. Furthermore, no references arise from a google search. I think it is caused by something on our side. Do you still want me to file a new bug?

Do you still want me to file a new bug?

No. Without more information this will not be helpful.

Filed JENKINS-53288 for signature verification check I see with 2.121.3 and a clean install (after applying the RSA 512 fix).

FYI we fixed JENKINS-53710 in Jenkins 2.145 that addressed a possible regression related to signature verification in Jenkins 2.130. While we observed the problem only on Java 11, it's possible for it to also occur on Java 8.