[jitsi-users] java signer for jitsi java web start

Vieri · February 17, 2015, 1:28pm

Hi,

I have absolutely no experience with java signatures.

I'm trying to self-sign Jitsi jars and run the Jitsi java web start version.

Currently I'm running:

# keytool -genkeypair -alias jitsisigner -keyalg RSA -keysize 2048 -keypass password -keystore JITSIkeystore.jks -storepass password -validity 7300
# keytool -exportcert -alias jitsisigner -file jitsisigner.cer -keystore JITSIkeystore.jks -storepass password
# keytool -importcert -trustcacerts -alias jitsisigner -file jitsisigner.cer -keystore JITSIkeystore.jks -keypass password -storepass password

WebStartBuild.properties contains:

java.jdk.dir = C:\\Program Files\\Java\\jdk1.8.0_25
keystore.alias = jitsisigner
keystore.file = C:\\Users\\vieri\\Documents\\jitsi\\java_keystore\\JITSIkeystore.jks
keystore.password = password
webstart.codebase.url = http://server.org/IT/IM/jws

Jitsi jws builds fine with

# ant -buildfile WebStartBuild.xml all-prod

but I get messages such as:

\[apply\] jar verified\.
\[apply\]
\[apply\] Warning:
\[apply\] This jar contains entries whose certificate chain is not validated\.
\[apply\] This jar contains signatures that does not include a timestamp\. Without a timestamp, users may not be able to validate this jar after the signer certificate&#39;s expiration date \(2035\-02\-11\) or after any future revocation date\.
\[apply\]
\[apply\] Re\-run with the \-verbose and \-certs options for more details\.

I guess it's OK.

I then went to the Windows control panel -> Java and I imported jitsisigner.cer as "trusted certificate" type.

However, when I try to launch http://server.org/IT/IM/jws/client.jnlp, Java Web Start warns me that it can't be run because my security settings are blocking the execution of self-signed applications.

Is there really no way to trust a self-signed app in Java 8 (without having to add site exceptions)?

I then also tried to sign the certificate with a local CA signing authority. I used openssl on another server to create a custom Ca and sign jitsisigner.cer.
I ran
# ant -buildfile WebStartBuild.xml all-prod
again and put the openssl-created CA cert within Java's "trusted root certs" in Windows control panel.

However, I'm still getting the same result when launching Jitsi via JWS.

Any ideas?

Thanks,

Vieri

···

Ingo_Bauersachs · February 17, 2015, 2:22pm

However, when I try to launch http://server.org/IT/IM/jws/client.jnlp, Java
Web Start warns me that it can't be run because my security settings are
blocking the execution of self-signed applications.

Is there really no way to trust a self-signed app in Java 8 (without having
to add site exceptions)?

AFAIK no.

I then also tried to sign the certificate with a local CA signing
authority. I used openssl on another server to create a custom Ca and
sign jitsisigner.cer. I ran # ant -buildfile WebStartBuild.xml all-prod
again and put the openssl-created CA cert within Java's "trusted root
certs" in Windows control panel.

There's no "trusted root certs" entry, I guess you meant Signer CA. AFAIK you need to import that into the system keystore, the user store is likely not sufficient.

However, I'm still getting the same result when launching Jitsi via JWS.

Any ideas?

When I created that stuff the most recent Java was 6u24. I think Daniel had some success with Java 7, not sure about 8. Look in the archives (around August '14).

Thanks,
Vieri

Ingo

Vieri · February 18, 2015, 12:58pm

From: Ingo Bauersachs <ingo@jitsi.org>
To: 'Vieri' <rentorbuy@yahoo.com>; 'Jitsi Users' <users@jitsi.org>
Sent: Tuesday, February 17, 2015 3:22 PM
Subject: RE: [jitsi-users] java signer for jitsi java web start

However, when I try to launch http://server.org/IT/IM/jws/client.jnlp, Java
Web Start warns me that it can't be run because my security settings are
blocking the execution of self-signed applications.

Is there really no way to trust a self-signed app in Java 8 (without having
to add site exceptions)?

AFAIK no.

I then also tried to sign the certificate with a local CA signing
authority. I used openssl on another server to create a custom Ca and
sign jitsisigner.cer. I ran # ant -buildfile WebStartBuild.xml all-prod
again and put the openssl-created CA cert within Java's "trusted root
certs" in Windows control panel.

There's no "trusted root certs" entry, I guess you meant Signer CA. AFAIK you need to import that into the system keystore, the user store is likely not sufficient.

I meant signer CA and the first tab too ("trusted certificates": http://docs.oracle.com/cd/E23943_01/bi.1111/b40107/img/ssl9a.gif).

In my example I placed my local ssl-generated CA cert in "signer CA" and jitsisigner.cer (the signed certificate) in "trusted certificates" both in "user" and "system".
JWS 8 keeps blocking the app because it considers it as self-signed.

So I tried another trick and used site exceptions instead of certificates. It's not what I prefer but I can still deploy it locally somehow.

I specified:
deployment.user.security.exception.sites=C\:\\Windows\\Sun\\Java\\Deployment\\exception.sites
in
C:\Windows\Sun\Java\Deployment\deployment.properties
and it seems to work.

It's still a pain because I need to deploy the content of C\:\\Windows\\Sun\\Java\\Deployment (or %userprofile%\AppData\LocalLow\Sun\Java\Deployment\security on a per-user basis) but the way certificates are handled is way beyond me.

In any case,I need to add 2 sites in the exception list: my server's URL and http://felix.extensions:9/. Ugly but it works.

However, I'm still getting the same result when launching Jitsi via JWS.

Any ideas?

When I created that stuff the most recent Java was 6u24. I think Daniel had some success with Java 7, not sure about 8. Look in the archives (around August '14).

I don't want to sound corny but I think you did a great job adding support for java web start. It really is handy because it doesn't require worrying about making an installer and making sure updates are deployed correctly. So please don't drop jws support...

By the way, the java console shows the following messages when Jitsi JWS starts up. Any ideas?

Java Web Start 11.25.2.18
Using JRE 1.8.0_25-b18 Java HotSpot(TM) Client VM

···

----------------------------------------------------
Missing Permissions manifest attribute in main jar: https://server.org/IT/IM/jws/sc-bundles/sc-launcher.jar.pack.gz
Can't load log handler "net.java.sip.communicator.util.FileHandler"
java.lang.ClassNotFoundException: net.java.sip.communicator.util.FileHandler
java.lang.ClassNotFoundException: net.java.sip.communicator.util.FileHandler
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.util.logging.LogManager$5.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source)
at java.util.logging.LogManager.access$1500(Unknown Source)
at java.util.logging.LogManager$RootLogger.accessCheckedHandlers(Unknown Source)
at java.util.logging.Logger.getHandlers(Unknown Source)
at net.java.sip.communicator.launcher.SIPCommunicatorJWS.main(SIPCommunicatorJWS.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Thanks,

Vieri

Ingo_Bauersachs · February 18, 2015, 2:11pm

I meant signer CA and the first tab too ("trusted certificates":
http://docs.oracle.com/cd/E23943_01/bi.1111/b40107/img/ssl9a.gif).

In my example I placed my local ssl-generated CA cert in "signer CA" and
jitsisigner.cer (the signed certificate) in "trusted certificates" both in
"user" and "system".
JWS 8 keeps blocking the app because it considers it as self-signed.

Your own certificate doesn't need to be in any of these stores, only the CA. Except for the exception site list, I never trusted the control panel and modified the truststore file of the JRE/JDK manually when necessary the tool Keystore Explorer comes in handy for this.

So I tried another trick and used site exceptions instead of certificates.
It's not what I prefer but I can still deploy it locally somehow.

I specified:
deployment.user.security.exception.sites=C\:\\Windows\\Sun\\Java\\Deploym
ent\ \exception.sites in
C:\Windows\Sun\Java\Deployment\deployment.properties and it seems to
work.

It's still a pain because I need to deploy the content of
C\:\\Windows\\Sun\\Java\\Deployment (or
%userprofile%\AppData\LocalLow\Sun\Java\Deployment\security on a per-user
basis) but the way certificates are handled is way beyond me.

In any case,I need to add 2 sites in the exception list: my server's URL and
http://felix.extensions:9/. Ugly but it works.

That Felix URL first caused problems with Java 6u24 because of new security checks. Seems Felix still handles this in a weird way. We don't need those extensions, so you could probably remove the offending code from a custom Felix build. Search for Felix 6u24 and Ingo and you'll find my bug report from back then.

However, I'm still getting the same result when launching Jitsi via JWS.

Any ideas?

When I created that stuff the most recent Java was 6u24. I think Daniel had
some success with Java 7, not sure about 8. Look in the archives (around
August '14).

I don't want to sound corny but I think you did a great job adding support
for java web start. It really is handy because it doesn't require worrying
about making an installer and making sure updates are deployed correctly. So
please don't drop jws support...

Be _very_ wary of what you're doing. The updates were never handled as well as they should have been and it was often necessary to clean the Java caches manually. And it might break at any time when Oracle adds new security checks. There's NO support AT ALL, this is merely a code dump for anyone interested.

By the way, the java console shows the following messages when Jitsi JWS
starts up. Any ideas?

They've been there from the start and I never cared to fix it.

Thanks,
Vieri

Ingo