Disable sun signed jars verification

Question

I'm getting a lot of troubles trying to publish a .war package containing a Web Start application with commons-configuration-1.3.jar in the build path (com.sun.deploy.net.JARSigningException).

I have already tried to clean the javaws cache, reinstall the application, even reinstalling java (1.6.0_24).

This is a stretch of my NetBeans IDE 6.8 (Build 200912041610) output while creating a JNLP application:

Warning: 
The signer certificate will expire within six months.
Signing JAR: D:\Java\workspace\OTP\DeskOTP\atual\build\cluster\modules\ext\commons-configuration-1.3.jar to D:\Java\workspace\OTP\DeskOTP\atual\build\jnlp\app\br-com-petrobras-ep-gedig-gedigdesktoplibrary\ext-commons-configuration-1.3.jar as jnlp

However, when trying to run I got a JARSigningException for this jar.

So, I decide to solve this disabling this verification. I believe I can decide and tell jvm not to verify my jars (my responsibility).

Is there anyway to tell jvm or javaws to NEVER verify non signed jars?

Hanuman

"Is there anyway to tell jvm or javaws to NEVER verify non signed jars?" What would be the point? Even if you can achieve it on the development machine, it is not something you should be doing on client machines. – Petty

There's a bug in some recent versions of Java where they fail to verify the certificates properly, so it would be useful to be able to bypass this for specific .jnlp files until the bug is resolved. – Rundlet

Answer 1

As a first reaction, I'd say to try java -noverify -jar your_file.jar.

However, this will only work for local jarfiles. It will not work from a web source, which is what is sounds like you're trying to do. Is that right?

Peluso

Yeah, I need something to ignore verifies on web. Will keep trying here. Any success will be post here. Thanks. – Hanuman

I did not even get this to work for local files. I don't think the noverify option controls any of the security verifications. – Iow

Answer 2

You can always download the jar from the web, manually remove the signature sections on the manifest and it should work. If the jar happens to be dynamically downloaded from the web as @Riking mentioned in the other reply, then you might be able to get around by proxying the URL to a different server.

Now, if you have access to the deployment build status and is having trouble with expired signatures on artifacts, one alternative might be to re-sign the jar using your company's (Petrobras?) signing certificates. That will allow you to work around expired issues, provided that the build knows it's supposed to pull your version of the artifact instead of the original commons-configuration.

Bish