Personal tools
The new "magic" world of Java Applet signing: what changes

Elevator to Hell??

Apr 02, 2014

The new "magic" world of Java Applet signing: what changes

Starting with Java SE 7 Update 21 in April 2013 Java Applets are encouraged to be signed with a trusted certificate. And something more starting with 7u25...

Introduction

This is a true story!

It's about my adventure inside applets, Java security, signing and so on.

Everything starts with this article, directly from Oracle:

"Java SE 7u21 will introduce changes to Java browser plug-in behavior, encouraging application authors and vendors to sign code with a certificate from a trusted Certificate Authority. Developers are strongly encouraged to sign code now in preparation for this release and future releases. Details of the new security prompts can be found in this java.com article."

And still...

"These steps will significantly lower risks to desktop users. We are also removing the “low” security settings in the Java Control Panel (e.g., low/custom), to prevent users to from inadvertently opting-out entirely from the security remediation we are building into Java. Users will be better protected by maintaining up-to-date versions of the JRE on their systems, combined with requiring code that is signed by a Trusted Certificate Authority (rather than self-signed or unsigned code)."

Here you can find a very good explanation of the difference between signed and unsigned applet.

So, I decided to buy my first certificate from a trusted Certificate Authority.

New policies introduced by Oracle are quite strict. Most of the work is to modify manifest attributes: for this purpose i use a batch file, something like this:

"C:\Program Files (x86)\Java\jdk1.7.0_51\bin\jar.exe" cvfm myJar.jar add.mf *.class

where add.mf is:

Manifest-Version: 1.0
Created-By: 1.6.0_16 (Sun Microsystems Inc.)
Permissions: all-permissions
Caller-Allowable-Codebase: *
Trusted-Library: true
Codebase: *
Name: My organization
Application-Name: MyApplicationName
Main-Class: MyApplicationName

Command for signing jar files could be easily found over the Web, this is an example:

 jarsigner -verbose -keystore codesignstore -storepass  -keypass  myapp.jar codesigncert

An advice

If you use esternal jars in addition to your, absolutely don't forget to include

Trusted-Library: true

attribute for all jars, and sign each one as explained above.

In fact, I've experienced a very frustrating situation, in which an applet that contains external jars wasn't correctly managed.

In this case, the error that you obtain is something like that:

java.lang.RuntimeException: java.lang.NoClassDefFoundError: XXXXXX

The reason is that if you don't tell to JRE that external libraries are trusted, it ignore them, causing the problem.

You can follow the whole discussion about that on StackOverflow.

Filed under: , ,
comments powered by Disqus