Java applications can be deployed via the Internet using Web Start. Web Start manages the installation and execution of applications. A self-contained Java application can be run without any further prerequisites besides its JAR and the Web Start deployment descriptor, the JNLP-file. However if you want advanced rights on the executing computer, you need to sign your application before you can deploy it. This article describes how you can sign your Web Start enabled application using a free, trusted certificate.

Java Web Start permissions

If you want to enable your application to access the file system or native libraries of the computer it runs on, you have to tell Web Start. This is done by adding the <security> element to the applications Java Network Launching Protocol (JNLP) file, e.g.:

<security>
  <all-permissions/>
</security>

Web Start applications without the <security> element are run in a sand box mode comparable to Java applets. Whenever a JNLP-file contains a request for additional permissions, all of the JARs used have to be signed. In order to sign Web Start applications, you need a X.509 certificate. You can either issue your own certificate or use one of a respected certificate authority (CA).

Self-signed certificates

During development of your application, a self-signed certificate may be sufficient. However if you want to make your application available to end users, this has a disadvantage. Only certificates from trusted certificate authorities, that is CAs whose root certificate is in Java's certificate store, are considered trustworthy. Self-signed certificates generate a rather deterring warning, when the user tries to install your application. Web Start still allows installation but a user might think twice about it, after reading the warning.

Self-signed certificates can be issued using OpenSSL for example. For a tutorial on how to do this see here. After you have got your self-signed certificate (usually in PEM or DER format), it can be imported into a Java keystore. Use the keytool --importcert command to do so. This step is necessary, so the jarsigner tool can later sign JARs with the certificate. In order to import your certificate into a Java keystore, you may need to convert it into a format the keytool can understand. A list of useful conversion commands can be found in the OpenSSL documentation.

Signing with your own certificates is acceptable during development or if you can add your own root certificate into the key store of the Java VMs running your application. If you want to address a wider audience, a trusted certificate is better to increase the end-user's confidence in your application.

Thawte Personal E-mail Certificates

Trusted certificates come from companies that usually sell certificates for a lot of money. For open source or freeware developers this is often not an option. Thanks to a great article by Richard Dallaway, I learned of free certificates from Thawte. In his article, he describes how to get a certificate from Thawte and use it to sign JARs. However Thawte seems to have changed a few things since back then and it does not work this way anymore. In fact it has become easier.

These personal email certificates are great because - as mentioned - they are free and Thawte's root certificate is in every recent Java-installation's root certificate store. Thus applications signed with such a certificate are considered to be signed with a certificate issued by a trusted authority. Other free certificate providers do not have this advantage and produce the same warning as self-signed certificates.

A personal email certificate from Thawte has some limitations compared to a fully paid certificate. For example you cannot change most of the information in the certificate; like the owner's name, which is set to something like Thawte Freemail Member. You have the option to join Thawte's Web of Trust. Being a member of the Web of Trust will allow you to enter more of your real information, should you want to do so. In its default state, such a certificate always contains your email address as means of identification.

To get a free Personal E-mail Certificate, you have to first sign up on their product page. Don't let the E-mail in the name fool you. It still works with Java's code signer. After you have signed up, login (make sure you are in the Personal E-mail Certificate section of the site). Choose certificates in the menu and click request a certificate and request a new X.509 format certificate. Pick the browser you want the certificate for. I have tested this procedure with Firefox 2. During the request the required private key will be generated. Once you have issued your request, go back to the certificates section of Thawte's site. On the view certificate status page you will find a list of requested certificates. Click your newly requested certificate. It may take a while before your certificate will be issued. If the status is pending check back later.

Click the fetch button on the bottom of the certificate's info page. This will install the certificate into your browsers certificate store. In order to use it with Java's signing tool, you have to export a copy. In Firefox this can be done in the certificate overview (in the menu: Edit > Preferences > Advanced > Encryption > View Certificates). Choose your certificate and click backup to save it in a PKCS12 certificate store. Remember the password as you will need it whenever you use the certificate to sign something. Internet Explorer can also export certificates via Window's internet settings.

You now have a certificate that will be recognised as issued by a trusted source by Java.

Signing your Jars

If you are using Apache Ant, the easiest way to integrate code signing in your build process is the <signjar> task. As the certificate is stored in a PKCS12 (Public Key Cryptography Standards) store and not a standard JKS (Java Key Store), the option storetype="pkcs12" has to be included. The certificate alias in the store has been set when you had exported it from your browser. To check the correct alias use Java's command line keytool to list certificates in a store:

keytool -list -keystore storeFile.p12 -storetype pkcs12


An example <signjar> Ant task could look like this:

<signjar keystore="${basedir}/certDir/storeFile.p12"
  alias="thawte consulting (pty) ltd. id von thawte freemail member"
  storetype="pkcs12"
  storepass="yourStorePassword">
  <path>
    <fileset dir="${dist.dir}" includes="**/*.jar" />
  </path>
</signjar>

This will sign all jar-files in your distribution directory. Individual jar-files can be signed this way:

<signjar jar="${basedir}/jarDir/yourApplication.jar"
  keystore="${basedir}/certDir/storeFile.p12"
  alias="thawte consulting (pty) ltd. id von thawte freemail member"
  storetype="pkcs12"
  storepass="yourStorePassword" />


Alternatively the jarsigner command line tool can also be used:

jarsigner -keystore storeFile.p12 -storetype pkcs12 yourApplication.jar "thawte consulting (pty) ltd. id von thawte freemail member"


Converting PKCS12 to JKS

Java uses its own keystore format, the Java Keystore (JKS). If you already have an existing keystore in this format, you might want to import your new certificate into it. For some reason keytool cannot import a PKCS12 certificate into a Java Keystore via the command line. Fortunately Kieran Shaw provides a solution that uses the Java java.security.KeyStore class in his blog. His solution imports a certificate from a PKCS12 keystore into an existing JKS. By modifying the provided KeystoreKeyImporter class you can also export from and import into any other keystore format that your security provider is capable of handling.

Conclusion

You should now be able to get a certificate which is recognised by Java to be issued by a trusted source. This certificate can be used to sign Java applications via the command line or with the help of Ant. If you already have an existing certificate store, you can also import this new certificate. End users can trust such a certificate more than they can trust a self-signed certificate. They can confirm the signers identity with the help of the email address contained in the certificate. They (or rather Web Start) can also verify that the certificate has indeed been issued by a respected CA.