Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8079815

JarSigner Signing with SHA1 then SHA256 Verification Fails

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Not an Issue
    • Affects Version/s: 8u40
    • Fix Version/s: None
    • Component/s: security-libs

      Description

      FULL PRODUCT VERSION :
      java version "1.7.0_75"
      Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
      Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      Darwin Rasikas-MacBook-Pro.local 14.1.0 Darwin Kernel Version 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64

      A DESCRIPTION OF THE PROBLEM :
      =========
      Description
      =========
      We are trying to sign a JAR file using JarSigner. Our target JAR is already signed by Eclipse in JDK6. When signing the JAR in JDK7 or JDK8 and verify it gives;

      jarsigner: java.lang.SecurityException: invalid SHA1 signature file digest for MyClass.class
      ==========
      Observations
      ==========
      1. Suppose we are signing a JAR with SHA1 then signing SHA256 with the [same] key / alias verification never fails.
      2. Signing a JAR with SHA1 then signing SHA256 with [different] keys / alias broke the verification.
      3. Signing a JAR with SHA1 then again SHA1 with [same/different] keys /alias never fails. This is the only workaround worked to fix our issue.

      This is also reported in stackoverflow[1]. Further, according to the java doc[2], it says "It is also possible for a JAR file to have mixed signatures".

      [1]http://stackoverflow.com/questions/12614139/what-prevents-java-from-verifying-signed-jars-with-multiple-signature-algorithms

      [2]http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html#sthref18


      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      jar should be verified. and returns "jar verified"
      ACTUAL -
      jarsigner: java.lang.SecurityException: invalid SHA1 signature file digest for MyClass.class

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      jarsigner: java.lang.SecurityException: invalid SHA1 signature file digest for MyClass.class

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      bash script is provided. Things to change;
      ============================
      1. "dummy.jar" -> a valid jar file
      2. /path/to/mykeystore -> a valid keystore
      3. /another/path/to/keystore -> another valid keystore
      4. aliasa, aliasb -> Any alias/certificate
      5. JDK6 and JDK7 paths
      =============================
      Save this as a test.sh and give executable permissions
      =============================
      JAR_FILE="dummy.jar"
      NEW_TEST_JAR="test_"$JAR_FILE
      -rm $NEW_TEST_JAR
      cp $JAR_FILE $NEW_TEST_JAR
      echo "=switching to JDK6..."
      export JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
      echo "=signing(default:SHA1)..."
      jarsigner -keystore /path/to/mykeystore $NEW_TEST_JAR aliasa
      echo "=verifying..."
      jarsigner -verify $NEW_TEST_JAR
      echo "=switching to JDK7..."
      export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_75.jdk/Contents/Home
      echo "=signing(default:SHA256)..."
      jarsigner -keystore /another/path/to/keystore $NEW_TEST_JAR aliasb
      echo "=verifying..."
      jarsigner -verify $NEW_TEST_JAR
      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      Workaround is to sign the JAR file with in JDK7 forcing SHA1.

      use the "-digestalg SHA1" parameter in jarsigner in JDK7.

        Attachments

          Activity

            People

            • Assignee:
              psonal Pallavi Sonal
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: