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.
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.
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.
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:TLSServerfor TLS/SSL server certificate chains,TLSClientfor TLS/SSL client certificate chains, andSignedJARfor 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:
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...
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
来源：https://stackoverflow.com/questions/45191576/how-to-sign-java-webstart-application-for-java-8u141