JDK-6805618 : Exception: signer information does not match signer information of other classes in the same package
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u7
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows
  • CPU: x86
  • Submitted: 2009-02-13
  • Updated: 2012-07-08
  • Resolved: 2012-07-08
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
6-poolResolved 7Resolved
Related Reports
Relates :  
Description
* Observed Error

java.lang.SecurityException: class
"com.adaptiveplanning.ui.desktop.utility.AppletErrorLogger"'s signer
information does not match signer information of other classes in the
same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at
com.adaptiveplanning.ui.desktop.aptreetable.APTreeTableApplet.doStart(AP
TreeTab leApplet.java:70)
at
com.adaptiveplanning.ui.desktop.utility.APBaseApplet.start(APBaseApplet.
java:53 )
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


* Below is the jvm code excerpt which generates the error:

751     private synchronized void checkCerts(String name, CodeSource cs) {
752     int i = name.lastIndexOf('.');
753     String pname = (i == -1) ? "" : name.substring(0, i);

754     java.security.cert.Certificate[] pcerts =
755         (java.security.cert.Certificate[]) package2certs.get(pname);

756         if (pcerts == null) {

757             // first class in this package gets to define which
758             // certificates must be the same for all other classes
759             // in this package

760             if (cs != null) {
761                 pcerts = cs.getCertificates();
762             }
763             if (pcerts == null) {
764                 if (nocerts == null)
765                     nocerts = new java.security.cert.Certificate[0];
766                 pcerts = nocerts;
767             }
768             package2certs.put(pname, pcerts);
769         } else {
770             java.security.cert.Certificate[] certs = null;
771             if (cs != null) {
772                 certs = cs.getCertificates();
773             }
774

--> the certificate of the current class does not match the certificate
    recorded in the first class loaded from the same package


775             if (!compareCerts(pcerts, certs)) {
776                 throw new SecurityException("class \""+ name +
777                 "\"'s signer information does not match signer information of other classes in the same package");
778             }
779         }
780     }
781


*  It seems to be pointing to the fact that the AppletErrorLogger class is
signed with a different cert as the first class in the same package
com.adaptiveplanning.ui.desktop.utility.

But CU claimed that all classes is signed with the same cert:

sm      3047 Wed Jan 28 15:49:34 PST 2009 com/adaptiveplanning/ui/desktop/utility/AppletErrorLogger.class

      X.509, CN="Adaptive Planning, Inc.", OU=Digital ID Class 3 - Java Object Signing, O="Adaptive Planning, Inc.", L=Mountain View, ST=California, C=US
      [certificate will expire on 8/3/09 4:59 PM]
      X.509, CN=VeriSign Class 3 Code Signing 2004 CA, OU=Terms of use at https://www.verisign.com/rpa (c)04, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
      [certificate is valid from 7/15/04 5:00 PM to 7/15/14 4:59 PM]
      X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
      [certificate is valid from 1/28/96 4:00 PM to 8/1/28 4:59 PM]


sm      1112 Wed Jan 28 15:49:32 PST 2009 com/adaptiveplanning/ui/desktop/utility/APBaseApplet$1.class
       X.509, CN="Adaptive Planning, Inc.", OU=Digital ID Class 3 - Java Object Signing, O="Adaptive Planning, Inc.", L=Mountain View, ST=California, C=US       [certificate will expire on 8/3/09 4:59 PM]
      X.509, CN=VeriSign Class 3 Code Signing 2004 CA, OU=Terms of use at https://www.verisign.com/rpa (c)04, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US       [certificate is valid from 7/15/04 5:00 PM to 7/15/14 4:59 PM]
      X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US       [certificate is valid from 1/28/96 4:00 PM to 8/1/28 4:59 PM]


Attached is the full output from jarsigner and the jar file.

Comments
EVALUATION The issue looks like is caused by mixed-code feature which introduced in JRE 6u19, and this feature is just forward port to JDK7 in b136, I will assume the customer will see the same problem in JDK7 after b136. Do we have a testcase for the issue they reported? a simple testcase will be the best, or we can access their applet to reproduce the bug. The new mixed code feature request more restrict signing for different jar files, especially when you are loading different classes from different jar files, I think this is the case IBM is trying to do, we need to have their signed jar file to see anything may break this rule, I see only one jar file attached to the bug report, any other signing jar in their testcase?
31-03-2011