专业签署小程序

Question

I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions. I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database. The applet used to work with the database when I self signed it, but not anymore. In addition, many unknown users will be using the applet, so I won't have control over their machines.

Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?

Answer 1

Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs

Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.

update : This page ( Java Control Panel Documentation ) describes what type of signature is required for various client side security level settings:

Answer 2

As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services ¹ works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.

1. It is relevant in that:
   • It uses a self signed certificate
   • It allows a sand-boxed app. to read/write to the local file system.
   • An applet launched using JWS has access to the API.

This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate . Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best ).

As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.