Notes on Java Applets

Notes on Java Applets

Martin Carrudus considers Java Applets and the signing thereof....

If you want to run a peice of Java code on Internet Explorer then the Java Applet code has to be signed to show who it came from and which site it's supposed to be run from. In this short article I will explain the process you have to go through below. This is based on my own experiences and works for me, but I cannot guarantee the accuracy of this information, take heed of it at your own peril!

Note on the Java Applet method 'paint

I was trying to generate a fractal fern pattern in a web page by plotting a series of points, but nothing was appearing on the web page (using the MSDOS command line facility 'appletviewer'). I experimented with an example Java Applet given in a book. This was designed to plot a series of circles from the 'paint' method. I expected to see a series of circles appear, but instead saw a single circle moving across the web page area. It suddenly dawned on me that you must completely regenerate any pattern you want to appear EVERY time Java calls the 'paint' method.

This had not been made clear to me. From then on, I simply stored up all the (randomly) plotted point co-ordinates so far in an array and redrew all of them each time 'paint' was called and the pattern appeared correctly.

Using the JDK command line tools.

Having downloaded the tools, it helps to alter the MSDOS system variable 'path' by adding the path of the folder 'bin' separated by a semi-colon at the end. Find it at the bottom of the 'System' panel off the 'Control Panel'. You may then reference these tools on the command line from whichever folder you are currently looking at.

The 'keytool' Tool.

To add a record to the keystore, my manual gave the keytool switch as '-genkey', but I found it to be '-genkeypair'. There is both a 'public' key and a 'private' key generated. The 'public' key you supply to the keystore. Suppose this to be 'status'. My manual gave the so-called 'common name' (CN) to supply as your own name, and also didn't mention two additional names to be supplied to the keystore, which are 'location' (L) and 'state' (S), in addition to your country (C). The switch -v gives out additional information. So the full command (In my case) should have been:

  -  keytool -genkeypair -v -alias Mart -keyalg DSA -keysize 1024 -dname "CN=Martin
Carradus, OU=Programming, O=Leaf Mindcraft, L=Keighley, S=West Yorkshire, C=UK"
-keypass secure -storepass status

All on the same line, of course. All fine so far.

Certificate Signing Authorities.

These are sites that take your 'cerificate' (more of later), verify it, then send you back a 'signed certificate'. Some charge, but I hit on the site www.cacert.org, that did it for free.

However, I eventually discovered that the 'signed certificate' is only valid for six months, which is rather inconvenient.

You generate your 'certificate' file (in this case 'Mart.csr', but you must give the full pathname where you want the file to be created) from the 'keystore' with the command (on one line):

  -  keytool -certreq -alias Mart -file Mart.csr -keypass secure -storepass status

You will find that you need to 'cut' the contents of the .csr file and 'paste' ALL the contents including the header and trailer with the hyphens and wording in them to the writable area supplied by CAcert.

The First Problem encountered.

It became apparent that CAcert was trying to establish your 'domain', which was really your web site URL address, in stages. So, firstly, I had to establish the first part of my URL, which is 'martinkd.freeuk.com'. It sends an email to 'webmaster@martinkd.freeuk.com', which seemed to get through to my actual email address. The email offers you a 'cerificate', but it seems to be quite happy that you have just received the email alright.

For these purposes, I found that the CN part of my keystore should have NOT been my name, but 'martinkd.freeuk.com'. As far as I know, you have to supply this .csr file with the correct CN part BEFORE it contacts 'webmaster@martinkd.freeuk.com'.

Having established this 'domain' CAcert then trys to contact your full URL e.g. 'www.martinkd.freeuk.com' at the email address 'root@www.martinkd.freeuk.com', only when you supply a .csr file contents with the CN given as e.g. 'www.martinkd.freeuk.com'. It took 24 hours, but the email generated got through to me.

At this stage, I got side-tracked by a file called 'trustedcacerts' (?) that only has about 25 'trusted' Certification Authorities. You can supply this to 'keytool' when you 'import' the returned 'signed certicate' into the keystore (more later). I thought it didn't 'trust' CAcert because it was not in this list, but things were going wrong for other reasons.

The Second Problem encountered.

CAcert required that I supply a password that had no discernable English word in it, and, preferably, some numerics/non-alphabetics in it. I hit on using my old B.Ae. clock number.

Let us suppose the password was 'B.Ae.123456'. Having cut and pasted the final 'signed certificate' for CN 'www.martinkd.freeuk.com' into a file called 'Mart.cer', you 'import' it into the keystore with the command:

  -  keytool -importcert -alias Mart -file Mart.cer -keypass secure -storepass status

I then discovered it was complaining about a 'public key'. What it was trying to say was that BOTH your public keystore password AND your CAcert password should agree. I found that there was a keytool command that I used to alter the keystore password from 'status' to 'B.Ae.123456'.

However both the public and private keys must agree. So you must regenerate the .csr file (with CN given as your full web site URL), cut and paste the contents into the writable area that CAcert provides, click the button, and eventually CAcert provides a 'signed certificate', that you cut and paste from a panel on the web page into your .cer file. Finally you need to issue the command:

  -  keytool -importcert -alias Mart -file Mart.cer -keypass secure -storepass B.Ae.123456

Which should do the trick! But beware. The 'signed certificate' contents must end at the final hyphen, or you get a rude message about 'error at end of file', or somesuch. However, I found it still did the trick.

JAR Files

These are compressed files (using the same compression as TAR, incidentally) that contain your Java Applet, and which you eventually sign, using 'jarsigner' in combination with the already 'signed' keystore. You have to create the JAR file first. The manual ranted on about an included 'manifest' .MF file. I thought I'd have to create one, but one is automatically created for you.

The command you need is:

  jar -cvf Leaf.jar Leaf.class

where 'Leaf.jar' should be the full pathname of the JAR file you wish to create, and 'Leaf.class' is the full pathname of your compiled Java Applet. The 'v' option produces a file listing including the name of 'manifest' .MF file.

Finally you 'sign' your JAR file with a command like:

  -  jarsigner -verbose -keypass secure -storepass B.Ae.123456 Leaf.jar Mart

The -verbose (NOT -v, note) option gives out information about what 'jarsigner' did. The 'Mart' part refers to the alias of your signed record in your keystore.

Signing Java Applets in HTML

The HTML tag you need is of the form:

 <applet code="Leaf.class" archive="Leaf.jar" width=100 height=100
codebase="/Java/">  Your browser does not understand Java.</applet>

That is, if you are holding your .class file and .jar file in a folder 'Java' relative to your web space URL. It DOES seem to need both the class and .jar files.

The Final Problem

When I run the HTML with the embedded signed Java Applet with 'appletviewer', it gives off messages seeming to indicate that you need to 'import' additional security method packages into your Java Applet. Ho hum...

Addendum

Due to the error messages I was getting when introducing Java Applets into HTML, I thought I needed to 'import' extra security package classes into the Java. The answer was, that the Java compiler, javac, was producing extra .class files in addition to the main class file output, and all of these needed digitally signing.

In my case, I was using 'objects' 'PaintSurface' and 'AnimationThread' in addition to my main 'Leaf' class, so I got additional 'PaintSurface.class' and 'AnimationThread.class' files. The MSDOS command line instruction needed to combine these all into a .jar file was:

  jar cvf Leaf.jar Leaf.class PaintSurface.class AnimationThread.class

Then to 'sign' this, the command I needed, was, as before:

  jarsigner -verbose -keypass secure -storepass B.Ae.123456 Leaf.jar Mart

Where 'Mart' is the alias for the keystore created previously and 'signed' by me by obtaining the certificate from the Certificate Authority over the Internet, and 'B.Ae.123456' was the public key I chose to use and present to the same Certificate Authority.

The -verbose option will cause 'jarsigner' to inform you:

That it has 'signed' Leaf.class, PaintSurface.class and AnimationThread.class
That the validity of the 'certificate' is only for six months.

As far as I know, you must also upload the extra .class files into your web space, in addition to your main one.

Martin Carrudus