How to manage certificate renewal with Java Webstart application

Question

I'm developing a Java desktop application using Java Webstart technology. I sign my app using a valid certificate and deploy it using the JnlpDownloadServlet. I prepare all this infrastructure with the maven-webstart-plugin.

But when my certificate expires and I have to resign and redeploy my application I'm having problems to make webstart redownload completely my application.

As far as I know, based in what I could gather from Internet (Webstart official documentation is awful), by default webstart checks the version and updates libraries based on the file server time (Last-Modified HTTP header)

If this is true, the webstart client should download entirely the new version of my application.

But instead webstart is only downloading the libraries with newer version number in the JNLP file as the maven webstart plugin generates them.

The application fails to start, complaining about different signed JARs, and when I look in tomcat access-logs, the only checked and donwloaded files in the server are the JNLP file, the JARs with real newer versions, and another one JAR (I assume this is the one that gets downloaded, signature-checked, and makes the client fail) All requests are GETs, no HEADs

I'm NOT using the version-based protocol in the JNLP (activated by the jnlp.versionEnabled property) but the webstart client behaves as if it were on.

My JNLP update options are

<update check="always" policy="always" />

The only solution I see is updating the version number of all JARs, appending something to the version number, but the JNLP "renderization" is done automatically by the webstart-plugin and I would prefer a simpler and more robust approach.

Ideas?

EDIT: Looks like the version-based download protocol is being triggered because the jar elements in the JNLP file have the version attribute. This is automatically added by the webstart plugin. This is a great functionality when managing dependencies versions. But it's a pain if you just want to update the signatures.

I use webstart regularly and update jar files without renaming them. Webstart always notices the change and downloads the modified jar files. Try a simple test case. Re-sign or modify one of the jar files and upload it to your server and see if your local webstart notices the change and downloads the re-signed jar. — Saeid Nourian, Mar 17 '15 at 01:47

score 2 · Accepted Answer · edited May 23 '17 at 12:25

I found that since 1.5 Java supports validating expired signatures if they are timestamped:

http://docs.oracle.com/javase/tutorial/deployment/jar/signing.html

It is also nicely explained here: https://stackoverflow.com/a/24178906/134898

Luckily, maven-webstart-plugin supports this since version 1.0-beta5:

    <sign>
        <storetype>pkcs12</storetype>
        ...
        <tsaLocation>https://timestamp.geotrust.com/tsa</tsaLocation>
    </sign>

Now, webstart clients will accept the application as long as the timestamp is valid, even if my signing certificate expires. (I tested with a private CA certificate and expired signing cert)

I will keep using the webstart version-based protocol for real changes in my libraries, which will trigger independent JAR downloads, and everything is fine, and world is beautiful.

I can not find documentation for this parameter anywhere! Where did you find this information? Here: https://github.com/mojohaus/webstart/blob/master/webstart-maven-plugin/src/main/java/org/codehaus/mojo/webstart/sign/SignConfig.java ? — Adriaan Koster, Feb 27 '17 at 15:57

How to manage certificate renewal with Java Webstart application

1 Answers1