GeeCON Prague 2014*
The moose likes Security and the fly likes Signed Jars and HTTPS Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Security
Bookmark "Signed Jars and HTTPS" Watch "Signed Jars and HTTPS" New topic
Author

Signed Jars and HTTPS

Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
I'm running a web application from jetty, which involves an applet on the client-side, JSPs/servlets on the server.

The applet jars needs to be signed during our build proces (by my company's keystore based on our purchased cert) but the customer will need to provide their own cert to run the https pages.

Is there a way to do this? Right now, I"m getting the "signer information does not match signer information of other classes in the same package" when I try to run it in HTTPS. This could be due to my jetty HTTPS settings not being quite ready (pointing at a keystore which is incorrect) - but I want to make sure that I can at least do what I need to do? If so, any suggestions/advice/tips would be most welcome!

thanks
Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
I'm trying to use the KeyStore that the applets were signed with on my local build as the KeyStore I'm pointing to when starting up Jetty. This still leads to the 'signer information does not match signer information of other classes in the same package' error when trying to accept one of my signed jars for use.

I also tried using a self signed certificate keystore for running Jetty and had the same problem.

When not running in HTTPS, I can use all the signed jars and everything works fine. Is the conflict between the signature on the jars and the one jetty's using for SSL? And if so, why doesn't accepting all the jars and certs help out? I may need to do something programatically in the code for this, I guess - tho I'm not sure where to start out.

If anyone's had a similar problem, I'd appreciate hearing how you'd worked it out.

thanks,
tOm
Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
One more thing I should add: When I try to directly access the jsp that's loading the jar causing the 'mismatched signing info' error - I dont see the problem.
Lin Feng
Ranch Hand

Joined: Dec 11, 2002
Posts: 142
I am wondering if you have two JSSE implementations installed. One from SUN JDK and another from Jetty. They could have confliction. The reason for that exception is you have a package spreaded in several jars. Some of them are signed and some of them are not signed or signed by another company. As you mentioned if the HTTPS was removed , everything is fine. So the signed Applet jar should be fine. So try to remove the SUN JSSE and see what will happen


Hope this help.

Lin
[ May 03, 2005: Message edited by: LIN FENG ]
Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
Thanks for the idea, Lin.

Is there a certain jar that I should be looking for which would indicate multiple installations?
Lin Feng
Ranch Hand

Joined: Dec 11, 2002
Posts: 142
Do you have the exception detail message? It should tell you when the class loader tries to load what class this exception was thrown.

Lin
Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
It's having problems with the QPMain.class.

I've been getting rid of any outdated/extra jsse.jar instances. I think that's the jar I need to worry about with the Sun/Jetty conflicts.


Here's my exception stack:

java.lang.SecurityException: class "QPMain"'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$100(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 sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Lin Feng
Ranch Hand

Joined: Dec 11, 2002
Posts: 142
Hi Tom,

I might be totally wrong on this. Is the QPMain in the jar signed by you ? The exception stack shows when the Applet class loader tries to load the QPMain the exception was thrown. If the QPMain is an user class ..... then all Jetty/Sun confliction assumptions could be wrong , I got to take back what I said . SSL should have no impact on class loading but the phenomenon was after you changed that to HTTPS the exception was thrown , if it was changed back to HTTP everything was fine. Even there is an unsigned jar on the client host , it does not make any sense that the JVM load class from local jar when the protocol is http and load class from code base when the protocol is https. The transport protocol should be transparent to class loader.

Could we get more information ?

Thanks

Lin
Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
Yes, the QPMain jar is one of my jars, which I've signed. It's one of 3 which are all signed with the same key. What other info would help?
Lin Feng
Ranch Hand

Joined: Dec 11, 2002
Posts: 142
Have a stupid question. Is there a class in the same package on your local classpath incidently? The class loader should have already loaded some classes in the same package with different signature. When it was loading this class , it detected confliction. But I cannot explain why it works well in HTTP. Is the QPMain the second user class or the third user class to be loaded ?

Thanks

Lin
Tom Katz
Ranch Hand

Joined: Aug 19, 2002
Posts: 169
well, I got my problem fixed by just putting all my classes in one signed jar.. in hindsight, seems like an obvious fix that only took me two days to see...

ahh, nothing like the learning process.
Lin Feng
Ranch Hand

Joined: Dec 11, 2002
Posts: 142
Great News. Congratulation.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Signed Jars and HTTPS