How to manage certificate renewal with Java Webstart application -

I am developing Java desktop applications using Java JavaTone technology. I sign my app using a valid certificate and deploy it using JnlpDownloadServlet. I create all this infrastructure with the Maven-WebStart-Plugin.

But when my certificate expires and I have to leave my application and have to recruit again, then I am having trouble downloading my application completely to webstones. is.

As far as I know, what I can collect from the internet (WebStart official documentation is awful), version and updates based on file server time (last-modified HTTP header) by default Webstart The library looks

If this is true, then the Webstart client should fully download a new version of my application.

But instead webstart is downloading the library to the new version of JNLP file as the Maven Webstart plugin generates them.

The application fails to start, complains about various signed jars, and when I see in the Tomcat access-log, only the checked and downloaded files in the server are JNLP files, real new versions With a jar, and a second jar (I believe that it gets downloaded, is signed-checked, and fails the client) All requests are GET, no staple

I < Strong> no JNA Using version-based protocols in Libya (the active by jnlp.versionEnabled property), but the Webstart client works on it as it is running.

My JNLP update options

  & lt; Update check = "always" policy = "always" />  

I see that the only solution is updating the version number of all Jars, adds some to the version number, but JNLP "redirection" is done automatically by the webstart-plugin And I would have liked a simple and more strong approach.

Edit: It seems that the version-based download protocol is being started because in the Jar element file in JNLP version < / Code> attribute is automatically added by the WebStart plugin. This is a major functionality while managing dependency versions but it is a pain if you just want to update the signature. I found that 1.5 supports validation of Java expired signatures if they are timestamps:

/ P>

This is also well explained:

Fortunately, maven-webstart-plugin supports version 1.0-Beta 5 since:

& lt; Sign & gt; & Lt; Storetype & gt; PKCS12 & lt; / Storetype & gt; ... & lt; TsaLocation & gt; Https: //timestamp.geotrust.com/tsa< / Tsa location & gt; & Lt; / Sign & gt;

Now, the Webstart client will accept the application unless the timestamp is valid, even if my signature certificate is expired. (I have tested with a personal ca certificate and expired sign cert)

I will use the WebStart version-based protocol for actual changes in my libraries, which will speed up independent jar downloads. , And everything is fine, and the world is beautiful.