I have an applet that's embedded on a web page that's in a signed secure jar which is self sufficient, meaning it doesn't have any dependency on any other jars. The applet works fine unless "online certification validation" is enabled through Java Control Panel -> Advanced tab -> Settings -> Security -> General -> Enabled online certification validation checkbox.
If online certification is enabled, the JVM cannot find my applet class and throws a ClassNotFoundException; however, if online certification is disabled, everything works just fine.
The jar contains all the classes it needs and is fully signed.
The applet is run in Java Plug-in 10.0.0.147 using JRE version 1.6.0_20-b02 Java HotSpot(TM) Client VM.
John: Have you gotten any responses on this issue? I am experiencing the exact same issue with applets that I have signed using a valid code signing certificate issued to me by a valid CA (Certification Authority).
For my applets, the ClassNotFoundException occurs when one (or both) of the following Java security settings are enabled:
- Check Certificated for revocation using Certificate Revocation Lists (CRLs)
- Enable online certificate validation
My Java Console log output is almost exactly the same as yours; the online certificate validation appears to succeed, but the ClassNotFoundException occurs shortly after, when the class loader attempts to load the applet class.
Again, like you have experienced, everything works fine if both of the above Java security settings are disabled. I have tried various combinations of Java versions: compiling with 1.6.0_24 and signing with 1.6.0_29, compiling with 1.6.0_19 and signing with 1.6.0_17, compiling with 1.6.0_29 and signing with 1.6.0_29. All combinations yield the same ClassNotFoundException when the above security settings are enabled.
This is a real puzzler and I would appreciate any additional information you have on this issue. FYI: I have other resources working on this and we may contact Oracle for assistance. I will update this post if we gain any traction in resolving this.
Joined: Feb 22, 2008
I looked into Java browser plugin's source code (plugin.jar and deploy.jar) and found a couple of bugs that turn out to be the root cause of this issue. In my situation, with CRL/OCSP enabled, I was able to load the applet as long as "Mixed code security verification is disabled". When I changed the setting to "Mixed code security verification enabled -- show warning if needed", you would think you would get a warning at the most since everything worked fine when such setting was disabled. But instead, you would get a ClassNotFoundException.
Since 1.6.0_19, Java browser plugin has been enhanced to separate the codebase into two domains, trusted vs. sandboxed. There're two class loaders involved, the parent loader responsible for loading the trusted code and child loading the sandboxed jars.
One of the bugs I've found is that when your signed jar is "not" explicitly marked as "Trusted-Library: true" in its manifest file, it will get silently ignored by the parent class loader. There're two issues here: 1) if the parent class loader determines the signed jar cannot be treated as "trusted", it should at least allow the child class loader to load it as a sandboxed jar; 2) it should definitely write something to the Java console instead of simply ignoring the jar silently.
Because the signed jar is ignored silently by the parent class loader, it's neither loaded by the parent class loader nor the child class loader, the class cannot be found anywhere, hence ClassNotFoundException.
Per Java guide, when you have a signed jar that does "not" have any dependencies on untrusted components, you should mark it as "Trusted-Only" in the manifest. However, it doesn’t work for me. My workaround is to mark my jar as "Trusted-Library", even though my jar is self-sufficient and doesn't depend on any untrusted components. Once I added the said attribute in the manifest, the ClassNotFoundException went away. I hope it works for you as well.
Thank you so much for your reply. The behavior (and workaround) that you described is exactly the same behavior as I am experiencing. I have verified that the bug you reported to Oracle regarding "Trusted-Only", as it also occurs with my simple test applet, which contains only one (signed) class.
Thanks again for your help. You have been a tremendous help and I am truly grateful.