Applet: Java.lang.SecurityException: class “…”'s signer information does not match singer information of other classes in the same package

Question

I have an applet that will not load for 1 client who is running IE7 on Vista.

The error is:

java.lang.SecurityException: class "com.arup.web.printing.WebPrintApplet"'s signer information does not match signer information of other classes in the same package.

The applet code is in a jar file named: WebPrintApplet.jar and it has a dependency on Sun's PdfRenderer.jar. I have signed both of the jar files with the same certificate and we are hosting the jar files from the same folder on our web server.

I am at a loss for what could cause this issue in our case. My applet's code is all within the com.arup.web.printing.WebPrintApplet package and the entire jar file is signed.

Any clues as to the issue and how to resolve it?

Answer 1

I have signed both of the jar files with the same certificate and we are hosting the jar files from the same folder on our web server.

If one of the Jars was already signed, it will now have multiple digital signatures. That could cause the error seen.

As an aside, a Java 7 JRE should support deploying embedded applets using JWS, which in turn allows sand-boxed access to the printer. Here is a demo. or the JNLP PrintService.

Answer 2

As you seem to have long test cycles you may want to investigate another source of failure. This error typically comes up if you have classes in the same package in two different jar files, for example if you have extensions / changes to the pdf renderer in your jar file. I think you should avoid such constructs by design and where not possible, you must have the same signer information for the two jars.

The current plugins support different signers on different jars, but i don't know exactly how the implementation is with many signers on different jars with "shared" packages.

Answer 3

I know this is two years old, but it may help someone in my situation:

Put the jar of the offending class in $JDK/jre/lib/ext/ and retry with a fresh JVM process.