How to sign Java Webstart application for Java 8u141?

Asked 19/7, 2017 at 13:7 Answered 20/7, 2017 at 16:55

It looks like there has been a change by Oracle similar to Java 7u45, where new manifest values needed to be set to run signed Java Webstart applications (see here).

Currently our signed application working with Java 8u131 does not start with Java8u141 with error message Could not verify signing in resource: (arbitrary resource.jar)

Can you still run your signed Webstart application with Java 8u141, i.e. do I have a special problem?

In the release notes is a note to security changes, but they don't look related to code signing. Also crypto roadmap looks like this release has not really changed code signing, despite Java 8u131 for example, where MD5 support was removed. But Java 8u131 is working for me and Maven Java Webstart Plugin also uses SHA-256-Digest.

Timoteo answered 19/7, 2017 at 13:7 Comment(13)

Can you post the stack trace that came with this error ? – Chamkis 19/7, 2017 at 14:11

@PallaviSonal see the anwser from Bogdan O https://mcmap.net/q/1499028/-how-to-sign-java-webstart-application-for-java-8u141 , that is the very same error. – Timoteo 19/7, 2017 at 18:50

Thanks for this very helpful hack! I also had to change the following jar-Files: axis-1.4, axis-jarpc-1.4, axis-saaj-1.4, xml-commons-resolver-1.2, commons-httpclient-3.1. Now the web start application, with 137 jar-files included, starts correctly again. (Good, that I had only to patch 5 jar files, I think this are the older ones !!!) – Sappington 21/7, 2017 at 15:14

This bug is addressed as part of the bug JDK-8184993 and the fix will be available in an out-of-cycle release of JDK 8u144, which is scheduled to be released on later hours of July 26, 2017. – Chamkis 26/7, 2017 at 7:53

@PallaviSonal The core bug linked is from 2005! bugs.openjdk.java.net/browse/JDK-6233323 – Timoteo 26/7, 2017 at 11:7

@Timoteo Yes, that was fixed in JDK 9 in 2016. – Chamkis 26/7, 2017 at 11:14

@PallaviSonal, also for the JRE 8u144? I'm not sure what they mean with 'Backports' if I check bugs.openjdk.java.net/browse/JDK-8184993... I'm using JRE 1.8.0_141-b15 at this moment but the problem still exists... – Gorman 26/7, 2017 at 11:40

@Gorman The issue has been fixed in a later version JDK 8u161(which is in early access) and the fix has been back-ported to JDK 8u144. The JRE 1.8.0_141-b15 is already publicly released , so the fix is not there in this release. The new update release JDK 8u144 will be posted on Oracle'd download page sometime later today, you can download that and verify with that. – Chamkis 26/7, 2017 at 11:52

@PallaviSonal, ok thank you for the explanation! :) – Gorman 26/7, 2017 at 12:0

@PallaviSonal, is there a way to see which build is currently available from the download page before installing? – Gorman 26/7, 2017 at 12:3

@Gorman oracle.com/technetwork/java/javase/downloads/index.html , this page shows what is the currently available release version. Right now it shows Java SE 8u141 , when it is updated to Java SE 8u144, you can download it. – Chamkis 26/7, 2017 at 12:8

Ah silly me, i read '144' as '141' :) sorry! And thanks again! – Gorman 26/7, 2017 at 15:40

The new version Java 8u144 is available now and fixed the webstart signing issue for me for my old versions again. – Timoteo 27/7, 2017 at 8:23

I have found a solution or more exactly a work-around to the problem. The jar in question was in our case the commons-httpclient-3.1.jar. The manifest contains the following entry

Name: org/apache/commons/httpclient

I added a / at the end and then I signed and re-deployed the application.

Name: org/apache/commons/httpclient/

This time the web start application started without any issues. In both cases the jar was signed with java 8u141, the jarsigner could verify the jar, but the webstart did not start in the first case. In my opinion this is a webstart bug.

Gelsenkirchen answered 20/7, 2017 at 8:24 Comment(3)

I have just tested with the Java 8u152 b05 (early-access) and it works. – Gelsenkirchen 20/7, 2017 at 9:10

I removed only the dependency that was reported for me and it was working, too. I'll verify if that had the same problem. – Timoteo 20/7, 2017 at 9:35

can confirm, works with 8u152 b05 | relevant issue: bugs.openjdk.java.net/browse/JDK-8184993 – Coray 11/8, 2017 at 19:27

I had the same problem with Java Webstart Application for java 8u141. It contains commons-httpclient-3.1.jar too. The problem exactly in this jar.

It looks like the algorithm of verification was changed. Now all manifest entries should have digest. I found out that this original jar has already contained one manifest entry org/apache/commons/httpclient without digest:

Name: org/apache/commons/httpclient
Implementation-Title: org.apache.commons.httpclient
Implementation-Version: 3.1
X-Compile-Target-JDK: 1.2
Specification-Vendor: Apache Software Foundation
Specification-Title: Jakarta Commons HttpClient
Implementation-Vendor-Id: org.apache
Extension-name: org.apache.commons.httpclient
X-Compile-Source-JDK: 1.2
Specification-Version: 3.1
Implementation-Vendor: Apache Software Foundation

I fixed problem by changing ant jar task settings. I added to exclude .MF files for 'zipfileset' (possible .SF, .RSA, .DSA files too). Also it can be required to change attribute 'filesetmanifest' = merge.

It prevents appearing that manifest entry in final signed jar.

Meraz answered 20/7, 2017 at 9:49 Comment(0)

There was a change affecting code signing: SHA-1 certificates were disabled. This is mentioned in the release notes you linked to. In particular they mention:

A new constraint named usage, that when set, restricts the algorithm if it is used in a certificate chain for the specified use(s). Three usages are initially supported: TLSServer for TLS/SSL server certificate chains, TLSClient for TLS/SSL client certificate chains, and SignedJAR for certificate chains used with signed JARs.

(emphasis mine). Note also that the release notes discuss the entire certificate chain. So even if your signing cert uses a newer/stronger hash algorithm (SHA2 etc.), it could still be rejected if the issuing authority's certificate used SHA1.

More details at:

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

http://openjdk.java.net/jeps/288

Counterpoint answered 19/7, 2017 at 16:59 Comment(2)

In my understanding this does not affect code signing. But even if I'm wrong, why does this affect SHA-2 code signing certificates? – Timoteo 19/7, 2017 at 18:43

If there is a SHA1 cert in the chain, so why does jarsigner valide the jar as valid with "jar verified"? In first tests it even looks like really only this one jar is affected. I believe this is a bug. – Timoteo 20/7, 2017 at 7:6

I had the very same problem. My solution was to remove all directory entries in the jar (as they are useless normally) either by modifying the build scripts (ant:jar filesOnly="true") or with small groovy script to repack the jar without the dir entries.

This is definitely a JWS bug - I'm wondering how this went unnoticed by Oracle and if they will deliver a fast fix for this...

Depreciate answered 20/7, 2017 at 11:57 Comment(0)

I had problems for commons-httpclient-3.1.jar, axis-1.4.jar, xml-resolver-1.2.jar, oro-2.0.8.jar. Open the MANIFEST.MF add "/" in the end for name. re-build and sign the project and now it works

Bamako answered 20/7, 2017 at 16:55 Comment(0)

Recommended topics

Hot tags