JDK-8049480 : Current versions of Java can't verify jars signed and timestamped with Java 9
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7u60
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2014-07-03
  • Updated: 2017-05-04
  • Resolved: 2014-07-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u131Fixed 7u76Fixed
Related Reports
Relates :  
JDK-8179614 - Test for jarsigner on verifying jars that are signed and timestamped by other JDK releases
Relates :  
JDK-8038837 - Add support to jarsigner for specifying timestamp hash algorithm
Description
FULL PRODUCT VERSION :
"Consumer" JRE
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing)

"Producer" JDK
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b20)
Java HotSpot(TM) Client VM (build 1.9.0-ea-b20, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
According to the latest security recommendations from Oracle, I have been trying to timestamp my jar files at signature time. If I sign with JDK 9, JRE 7 complains "Found unsigned entry in resource".

Complete compatibility matrix as far as I can see:
Sign | Run  | Works?
With | With | Works?
  7    7    Y
  8    7    Y
  9    7    N
  7    8    Y
  8    8    Y
  9    8    N
  7    9    Y
  8    9    Y
  9    9    Y
  
It looks like this is a bug in the signature process rather than the verification process, but it may be a problem with the verification instead?

REGRESSION.  Last worked in version 8u20

ADDITIONAL REGRESSION INFORMATION: 
"Consumer" JRE
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing)

"Producer" JDK
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b20)
Java HotSpot(TM) Client VM (build 1.9.0-ea-b20, mixed mode, sharing)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a small webstart application
2. Obtain a code signature certificate
3. Sign with JDK 9 
C:\>"C:\Program Files (x86)\Java\jdk1.9.0\bin\jarsigner.exe" -storepass password -tsa https://timestamp.geotrust.com example.jar.9b20 test
4. Launch the webstart application from a machine without JDK 9 installed

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should launch and run normally
ACTUAL -
The application doesn't run, claiming that the JAR file contains unsigned entries

ERROR MESSAGES/STACK TRACES THAT OCCUR :
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://webstart.example.com/test.jar.9b20
	at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
	at com.sun.javaws.security.SigningInfo.check(Unknown Source)
	at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
	at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.launch(Unknown Source)
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main.access$000(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Don't use timestamping or timestamp with JDK 8 or earlier
Comments
The filer is correct. When we backported 7180907 to 7u, we wanted to be conservative. Therefore the name of the AlgorithmId itself ("SHA256") is not updated (in JDK 8, it's "SHA-256"). Instead, we made a small tweak inside SignerInfo to hard code the "SHA256" -> "SHA-256" translation for jar signature verification, and we missed the timestamp verification. The planed fix is to extend the "translation" to timestamp verification.
08-07-2014
Update from the filer: Hi, I'm the reporter of JI-9013191 and I just wanted to follow up with some more information, since I can't see or comment on the bug in the OpenJDK JIRA instance. Hope this is the right place. I'm having problems with JAR files signed and timestamped with JDK9 - they fail validation under JDK7u60. It looks like this is due to the fact that JDK9 timestamps by default using SHA-256 - but in the JDK 7u tree, AlgorithmId.java is missing a backport of changeset JDK-7180907 which means that SignatureFileVerifier#verifyTimestamp fails since it is looking for an algorithm with the non-standard name SHA256 (without a hyphen). By the way, the bug report talks about Web Start, but the minimal reproducable case is much easier and doesn't involve Web Start: - create a jar with one file in it - sign and timestamp with JDK9 using default settings - verify with JDK7 -> verification failure "jar is unsigned. (signatures missing or not parsable)" Running the verification with -J-Djava.security.debug=jar gives jar: processEntry: processing block jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256 MessageDigest not available jar: done with meta! jar: nothing to verify! Hope that helps, Robert
07-07-2014