I’m having issues getting our smart client to launch using our code signing certificate.
When I launch the smart client, I get the initial warning that “Part of the application is missing a digital signature.” The more detailed messages say “…Although the application has a digital signature, the application’s associated file (JNLP) does not have one…The digital signature was generated with a trusted certificate.”
Following everything I’ve found in the forums here:
– I removed swingbeans.jar from the application server
– I have unsigned and resigned all jars under the following directories and their subdirectories: lafs, beans, plugins, and lib. The jars all verify using both signtester.jar and jarsigner
– No jars are double-signed under these directories
– No jars are unsigned under these directories
– All jars have the same certificate
– I flushed my java caches using the Java control panel tool
– I’m running the latest JDK/JRE for Windows XP on the client
Any thoughts on what I might have missed? I’m sure I haven’t listed everything I’ve tried. We are currently running Servoy 5.1.4.
you get just that warning right? the rest works?
The client just starts if you accept it?
the problem is that webstart wants also the jnlp file to be signed, but this is not possible because we generate the jnlp file on the fly
The reason why webstart wants the jnlp file to be signed is because of this vm property that we set:
-XX:SoftRefLRUPolicyMSPerMB=3600000
i think if you remove that one you will not get that warning error… Problem is that for performance we do need that setting…
Yes, it all works if I click through and accept the application. Thanks for this, it makes what’s going on clearer, though it will be an educational hurdle with customers. So basically, I’ve gotten this as far as I can currently go technically?
Is there any possibility with future Servoy releases that the signing of the JNLP could be configured with my keys to occur as part of the generation process? I’m still learning Servoy, so this may be a silly question.
This will be really tricky because we need to generate a jnlp file as a file
Include that in the j2db.jar (the main jar) and then sign that one again.
I guess you could do that your self now if you resign everything…
here is a snippet of the jnlp spec how to do that:
5.4.1 SIGNING OF JNLP FILES
A JNLP file can optionally be signed. A JNLP Client must check if a signed version of the JNLP file
exists, and if so, verify that it matches the JNLP file that is used to launch the application. If it does not
match, then the launch must be aborted. If no signed JNLP file exists, then the JNLP file is not signed,
and no check needs to be performed.
A JNLP file is signed by including a copy of it in the signed main JAR file. The copy must match the
JNLP file used to launch the application. The signed copy must be named: JNLPINF/
APPLICATION.JNLP. The APPLICATION.JNLP filename should be generated in upper case,
but should be recognized in any case.
The signed JNLP file must be compared byte-wise against the JNLP file used to launch the application. If
the two byte streams are identical, then the verification succeeds, otherwise it fails.
As described above, a JNLP file is not required to be signed in order for an application to be signed. This
is similar to the behavior of Applets, where the Applet tags in the HTML pages are not signed, even when
granting unrestricted access to the Applet.
Big problem here is that if you would get the standard jnlp file:
and save that file to disk. and include that as the APPLICATION.JNLP file in the JNLPINF/ dir in the j2db.jar (besides the meta-inf i guess)
then you don’t (or shouldnt) get the warning if you really start it by that url
But if you are using other entry points like profiles or a deeplink directly to a solution, or change anything on the admin pages (like system properties or vm properties)
that affect the jnlp file then it doesn’t work anymore…
So for us to make this work we have to somehow generate the j2db.jar for every request and then somehow know what jnlp is used to get that jar file (so if possible we should have some kind of session at the server)
then include that jnlp file quickly in the jar for that specific client, sign the jar and serve the jar
as you can see thats quite a bit of work… and maybe it is not even possible to do… (we really have to link the right jnlp file the client uses to the j2db.jar that it downloads which are 2 totally separated request to the server)
I do have some other idea that i have to work out to by pass all of this. I only don’t know if this will really work need to work on a prototype first.
We now sign our Servoy installation with an official digital certificate.
It works fine, but we get a warning that the solutions jnlp file is not signed.
I found this post and wunder if this message can be avoided ??
see my post one post above this…
i explained exactly what to do there.
Or you could delete “-XX:SoftRefLRUPolicyMSPerMB=3600000” that part of the vm args but that could hurt your performance a bit.
(if that is the only thing in the vm args then place a space into it)
We are working almost 6 months now, on our production system, without the vm arg: -XX:SoftRefLRUPolicyMSPerMB=3600000
vm args (in servoy-admin) set with space…
I removed the -XX:SoftRefLRUPolicyMSPerMB=3600000, it is correctly removed from the jnlp but we still get the warnings…
Today we started working on java 7 update 51 and there is no improvement…
Removing the version attribute from the jnlp makes the yellow warning disappear but then you lose the option ‘Always run this application…’
There are no console warnings, everything signes with the last signtester with our own certificate
Adding our certificate to trusted certifacates in ‘Internet Options’ in Windows control panel made all the warnings disappear, even with the -XX:SoftRefLRUPolicyMSPerMB=3600000 setting still active.
We have to do it for all customer computers now but it’s better than nothing…
(java 7 update 51)
robrecht:
Adding our certificate to trusted certifacates in ‘Internet Options’ in Windows control panel made all the warnings disappear, even with the -XX:SoftRefLRUPolicyMSPerMB=3600000 setting still active.
We have to do it for all customer computers now but it’s better than nothing…
(java 7 update 51)
Hi all, i’m trying to solve the problem too…
I’m using Servoy Application Server release 5.2.17, i’ve signed all my Application Server folder using CodeSigner Tool and a 3rd Part certificate.
All seems good because all the jars file are signed and the manifest looks correct too. But with java 7 u 51 appears the malefic warning message again.
So i tried to install manually the certificate under the folder “trusted Publishers” and all works fine… but this solution its not good for me… i cant install my certificate in every computer that my application works.
Someone else have a good idea to help me? Or we are forced to wait a new java realese hoping that solves something?
if you need to do that, then somehow your root certificate that signed your certificate is not in the trusted roots of java.
So you should make sure you use one that is a valid java certificate. (i guess many already here on the forum have providers that work just fine)
jcompagner:
if you need to do that, then somehow your root certificate that signed your certificate is not in the trusted roots of java.
So you should make sure you use one that is a valid java certificate. (i guess many already here on the forum have providers that work just fine)
Hi Johan,
Thanks to your reply.
To create my .jks key i used 3 certificate, 1 root, 1 intermediate, 1 specific with my company informations. So you’re telling me to use another root certificate because probably mine certificate it’s not the right one?
My root certificate is certainly valid because its expire data is jan 2028… Where i can look if my root certificate is valid for java?
Harjo:
The yellow balloon is a bug in Java. That will probably fixed in next java version. Which malefic message do you get?
My malefic message i think it’s just the yellow balloon (look the image)
[attachment=0]yello baloon.png[/attachment]
jcompagner:
you have to see them in the root ca list that you can lookup in de java preferences
So if i find my certificate under the certificate-type “secure certificate” into the java preference my root’s certificate is correct, otherwise it isn’t… right?
(i’m not sure but we are talking about the machine that i use to certificate my application, do you confirm?)
jcompagner:
so it does start normally you only get that screen?
thats the java bug
Yes, now the situation is this.
I can solve this yellow balloon only by installing my personal certificate in each computer where my application run, but because this is not possible I’ill wait the java update.
