Certificates & Older Java Versions

We’re having a lot of issues with users not using the latest Java versions and the new certificate signing requirements. Most of our problems are with Mac users running MacOS X 1.4. They’re not able to update to Java 1.6 because Apple doesn’t provide an updated Java install for that OS version.

These users are able to download & install Servoy, but once they quit and try to start Servoy again, they get the error:

“Unable to launch the application.”

and

“JAR resources in JNLP file are not signed by the same certificate.”

The text from the ‘Detail’ button on the error dialog are as follows:

JNLPException[category: Launch File Error : Exception: null : LaunchDesc:
<jnlp spec="1.0+" codebase="http://servoy.3rdiqc.com:8080/" href="http://servoy.3rdiqc.com:8080/servoy-client/plugins/servoy_jasperreports.jar.jnlp">
 <information>
   <title>Servoy Client Plugins</title>
   <vendor>Servoy and Others</vendor>
   <homepage href="null"/>
 </information>
 <security>
   <all-permissions/>
 </security>
 <resources>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports.jar" download="eager" main="false"/>
   <jar href="http://servoy.3rdiqc.com:8080/lib/commons-collections.jar" version="1274288999131" part="commons-collections" download="lazy" main="false"/>
   <package name="org.apache.commons.collections." part="commons-collections" recursive="true"/>
   <jar href="http://servoy.3rdiqc.com:8080/lib/commons-logging.jar" version="1274288999131" part="commons-logging" download="lazy" main="false"/>
   <package name="org.apache.commons.logging." part="commons-logging" recursive="true"/>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports/jasperreports-3.6.0.jar" download="eager" main="false"/>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports/commons-beanutils-1.8.0.jar" version="1274288999131" part="commons-beanutils" download="lazy" main="false"/>
   <package name="org.apache.commons.beanutils." part="commons-beanutils" recursive="true"/>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports/commons-digester-1.7.jar" version="1274288999131" part="commons-digester" download="lazy" main="false"/>
   <package name="org.apache.commons.digester." part="commons-digester" recursive="true"/>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports/iText-2.1.0.jar" version="1274288999131" part="itext" download="lazy" main="false"/>
   <package name="com.lowagie." part="itext" recursive="true"/>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports/jdt-compiler-3.1.1.jar" version="1274288999131" part="jdt-compiler" download="lazy" main="false"/>
   <package name="org.eclipse.jdt." part="jdt-compiler" recursive="true"/>
   <jar href="http://servoy.3rdiqc.com:8080/plugins/servoy_jasperreports/poi-3.2-FINAL-20081019.jar" version="1274288999131" part="poi" download="lazy" main="false"/>
   <package name="org.apache.poi." part="poi" recursive="true"/>
 </resources>
 <library-desc unique-id="null"/>
</jnlp> ]
	at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LaunchDownload.java:1041)
	at com.sun.javaws.LaunchDownload.checkSignedResources(LaunchDownload.java:943)
	at com.sun.javaws.Launcher.continueLaunch(Launcher.java:821)
	at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:522)
	at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
	at com.sun.javaws.Launcher.run(Launcher.java:165)
	at java.lang.Thread.run(Thread.java:613)

We’ve used Johan’s signtester.jar with the new ‘overwrite’ feature to self-sign all the jars on the server. This cured a number of issues with this error coming up randomly for ALL users. Now, we just have these other users with the problem. The only workaround so far is clearing the client cache and re-downloading the client app every time the user needs to start Servoy. Users are getting very frustrated! The only common link I’ve found so far is that these client machines are not running the latest Java version.

Is this possibly a problem with some jars being signed twice, once by the original author, and now by me using the signtester.jar utility? Is this a case of original certificate being read and my new certificate being ignored because of the presence of the original certificate?

Any help or insight would be greatly appreciated.

Most probably, it is a problem with double signing.
Under Mac OS X 1.4, I believe you are stuck with Java 1.5?

If so, the only way will be to
1/ unjar/unzip all the jars,
2/ get rid of the files in META-INF that ends with DSA SF RSA (keep the MANIFEST.MF and any .inf that could be there too!)
3/ jar or zip it back
4/ resign them again…

If you have ant installed, it could all be done in a build.xml file, and some contrib ant tasks.

Thanks Patrick! I will give this a try. Scott Butler outlined the steps in another forum thread to remove the signing files, etc. so I should be able tackle this.

Under Mac OS X 1.4, I believe you are stuck with Java 1.5?

Yes, we are stuck with Java 1.5 on Mac OS X 1.4.x so hopefully this will get us through until I can convince them to upgrade.

yes old java versions i think below 6u14 have a problem with double signing, i think they fixed that around that time.
But java 5 never got that fix so its only 6u14 and greater that works with double signing

Thanks Johan!

Double signing does appear to be the problem. I removed the signing from a component of the Jasper Reports plugin, re-signed it and it is no longer failing on that particular set of jars. Now it is giving errors on other jars loading after the Jasper plugin.
Is there a way to quickly remove all the signing from all the jars so I can ‘single-sign’ everything to get these users up and running?

youo have to create a script/ant file that does that for you

the sign_tester tool only adds/overwrites the signing…
maybe i will change it one time to also remove it first, but the sign tester code is open source, java file is included, so scott or patrick (2x) could pick it up and add some code to first unzip and remove everything

End of the double-signing problem:
[attachment=0]unsigner.jar[/attachment]

This quick and dirty (but pefectly working) little tool will unsign recursively all the jars located under the application_server (mainly those in /beans / lafs/ /lib and /plugins)
You put it in your /Servoy/application_server/ folder and call it like from the command like this:

java -jar unsigner.jar

Once it has done its stuff, you will still need to use Johan’s signtester tool to properly resign everything.

unsigner.jar (5.32 KB)

Wow Patrick…thank you!

I will try this out this evening and let you know how it goes.

THANKS Patrick!! :D
Really cool, Is it much work to integrate this into the signtester.jar?

Harjo:
THANKS Patrick!! :D
Really cool, Is it much work to integrate this into the signtester.jar?

:lol: Always pushing the limit, eh, Harjo?
I’ll see what I can do.

The unsigner.jar worked beautifully along with re-signing all the jars using Johan’s signtester.jar. My users using Java 1.5 are up and running with no errors.

Many, many thanks Patrick, for removing the headache of manually unsigning all the jars for us non-Java-savy guys!

Glad it worked!

Since some people(!) ask for an all-in-one tool, I have modified Johan’s signtester.jar: when you use it with the ‘overwrite’ parameter, it will first unsign the jars… (Sources are included)

You can ownload it from the Servoy-Stuff site.

Brilliant, just what I needed Patrick, Thanks!

ptalbot:
Glad it worked!

Since some people(!) ask for an all-in-one tool, I have modified Johan’s signtester.jar: when you use it with the ‘overwrite’ parameter, it will first unsign the jars… (Sources are included)

You can ownload it from the Servoy-Stuff site.

Indeed, always pushing the limit! :-) I find it important that somebody without ANY Java knowledge is able to do this…

Thx Patrick! ;-)

ptalbot:
Glad it worked!
Since some people(!) ask for an all-in-one tool, I have modified Johan’s signtester.jar: when you use it with the ‘overwrite’ parameter, it will first unsign the jars… (Sources are included)
You can ownload it from the Servoy-Stuff site.

Thank you so much Johan and Patrick! Excellent Servoy stuff indeed!

Harjo:
I find it important that somebody without ANY Java knowledge is able to do this…

Exactly! Especially for guys like me, is it from great importance that this action can be executed by anyone using Servoy. :wink:

Therefore, I suggest that sign/unsign actions would be great to implement in Servoy’s Eclipse enviroment itself. A ‘Certificate’ option in the File menu would be something valuable 8) .
Feature request is posted here:
http://www.servoy.com/forum/viewtopic.php?f=13&t=14207&p=74863#p74863

b- overwrite all jars (remove all existing certs and sign them by selected certificate)

I have mentioned it before and I do so again.
It is absolutely not so that this can always be done without causing issues.
So, without knowing what you do, possible errors can cause confusion for both the Servoy developer and possibly also the Component developer.
Everybody removing signatures from jars should realize this.

Apart from that I am not sure if you/we are even allowed to remove a signature and replace it with our own.

IT2Be:

b- overwrite all jars (remove all existing certs and sign them by selected certificate)

I have mentioned it before and I do so again.
It is absolutely not so that this can always be done without causing issues.
So, without knowing what you do, possible errors can cause confusion for both the Servoy developer and possibly also the Component developer.
Everybody removing signatures from jars should realize this.

Apart from that I am not sure if you/we are even allowed to remove a signature and replace it with our own.

Right. So a console window displaying the log should not be exorbitant, yes? :wink:

IT2Be:

b- overwrite all jars (remove all existing certs and sign them by selected certificate)

I have mentioned it before and I do so again.
It is absolutely not so that this can always be done without causing issues.
So, without knowing what you do, possible errors can cause confusion for both the Servoy developer and possibly also the Component developer.
Everybody removing signatures from jars should realize this.

Apart from that I am not sure if you/we are even allowed to remove a signature and replace it with our own.

Marcel,
despite the fact if, or if it is not allowed, are there issues, with your plugins & beans that you know of?
So far it works just fine…

I do not understand, what signing has to do, with breaking code or possible errors… (I understand that double signing can lead into trouble)
But hey, that’s me… I’m not a java-guru ;-)

Aspose stuff does not like that signatures are removed.

Also, I don’t exclude that I am going to use signatures for the update mechanism to make it a (more) secure process in the future.

Can you define: “Does not like?”

is that a legal issue? or a technical issue?
so far, it is working here…

it sounds more, that you don’t like it! :-) right?