Securing Java Web Start for desktops

In a previous post I explained how to make sure only trusted Java applets can run outside of the Java sandbox. Unfortunately this is only half of the battle with Java on desktops. Besides Java applets that run inside a web browser, installing the Java Runtime Environment also enables the use of Java Web Start (javaws).  With this technology a complete Java application is downloaded and stored locally and then started outside of the browser process. This is just as dangerous as downloading and running an executable. Java Web Start applications only run inside a sandbox when they are not signed. Signed apps however have access to all the files and OS APIs other user applications do. It is possible to lock signed javaws inside a sandbox using the javaws.policy file, but in this post I’ll focus on preventing unknown javaws apps to start at all.

Running a signed javaws application for the first time will cause a security popup to appear:

The warning is not very informative. After clicking on “More Information…” the risks become a little more clear:

Obviously most users will just click “Run” without hesitation. Fortunately, it is possible to move the decision to run a javaws app to a central place. This is documented in the Java Deployment Guide in the Deployment Configuration File and Properties section. Place a deployment.config file in the JRE lib directory with these contents:


The path can point to the same lib directory, or a central location on a file share. The contents of this file should be:\\\\myserver\\myshare\\java\\trusted.certs

The property controls the “Allow user to grant permissions to signed content” checkbox in the Java Control Panel. The property controls the “Allow user to grant permissions to content from an untrusted authority” checkbox. Disabling them is recommended by CERT. Adding another property with “locked” appended to its name prevents users to change it back:

This effectively disables the user to start any signed javaws application. Trying to do so will now trigger an error that looks like this:

Clicking the details button explains the security configuration does not allow the user to grant permission to new certificates:

So far, so good. Of course there might be some javaws applications that you are running within your organization that should be allowed. This is where the property comes in. The default is a trusted.certs file inside the JRE lib directory, but placing this on a central share might make updating it a lot easier. To create this file, use the keytool binary that comes with JRE. Keytool is used to manage Java keystores. To create an empty keystore use:

keytool -genkey -alias foo -keystore trusted.certs
keytool -delete -alias foo -keystore trusted.certs

When asked for a password for the new keystore, use “changeit”. This is the password for the cacerts file that comes with JRE. Since none of the information inside the trusted.certs file is secret there is no need to set a strong password.

Now download the JAR file of the javaws app that is trusted. Unzip it and look inside the META-INF directory. There will be a *.RSA file. This holds the signer certificate (and its CA certificates) in pkcs7 format. To extract the certificates use:

openssl pkcs7 -print_certs -in PATCHMAN.RSA -inform DER -out cert.txt

This will export the signer and CA certificates in PEM format. Now edit cert.txt so that it only contains the signer certificate (remove the CA certificates). Convert it to DER format:

openssl x509 -in cert.txt -out cert.der -outform DER

This format can be read by keytool to add it to the keystore:

keytool -importcert -alias patchmanager -file cert.der -keystore trusted.certs

Start the Java Control Panel, and click the Certificates button on the Security tab. Select Trusted Certificates and the System tab. The imported certificate should now be shown:

This will make sure only trusted Java Web Start applications can be run outside of the Java sandbox.

Leave a Comment