JavaPlugin 1.4.0 Security Dialogues

M. Gallant 07/17/2001

Quick Tips for Developing RSA-signed JavaPlugin Applets

To avoid having to jar and sign after each source code edit, use a temporary local policy file, placed in the default user.home directory (so it will be automatically found by your Java 2 runtime environment) with an entry specifying full privileges, and a codeBase specifying your entire local drive. . A very simple and useable policy file, for example is:
```
 grant codeBase "file:/C:/-" {
  permission java.security.AllPermission;
};
```
In this way, you can quickly develop privileged code, without RSA signing that can be quickly tested with no annoying security prompts associated with RSA-signed JAR archives. The html-converted page can be used without any changes, but remove any jar archives in the deployment directory so that the class files are used, along with the local policy file. Note that since we are temporarily not RSA signing the code into a jar archive, the usePolicy privilege does NOT need to be added to the policy file statement. When all source edits are completed, replace the full-privileges policy file with your default one (or none, if you never use policy files). Then jar the classes, and RSA sign the jar file and test.
To force an instant reload of any recompiled source code and or signed jar archives, use the x option in the JavaPlugin Java Console ("clear classloader cache"). It will instantly flush any cashed classes and jar archives.

JavaPlugin 1.4.0, deployed with J2RE1.2 v1.4b has improved functionality over earlier versions. It allows RSA-signed Java applets to run:

even if the root CA certificate is not recognized (i.e. not present in the C:\Program Files\JavaSoft\JRE\1.4\lib\security\cacerts certificate file).
even if the certificate used to sign the JAR archive has expired at run time.

This status is displayed to the user, as shown below, and as usual the user has the choice to allow/disallow the applet to run, based on the user's personal trust decision on the origin of the code (e.g. web-site deployed from), and the code-signer's identity.
[Note that J2SE1.2 v1.4+ also conveniently provides the htmlconverter utility in the C:\jdk1.4\lib directory]

The screen shots below show the JavaPlugin 1.4.0 dialog for an applet, signed with an RSA code-signing certificate, issued by an enterprise CA. This root CA is not present, by default, in the cacerts file, as shown in the first image. Importing the enterprise root CA certificate into the cacerts database file shows that the CA responsible for issuing the code-signing certificate is now recognized, as displayed in the second image:

[before importing root CA certificate into cacerts]

[after importing root CA certificate into cacerts]

The image below shows a different example; a cross-certified Thawte/Entrust issued certificate. No importing of the root CA certificate was required here, as the standard Thawte root CA already exists in cacerts. In this way, enterprises using this approach maintain control of their issuance policies, while requiring minimal end-user configuration:

[Thawte/Entrust cross-certified enterprise certificate example]