Signing Applets - Java Plugin
This section contributed by s. nichols; last updated 9/4/99 Contents The 1.1 version of the Sun Java Plugin

Another possibility for deploying a Java applet is to use the Sun Java Plugin (see <http://www.javasoft.com/products/plugin/index.html>). The benefit of the Java Plugin is that the same Java virtual machine is used independent of the browser. This is accomplished by installing the Java runtime environment as an Active X control in Internet Explorer and as a Netscape plugin in Netscape. The Java Plugin is currently (10/27/98) available for Windows 95, 98 and NT; Solaris on Sparc and x86; and Linux; it is not yet available for the Macintosh. 

Like Netscape and Internet Explorer applets that use the "native" virtual machines, Java Plugin applets can be signed as well. The bad news is, they use yet another signing model. Signing the applets is quite straight forward; an overview can be found at <http://www.javasoft.com/products/plugin/1.1.1/docs/signed.html>. Everything is done with the Sun javakey tool, which ships with the JDK. More information about javakey can be found at <http://www.javasoft.com/products/jdk/1.1/docs/tooldocs/solaris/javakey.html> and <http://www.javasoft.com/security/usingJavakey.html>

The fundamental flaw with this whole scheme is that, as of Java Plugin 1.1.1, there is no automated way to distribute your certificates. The certificates are kept in the java security database (usually identitydb.obj), and javakey is the only tool to manipulate this database. This means that users must install your certificate (as well as the Java Plugin) before their browsers will recognize your signed applet.

These shortcomings are sometimes discussed on <news:comp.lang.java.security>.  The bottom line is this: if you are deploying on Plugin 1.1, you are going to have to do some extra work to make the security system usable.

Rolling Your Own Installer for the Sun Java Plugin 1.1

One approach that some developers have taken is to roll their own installers. The steps to do this would go roughly like this (disclaimer: I have not done this myself, so some research is probably in order if you decide to try this).  The certificates are kept in a file identitydb.obj, pointed to by the property identity.database in the java.security properties file. Assuming that you have generated an X509 certificate using javakey, you will want to put the certificate into a java security database. The goal is to put it into an empty database, so as not to give away your private keys. If you change the identity.database property, and then create the certificate, you should end up with a security database which only contains your certificate.

The next step is to somehow get this security database onto your client's machine. Note that when you do this, if any other client was using this mechanism, you will break their applet because you are replacing or renaming the entire security database. This technique is probably only appropriate for intranet applications where you, and only you, are deploying all of the Java Plugin applets. Anyway, at this point you now have to write an applet to download the identitydb.obj file, read the java.security properties file, and either set identity.database to point at your new file, or overwrite the existing identitytdb.obj. Since this involves reading and writing to the local filesystem, your applet will need to be signed, which means you are back to supporting signed IE and/or NS applets.

Bypassing the Sun Java Security System and Using PVCj As Your Installer for the Sun Java Plugin 1.1

PVCj is an open source tool for deploying Java plugin applications.  It takes advantage of the fact that the Plugin has a local classpath, and fully trusts anything on that classpath.  It works like this: first, you have to somehow get the PVCj jar file onto the local machine.  Then, you modify your HTML page that starts the applet to point to the PVCj applet instead.  PVCj defines some parameters which specify a URL for the jar files you'd like to download.  PVCj checks the local class path against the remote server and, if the local files are out of date or missing, downloads the jar files from the remote server.  Another parameter specifies another HTML page, which does specify your plugin applet as the launch point.  PVCj redirects the browser to the new page, the plugin finds the applet class files in a local  directory, and launches the applet with full privileges.

PVCj does do rudimentary security; you can specify which class C domains you are willing to trust.  I'm not sure if I would use PVCj for an internet application, but for LAN based intranet stuff, it works great.  I've rolled out several Java/CORBA clients using PVCj; after a lot of experimentation, it is the best solution I've found for Java 1.1.x applets.  You can get more information or the tool itself at:

<http://www.granitepeaks.com/pvcj/>

PVCj also works with the 1.2 version of the plugin.  Note that you still have to somehow get pvc.jar onto the client machine.  One the applications I've done -- Windows 95/NT running IE4 -- we've used a signed Active-X control to do this.

Sun Java Plugin 1.2

I don't have direct experience with any of the 1.2 flavors of the plugin, but it looks like Sun has finally addressed the signing issue with release 1.2.2 of the plugin. In brief, the plugin can now recognized "Netscape Object Signing"-signed applets, so that applets signed as in the "Netscape" section of this document will be recognized by the plugin.

You can read more about this in "DEPLOYING RSA SIGNED APPLETS IN JAVA TM PLUG-IN", at <http://java.sun.com/products/plugin/1.2/docs/nsobjsigning.html>.

Next section: Creating and Installing Test Certificates

 

 

 
  
    Copyright © 2012 Daniel Griscom Site design myriadweb.com  
Home Page Home Page Home Page