Does Java 9 invalidate SHA1 certificates or another issue at work?

Question

[ UPDATE ] Oracle has just revised the cryptographic map ( https://www.java.com/en/jre-jdk-cryptoroadmap.html ), they will not blame SHA -1 for code binding: 2017-03-14 Target date changed from 2017-04-18 to 2017-07-18. Narrowed scope from all SHA-1 usage: only TLS will be affected, *code signing will not not be affected at this time*. 2017-03-14 Target date changed from 2017-04-18 to 2017-07-18. Narrowed scope from all SHA-1 usage: only TLS will be affected, *code signing will not not be affected at this time*.

This in no way affects the exact answer that I received below, since it will be applied, no doubt, in the future.

-

Original post:

Trying to run our Java application deployed by Webstart on JRE 9 ea 153 , I get the following popup:

In further details, I see that the certificate will still be valid for some time:

so I wonder if the reason for abandoning SHA1 is?

It certainly sounds like a policy in line with (by other people in the industry ), but the message doesn’t really sound neophyte-friendly (especially if it is intended for end users), so I left bewilderment.

I was looking for a roadmap. This is what I found, but I'm not sure if I am interpreting this paragraph correctly:

Disable SHA-1 in certificate chains anchored by roots included by default in Oracle JDK; local or enterprise CAs are not affected. Signed code that is timestamped before 2017-01-01 is not affected.

as a cause of failure above. I would really appreciate confirmation.

FWIW, our certificate is issued by CA, which I believe is different from enterprise CA.

Thanks.

Answer 1

If this signed Jar is intended for use by end users, the package that was signed by SHA1 in 2017 will not work.

The termination of SHA1 was announced a long time ago. The only way would be to install a local CA or something else, but this will not happen on the end user machines (and should not).

To sign the Jar for your end users, you will need a new valid SHA-256 certificate from your certification authority, and re-sign any Jar that was signed with the old one after 12/31/2016. Your certificate may have expired after a few months.

Regardless of whether you have the dual purpose of your cans, it depends on the oldest version of the JVM that you are aiming for. As far as I understand, something> = 1.4.2 supports SHA-256. If you want to target even older versions (damn, when I started programming java 1.5, it was already considered OLD), you need something like double signing. More information can be found here and here.

"How to double mean a jar" is probably a new topic, because it is hardly related to this issue, which I think.