Since the latest Java update, two of my applets are displaying a warning pop-up to our users even though both of the jar
files we are using are signed. I have verified they are signed using the jarsigner -verify MyJarFile.jar
command. Below is the popup message we are seeing...
My applet invokes a C++ dll through JNI. The C++ dll invokes a C# netmodule.
Does anyone know what I can do to get this popup to go away? It says the application contains both signed and unsigned code, but I am signing every java file (there is only 1) in my jar file. Is there a higher level of signing I need to do?
Edit: This is occurring as of the latest Java update. See the quote below taken from this page.
Authors and vendors of applications deployed using either Java applets or Java Web Start technology – applications distributed to end users at runtime via the web browser or network - should sign their code using a trusted certificate for the best user experience. Specifically, all Java code executed within the client’s browser will prompt the user. The type of dialog messages presented depends upon risk factors like, code signed or unsigned, code requesting elevate privileges, JRE is above or below the security baseline, etc. Low risk scenarios present a very minimal dialog and include a checkbox to not display similar dialogs by the same vendor in the future. Higher risk scenarios, such as running unsigned jars, will require more user interaction given the increased risk.
I figured out the answer. I did not have a manifest file in my eclipse project, so I created a file called manifest.mf
and put the following code into it.
Manifest-Version: 1.0
Trusted-Library: true
When building the jar file in eclipse, on the 3rd page, it asks you for a manifest file. I believe it defaults this option to 'Create a manifest file for me', but this manifest file only contains the first line above. Choose the option that says 'Use existing manifest from workspace', and choose your manifest.mf file you just created. Then sign your jar as you normally would.
It was the Trusted-Library
attribute that fixed the problem. Check out this page for more information on this attribute and other Privileged code jar files.