Question

I have a small javafx2 application that is used in the office. Some guys run it from Firefox, some run it as a desktop app. Webstart is great.

The current approach is that I have added this to the jnlp file:

<security>
  <all-permissions/>
</security>

Then created a key in a keystore using the keytool:

keytool -genkey -keystore yourKeystore -alias keyname

And I sign all jar files that are to be on the user's PC using jarsigner:

jarsigner -keystore ./myapp.keystore -storepass xxx -keypass yyy <path to jar file> keyname

So the user either starts the app using the shortcut file (the jnlp file) on their desktop, or they browse to the app in Firefox. This works great, except nowadays we get this dialog that says:

Running applications by UNKNOWN publishers will be blocked in a future release

and I am worried about what will happen when that future release is out.

I do not have a deep understanding about all this code signing thing. I know that it works by embedding some binary data into files that is used to prove that the releaser of the app is a company/individual that is recognized by the Certificate Authority (and this is what jarsigner does AFAIK). Certificates are recognized by OSes like Windows and Linux, by webbrowsers like Firefox and Safari and Java also recognizes certificates at 2 levels, user and system. There are widely accepted Certificate Authorities (like Verisign) that are recognized by default in OSes like Windows and Linux. I know that webbrowsers also recognize some Certificate Authorities, but I think the list they recognize can be different from the list the OS recognizes. I guess Java also recognizes some but I do not know what. I also know that I can have system level configured keystores in Java by specifying the keystore in ~/.java/deployment/deployment.properties, deployment.system.security.trusted.certs. If I do not want to pay for a certificate, I can create my own (this is what I was doing) so my certificate is from an UNKNOWN publisher. What I was hoping for that if I specify my keystore via deployment.system.security.trusted.certs then it will solve this problem for the office but apparently it does not, which I do not understand because in this case the system administrator says that he recognizes this certificate. So now I am thinking about making a certificate using makecert in windows which can then be pushed down to client PCs via GPO. My understanding is that this will create certificates that are recognized by the OS, but I do not know if makecert made certificates would be treated the same way as e.g. verisign certificates in Windows, in Firefox and also in Java. And I do not know if UNKNOWN refers to a list within java or it refers to the fact that the Certificate Authority is not recognized by the OS.

My questions:

  1. If someone could fix the mistakes I made in the above description I would appreciate it. I believe I am misunderstanding something, but I do not know what.
  2. I just cannot believe that Webstart won't work unless we pay for a certificate. I guess what we need is a mechanism that a sysadmin can say that he wants the office PCs to recognize a given certificate. Does anyone have an idea how to do this in the future?
  3. If we have to purchase a certificate, could someone please let me know what to watch out for or how that works in general? Can I use jarsigner the same way?
  4. If we have to purchase a certificate, is there a list of Certificate Authorities out there that we can pick from? Obviously I want to go for the cheapest as I find this an administrative overhead.

Thank you for your help.

Was it helpful?

Solution

My setup that works with JRE7u40 and JRE8 is this:

I have a self-signed cert for my certificate authority (CA). This cert must be trusted by the system (e.g. add it to Java Control Panel / Security / Certificates / Signer CA, but there may be other ways to make your CA trusted).

Then I have a code publisher certificate, signed by my CA. I use this cert to sign all my code (jars).

Furthermore, if you want all permissions for your code, I suggest these MANIFEST.MF attributes as QDH minimum (since JRE7u40, if I remember):

Permissions: all-permissions 
Codebase: * 
Trusted-Library: true 
Trusted-Only: true

First time you run such application, you will still see the security warning because runtime is unable to ensure that code signer certificate was not revoked by its CA.

However, now you have the option to permanently accept this publisher (code signer certificate), and if you do, the code signer certificate will be added to trusted publishers (Java Control Panel / Security / Certificates / Trusted Certificates) and you won't see such warning again.

If you want to avoid this step, I guess you have to setup your CA infrastructure properly to support certificate revocation verification. I assume that includes some extra attributes in your CA certificate and availability of special certificate revocation service. For intranet deployment, you may skip that.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top