January 18, 2021
Hot Topics:

Signing Java with Microsoft's Authenticode

  • By John Viega
  • Send Email »
  • More Articles »

Not surprisingly, Microsoft, Netscape, and Sun have each developed a separate system for signing Java code, allowing applets to play outside the sandbox. In other articles in this series, we cover Netscape's and Sun's system; here is a look at Microsoft's.

Step one is securing an identity with which you can sign code.

Getting an Authenticode Certificate

A number of vendors distribute certificates suitable for Authenticode. Verisign, the certificate authority (CA) that provides Netscape Object Signing certificates, also issues Authenticode certificates.

You'll need to select a flavor of ID. For personal use, select class 2 (US$20 on your credit card). For business use, select class 3.

You'll be given a form to fill out, after which Verisign will try to verify you are who you say you are, mainly by running a credit check. Sometimes the credit check won't have up-to-date information. If you're rejected, try using the address of the last place you lived; that's the most common problem.

Once your data has been approved, Verisign sends an e-mail with instructions for picking up the certificate. When downloading the certificate, you will need to save two files: the private key file and the certificate file. Remember the password used to protect the private key; it will be needed when it comes time to sign code. For the sake of simplicity, we'll assume you saved your certificate as a:\Cert.spc and your private key as a:\Key.pvc.

Getting the signing software

Before signing anything with the certificates, download and install the Microsoft Java SDK.

We'll assume you installed the Java SDK in the directory C:\SDK-Java.31. All of the programs we're going to need for signing Java code live in C:\SDK-Java.31\Bin\PackSign, so you should probably add that directory to your path. Under Windows 95/98/NT, running the following command at the DOS prompt will fix up your path for the current session:


You can add this command to your autoexec.bat file to make the change persist through a reboot.

Cabinet files

Unlike the other signing tools we discussed (which work on JAR files), Authenticode signing only works on cabinet (CAB) files. There's nothing special about the CAB format; it's just another way of archiving many files into one. However, it's the only archive format IE supports for signing Java code.

Say we have an applet that consists of two files: file1.class and file2.class. We can create a CAB file in the same directory by typing the following at the DOS prompt:

cabarc N test.cab file1.class file2.class

If there are no other class files in the directory, we can also type:

cabarc N test.cab *.class

Security zones

In order to understand what signing a CAB file means, we need to know a little something about what an IE "security zone" is. By default, a security zone is a group of Web sites. Each zone is assigned a security level, which may be Low, Medium, High, or Custom. We won't cover Custom zones, except to say that they can implement arbitrary security policies.

There's a default zone called Trusted Sites, into which a user can put any server. All code from that zone will be completely trusted (i.e., the zone has a Low security level). Similarly, there's a Restricted Sites zone. Any sites the user puts in this zone will need explicit permission before they can run anything "outside the sandbox." By default, most everything else falls into the Internet zone, which is assigned a Medium security level. Code can run outside the Java sandbox in a limited manner. For example, code can use up to 1 megabyte of data in a restricted area on your hard disk by using the API com.ms.io.clientstorage, which works out of the box with Internet Explorer only. Unlike fully trusted applets, applets restricted to the Medium security level should not otherwise be able to use your file system.

When signing our cabinet file, we request to run either with Medium or High privileges (we can also request Low privileges, but since we'll always be allowed to run in the sandbox, doing so is mainly useful only to prove you vouch for the CAB file). If our code ends up in a Low security zone, our code will always run without prompting the user for permission. If our code ends up in a Medium security zone, then before code that requests Medium level privileges can run, the user will be prompted as to whether to let the code run. If our code ends up in a High security zone, all code that wants to run outside the sandbox will need to be approved through a dialog with the user.

Signing CAB files

To sign test.cab, we're going to use the signcode command, which is included in the Java SDK. Here's a typical command line:

signcode -j JavaSign.dll -jp <br>
High -spc a:\Cert.spc -v <br>
a:\Key.pvk -n "My Applet" -i <Br>
http://www.mywebpage.com/ test.cab<br>

The flags here are a bit arcane. If you want your CAB file to request permisions, the -j flag should always be there, and take JavaSign.dll as a parameter, unless you're signing something other than Java code (the same command can be used to sign Active X controls and other mobile code too). The -jp flag passes a parameter to the DLL. For Java signing, that's how we request High privileges. The -spc flag and -v flag are used to specify the location of your certificate and private key, respectively. The -n option needs to be present, and it specifies the name of the software, which is displayed to the user before the user decides whether to run your code. The -i option specifies where to go for more information about the product, which also gets displayed when the user is prompted to give your code permission to run. You can also "timestamp" your signature, so that after your certificate expires, your applet will still work. However, doing so requires a timestamp server, which isn't covered here. For more information on Authenticode for Java, visit Trust-Based Security for Java.

To confirm that everything has worked properly so far, run the command:

chkjava test.cab

A window should appear similar to the one an end user will see when IE asks if the application should be allowed to run.

Making test certificates

To avoid putting down some cash for a real certificate from a CA and still be able to play around with Authenticode, you can make a test certificate. The first step is to create the certificate with the command:

makecert -sk Key.pvk -n "CN=Your Name" Cert.cer

That command makes a certificate and a private key you can use in other applications, but it won't work for code signing. To get it to work with code signing, convert it to a Software Publisher Certificate (SPC) by typing:

cert2spc Cert.cer Cert.spc

Now you can use Key.pvk and Cert.spc for testing purposes in the same way as if they came from a CA.

Page 1 of 2

This article was originally published on October 29, 1998

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date