This site is under construction

Code Signing for Java Applets by Daniel Griscom, griscom@suitable.com

Contents

• Release History
• Overview
• Code Signing for Netscape Navigator
  • Summary of Process
  • Collect Tools
  • Set up a directory for signing
  • Find Navigator's digital ID database directory
  • Find name of your digital ID
  • Find password for your digital ID
  • Create a .jar signing batch file
  • Do the actual signing
  • Verify the signed archive
  • Install the signed archive
  • Possible problems
  • Notes
• Code signing for Microsoft Internet Explorer
  • Summary of Process
  • Collect tools
  • Set up a directory for signing
  • Create a .cab signing batch file
  • Do the actual signing
  • Verify the signed archive
  • Install the signed archive
  • Possible problems
  • Note on Microsoft Security Levels
• Signing for both Navigator and Explorer
• Links
  • Examples of signed pages
  • Tools
  • Vendors
  • Other sources of information
• Disclaimer

Release history

Overview

This document goes over the process of digitally signing a Java applet's files. I wrote it because I couldn't find a single description of this process anywhere on the Web. It's written with as much detail as possible, but with the assumption that the reader basically knows his stuff. Please send any and all comments to me at griscom@suitable.com.

By default, and for security reasons, Java applets are contained within a "sandbox." This means that the applets can't do anything which might be construed as threatening to the user's machine (e.g. reading, writing or deleting local files, putting up arbitrary message windows, communicating with arbitrary other machines, querying various system parameters, etc.). Early browsers had no provisions for Java applets to reach outside of the sandbox. Recent browsers, however, have provisions to give "trusted" applets the ability to work outside the sandbox. For this power to be granted to one of your applets, the applet's code must be digitally signed with your unforgeable digital ID, and then the user must state that he trusts your products.

A digital ID has two parts: your public certificate and your private key. The private key is what you use to sign your code; the public certificate is what other people use to verify your code was signed with your private key. When you are generating the ID (with the help of a certificate authority such as VeriSign) the private key is generated on and never leaves your machine. This means that nobody else can intercept and use your key, but it also means that if you lose the private key you can't get another one from the company. The only option then is to invalidate your old ID and request a duplicate.

Note: there's actually one more component to using a digital ID; the browser must have the corresponding certificate authority's (CA's) validating certificate. In other words, your digital ID is a document signed by a CA saying "This person is who he says he is, and this CA vouches for him", which isn't useful unless the browser can verify that the CA in question has authority.

VeriSign's certificates are included with Navigator and Internet Explorer, so those browsers are all ready to validate (or reject) VeriSign certificates. Other CAs may not have their certificates installed, which means that your user will have to explicitly install them before signatures from these CAs can be recognized.

Netscape and Microsoft have different approaches to granting extra powers to applets. Microsoft's is simpler; all you do is digitally sign an archive containing your applet. When the applet is loaded by Internet Explorer, it will immediately ask the user if she trusts the developer. If yes, then the applet runs with full access to the user's machine. If no, then Explorer tries to load the applet using the individual .class files; if it succeeds, it runs the applet in the sandbox.

With Navigator, you must add code to your applet that requests permission to do any "dangerous" actions, and then sign an archive containing the applet. This uses extra Java classes called the "Netscape Capabilities API". When the applet is loaded by Navigator it will be constrained by the sandbox. When the applet requests permission to do a "dangerous" action the user will be asked if he trusts the developer; if no, then the request fails (but the applet keeps running); if yes then the request succeeds and the applet may use the specified "dangerous" capability.

There are two separate procedures below for signing applets, one for Netscape Navigator and one for Microsoft Internet Explorer. For Navigator, the files must be signed with a Netscape Object Signing ID (creating a "manifest" of the files), and then the files and manifest must be wrapped into a .jar archive. For Explorer, the files must be wrapped into a .cab archive and then signed with an Microsoft Authenticode ID. Currently, both processes can only be done on Windows machines (Win95 or later).

Note: neither procedure below will work with Sun's HotJava browser, which requires a third method of signing altogether. Since I have no experience with this browser I haven't included any information on providing for it.

There's one further wrinkle in the process. Digital IDs are only good for a certain period of time (the default is a year). Once an ID has expired it is no longer valid. However, what about applets that were signed with a then-valid ID, but whose ID has since expired? Should the applet be trusted?

Microsoft and Netscape handle this situation in different ways. Netscape's tools won't let you sign an applet with an expired ID. However, Navigator will treat an applet signed with a currently-expired ID the same as an applet signed with a still-valid ID. Microsoft's tools allow you to attach an unforgeable timestamp to your archive. Archives which were timestamped and signed with valid IDs will be treated as secure even after the ID expires; archives that weren't timestamped or were timestamped after the ID had expired will be treated as suspect.

Code signing for Netscape Navigator

Summary of Process

Collect the tools you'll need: a digital ID, zigbert, and zip. Use zigbert from an MS-DOS window in Win95 to create a digital signature for the applet's files. Pack all the files (.class and manifest) into a single .jar file, using zip without compression and preserving directories (but stripping off the beginning of each path). Install the results. Enjoy.

Collect tools

You'll need three items to do digital signing: a Netscape Object Signing software publishing digital ID, a DOS program called zigbert.exe, and a DOS archiving tool called zip.exe.

To get the digital ID, use Navigator 4.0 under Win95 (make sure Java and JavaScript are enabled). Go to <http://www.verisign.com/>. Choose "Software Signing IDs" and click "GO", then click "Enroll for Digital ID for Netscape Object Signing". Follow the directions for enrolling for a Class 2 or Class 3 software publishing ID.

Note: VeriSign is the CA that I used for my certificates. Although it was one of the first, it now has competitors. You can check Netscape's list of CAs which supports their products at <https://certs.netscape.com/client.html>, or you can check my Vendors section below.

When you've received your ID, it will be automatically installed in a pair of files called "cert7.db" and "key3.db", both in (probably) "C:\Program Files\Netscape\users\<yourName>". This is the digital certificate database used directly by Navigator. You don't need to export anything, but when you use the code signing tools below you'll need to specify this directory, the name of the ID to use within the database, and the password for the database (if any). (Make a backup copy of the two .db files in case things get wiped out.)

To get zigbert, go to <http://developer.netscape.com/software/signedobj/jarpack.html> and click "Jar Packager Command Line (Zigbert)." You'll want to download "Zigbert 0.60 for Windows"; this is (1/5/98) at <http://developer.netscape.com/software/signedobj/zig60win.zip>. In the same page, click "Zigbert User's Guide" for further info on using Zigbert. The URL for this (1/5/98) is: <http://developer.netscape.com/library/documentation/signedobj/zigbert/index.htm>

Make sure that zigbert and zip are placed in one of the directories in your PATH, so that MS-DOS will be able to find them.

Note: There's a problem with zigbert version 0.60: it requires an application extension called msvcrtd.dll (zigbert was compiled with debugging on, and this is the debugging version of msvcrt.dll, whose name stands for MicroSoft Visual C RunTime). Netscape has a zigbert version 0.60/A, which doesn't need this application extension, but that version has a nasty bug (symptoms: you sign and zip an archive with no apparent problems, but the resulting archive is corrupted). So, you have to use version 0.60. To get around the lack of msvcrtd.dll, find your msvcrt.dll file (mine is in c:\windows\system\msvcrt.dll), duplicate it, and rename the duplicate msvcrtd.dll. This seems to satisfy zigbert, and everything works. (Hello, Netscape? Wanna fix a bug?)

Summary:

• Use zigbert version 0.60, not 0.60/A
• If zigbert complains that it needs msvcrtd.dll, then find your copy of msvcrt.dll, duplicate it, and rename it to msvcrtd.dll.

Set up a directory for signing

Create a top-level directory for the signing (I called mine "signing"). Within that directory, create a subdirectory containing all the .class files for your applet (I called mine "MyApplet"). Within the subdirectory, place copies of all .class files in their directories. Top level .class files should be right inside this directory, and all package .class files should be in subdirectories with the package names (e.g. all my "util" package .class files are inside a subdirectory called "util").

Find Navigator's digital ID database directory

For each browser user, Netscape maintains a directory holding various items, including that user's digital ID database. You'll need to specify this directory when using the code signing tool so that the tool will be able to find the public and private components of your key.

This directory is (usually) "c:\program files\netscape\users\<yourName>". To make sure, search for a directory containing the files "cert7.db" and "key3.db" (which contain your public certificate and private key, respectively). For safety, you might want to copy these files to a safe place.

Find name of your digital ID

Now that you've found the digital ID database, you need to know the exact name of your digital ID. To do this, use zigbert to list the contents of the database:

zigbert -d"<DATABASE directory>" -L

In my case, I typed this:

zigbert -d"c:\program files\netscape\users\griscom" -L

zigbert will print out a list of all certificates. Yours will have some long name based on your name, and MUST have a "*" to its left (indicating it is available for signing). I got the following results:

using certificate directory: c:\program files\netscape\users\griscom
S Certificates
- ------------
  AT&T Certificate Services
  Thawte Personal Premium CA
  GTE CyberTrust Secure Server CA
  Verisign/RSA Commercial CA
  AT&T Directory Services
  GTIS/PWGSC, Canada Gov. Web CA
  Thawte Personal Freemail CA
  Thawte Server CA
  GTIS/PWGSC, Canada Gov. Secure CA
  MCI Mall CA
  VeriSign Class 4 Primary CA
  United States Postal Service CA
  KEYWITNESS, Canada CA
  Netscape Export Control Policy CA
  BBN Certificate Services CA Root 1
  Thawte Personal Basic CA
  CertiSign BR
  VeriSign Class 3 Primary CA
  Canada Post Corporation CA
  Integrion CA
  IBM World Registry CA
  Uptime Group Plc. Class 1 CA
  VeriSign Class 1 Primary CA
  VeriSign Class 2 Primary CA
  VeriSign, Inc. - VeriSign, Inc.
  Uptime Group Plc. Class 2 CA
  Thawte Premium Server CA
  Uptime Group Plc. Class 3 CA
  Verisign/RSA Secure Server CA
  GTE CyberTrust Root CA
  Uptime Group Plc. Class 4 CA
* Daniel T Griscom's VeriSign Trust Network ID 

------------

So: my ID name is "Daniel T Griscom's VeriSign Trust Network ID", and can be used for signing (phew).

Find password for your digital ID

If you have set a Navigator/Communicator password, you'll need this password for access to the database. (Being a trusting soul I haven't set one, so the batch file below shows an empty password.)

Create a .jar signing batch file

Life's a lot easier when you let the computer do the grunt work. So, here is a DOS batch file that creates a signed .jar archive for all files in a given subdirectory. Create the following DOS batch file called jarsign.bat:

@ECHO OFF
REM Script to make a directory into a signed .jar file. Takes the directory name as
REM its argument; creates a .jar file of the same name in the directory above the
REM specified one. Note: must be run in directory above directory to be signed.

REM I'll set up a couple of variables to make things more readable. You'll need to
REM edit these values to match your setup. If you get an error such as
REM "Out of environment space" then you'll have to increase your environment space.
REM (Boy, do I love DOS.)

REM This is the location of the digital signature database
SET ID_LOC="c:\program files\netscape\users\griscom"

REM This is the name of the digital ID to be used
SET ID_NAME="Daniel T Griscom's VeriSign Trust Network ID"

REM This is the password for the database. I haven't set one for mine,
REM so I don't need anything here (the single space is ignored).
SET ID_PASSWD=" "

REM First, sign the directory [creates a META-INF directory]
REM Arguments:
REM    -d[text]    Directory holding digital signature database
REM    -k[text]    Name of ID in digital signature database
REM    -p[text]    Password for the database
REM    [rest]      Name of directory to be signed
ECHO *********** About to sign directory using zigbert ***********
zigbert -d%ID_LOC% -k%ID_NAME% -p%ID_PASSWD% .\%1

REM Now, go into the directory and create a .jar file in the directory above
cd %1
ECHO *********** About to create .jar archive with zip ***********
zip -r0 ..\%1.jar *

REM Remove the META-INF directory and contents (gotta clean up, you know...)
deltree /Y .\META-INF

REM Punt the various environment variables
SET ID_LOC=
SET ID_NAME=
SET ID_PASSWD=

REM Now shift back to the upper directory
cd ..

ECHO *********** Done creating .jar archive ***********

Change the ID_LOC, ID_NAME and ID_PASSWD values to correspond to your digital ID directory, name and password, respectively. Make sure that jarsign.bat is where MS-DOS can find it (somewhere in your PATH). Also, when you execute the batch file you must be in the directory containing the directory to be signed.

Note: including your password in the text of jarsign.bat is a classic security no-no (although it isn't as bad as not having a password at all). To be truly secure you should never store your password in plaintext. However, zigbert has (had?) a bug that prevents it from prompting you for the password. If this bug is fixed then you should be able to remove the "-p" argument from zigbert and type in your password when prompted. I haven't tried it myself.

Do the actual signing

Change to the directory that contains the directory containing your applet's .class files. Then, run jarsign with the name of the applet subdirectory as an argument:

jarsign MyApplet

You'll see lots of messages scroll up the screen. When done, a new file with the applet directory's name and the suffix ".jar" will be created.

Verify the signed archive

The first time you create a signed archive you'll want to verify it. Do this by using the -w option for zigbert:

zigbert -d"c:\program files\netscape\users\griscom" -w  MyApplet.jar

Note: you'll have to change the -d argument to match your own digital ID database directory. You might want to make the following one-line batch file, named zigcheck.bat:

zigbert -d"c:\program files\netscape\users\griscom" -w %1.jar

(again, change the directory name), and then use it thusly:

zigcheck MyApplet

If the archive is signed properly, you'll get a printout of the contents of the signing ID. If not, you won't.

Install the signed archive

Put the signed .jar archive into the web server directory containing the main class of your applet. Change the .html file that invokes the applet so that it mentions the archive:

<title>My Wonderful Signed Applet</title>
<hr>
<applet code="MyApplet.class" ARCHIVE="MyApplet.jar" width=600 height=350>
</applet>
<hr>

Possible Problems

If you sign your applet but you still get security exceptions when you run your applet then you code may not be properly using the Netscape Capabilities API to request privileges. Another clue is that you never see Navigator's security dialog, even when your code tries to do secure things. For information on the Capabilities API, see Netscape's document Java Capabilities API at <http://developer.netscape.com/library/documentation/signedobj/capsapi.html>, or Joe Bowbeer's article Signing Applets for Internet Explorer and Netscape Navigator at <http://ourworld.compuserve.com/homepages/jozart/article/index.html>.

If you sign your applet, but when you test using the "-w" option for zigbert it complains about problems with the archive, you may be using version 0.60/A of zigbert, which has a known bug. See my note above on the zigbert bug.

If zigbert complains "zigbert: PROBLEM signing data (Certificate not approved for this operation)" then your certificate isn't approved for signing archives. You probably have an Email-signing certificate instead of a software publishing certificate.

Notes

Although it should, Navigator 4.0 doesn't load .gif (and probably .jpg) images from archives. Perhaps a later version will.

If you don't have a digital ID, or you don't want to re-sign your applet again and again while developing, there is hope. Check out the Netscape tech note Activating Codebase Principals, at <http://developer.netscape.com/library/technote/security/sectn2.html>. By default, Navigator will let you trust applets with a given digital signature, or from your local hard disk (using file: URLs). If you activate codebase principals (meaning that principals, or trusted sources, can depend on where your code is based), Navigator will let you trust applets that come from specific http: URLs.

Sub-note: although the Activating Codebase Principals tech note tells you to edit the text file "prefs.js", this isn't always true. On the Macintosh, for instance, you must edit the file "Netscape Preferences", which isn't registered as a text file at all (you must force a text editor to open it, although once open it's fine). Good luck.

Code signing for Microsoft Internet Explorer

Summary of Process

Collect the tools you'll need: Internet Explorer 4, a Microsoft Authenticode digital ID, cabarc, signcode, signer.dll, javasign.dll, and chktrust. Use cabarc to create a .cab file containing the applet .class and .gif files. Use signcode to sign the archive. Use chktrust to verify the signed archive. Install the results. Enjoy.

Note: this procedure has been extensively revamped due to changes in Microsoft's tools. It is now based on the code signing tools included with Microsoft's Java SDK 2.01.

Collect tools

You'll need seven items to do Explorer digital signing: Microsoft Internet Explorer 4, a Microsoft Authenticode digital ID, a DOS program called cabarc.exe, a DOS program called signcode.exe, a DOS program called chktrust, and two application extensions called signer.dll and javasign.dll.

Download Internet Explorer from the Microsoft web site at <http://www.microsoft.com/ie/default.htm>.

To get the digital ID, use Navigator 4.0 under Win95 (make sure Java and JavaScript are enabled). Go to <http://www.verisign.com/>. Choose "Software Signing IDs" and click "GO", then click "Enroll for Digital ID for Microsoft Authenticode Technology." Follow the directions for enrolling for a Class 2 or Class 3 software publishing ID.

When you receive your ID, you will be prompted to store it in a pair of files: your certificate file (with suffix ".spc") and your private key file (with suffix ".pvk"). When you use the code signing tools below you'll need to specify the location of these two files. (Copy them onto a floppy disk for safekeeping.)

Note: you can create your own test certificates using makecert and cert2spc, which are also included with the Microsoft Java SDK (described below). You'd do something like this:

echo Making test certificate for %CERTNAME%
makecert -sk MyKeyName -n "CN=%CERTNAME%" certificate\MyTestCert.cer

echo Creating spc certificate
cert2spc certificate\MyTestCert.cer certificate\MyTestCert.spc

Check out the Microsoft documentation for more info.

Now you'll need to get the other tools. They are all part of Microsoft's Java SDK (version 2 or later), which can be found (1/5/98) at <http://www.microsoft.com/java/download.htm>. (It's a 10MB download to get 300kB of files; sorry.)

The first tool is cabarc.exe, a very simple command-line oriented "cab" archiver. There's a much more powerful alternative called diamond: it provides WAY more power and complexity than you need for Java code archiving and signing, so I'd suggest you stick with cabarc.

signcode.exe is a very simple command-line oriented code signing tool. chktrust.exe is a very simple command-line oriented signature testing tool.

Note: these tools requires the "Microsoft CryptoAPI" to work. Although this isn't documented anywhere, this API is installed when you install Explorer 4.0.

Set up a directory for signing

Create a top-level directory for the signing (I called mine "signing"). Within that directory, create a subdirectory containing all the .class files for your applet (I called mine "MyApplet"). Within the subdirectory, place copies of all .class files in their directories. Top level .class files should be right inside this directory, and all package .class files should be in subdirectories with the package names (e.g. all my "util" package .class files are inside a subdirectory called "util"). Include all images files as well (these are utilized by Explorer, although not Navigator).

Create a .cab signing batch file

Create the following DOS batch file called cabsign.bat:

@ECHO OFF
REM This batch file creates and signs a .cab file. The first argument should be the
REM name of the directory of files to be put into the cabinet (NO terminating "\",
REM please!) The second argument should be the formal name of the
REM applet. Note: you should be in the directory containing the directory of 
REM files to be CABbbed/signed when you run this.

REM I'll set up a couple of variables to make things more readable. You'll need to
REM edit these values to match your setup. If you get an error such as
REM "Out of environment space" then you'll have to increase your environment space.
REM (Boy, do I love DOS.)

REM This is the location of the digital ID certificate file (.spc). For convenience,
REM I put mine in the same directory as my Navigator ID database.
SET CERT_FILE="c:\program files\netscape\users\griscom\mycred.spc"

REM This is the location of the digital ID private key file (.pvk).
SET KEY_FILE="c:\program files\netscape\users\griscom\mycred.pvk"

REM First, create the CAB file. The arguments here are:
REM    -r        Recurse into subdirectories
REM    -p        Preserve path names
REM    -P [arg]  Strip the argument (here "%1\") from the beginning of each path
REM    N  [arg]  Create the given named .cab file
REM    [rest]    Put these files (here "%1\*.*") into the .cab file
REM Note! this does NOT use the -s option to reserve space for the signature;
REM the latest version of signcode (from the Java SDK 2.01) doesn't need this.
ECHO *********** About to create .cab archive using cabarc ***********
cabarc -r -p -P %1\ N %1.cab %1\*.*

REM Next, sign the code. Arguments are:
REM    -j javasign.dll    This provides the tools to do Java permission levels
REM    -jp  [arg]         The permission level to be used (here "low")
REM    -spc [arg]         Software publishing certificate file
REM    -v   [arg]         Private key file
REM    -n   [arg]         Nice name of archive (shown in digital ID dialog)
REM    [arg]              Archive file to be signed (here "%1.cab")
ECHO *********** About to sign archive using signcode ***********
signcode -j javasign.dll -jp low -spc %CERT_FILE% -v %KEY_FILE% -n %2 %1.cab

REM Finally, timestamp the code. (I put this in a separate command to make each
REM command simpler.) NOTE! for this to work you must have an Internet
REM connection up and running. Arguments are:
REM    -x                 Timestamp the archive; do not sign it (it's already done)
REM    -t   [arg]         The timestamp server's HTTP address (here it's VeriSign)
REM    -tr  [arg]         The number of times to try timestamping before giving up
REM    [arg]              Archive file to be timestamped (here "%1.cab")
ECHO *********** About to timestamp .cab archive using cabarc ***********
signcode -x -t http://timestamp.verisign.com/scripts/timstamp.dll -tr 5 %1.cab

REM Punt the various environment variables
SET CERT_FILE=
SET KEY_FILE=

ECHO *********** Done timestamping .cab archive ***********

Change the CERT_FILE and KEY_FILE values to correspond to the location of your public credential file and private key file, respectively. Make sure that cabsign.bat is where MS-DOS can find it (somewhere in your PATH). Also, when you execute the batch file you must be in the directory containing the directory to be signed.

Do the actual signing

Change to the directory that contains the directory containing your applet's .class files. Then, run cabsign with the name of the applet subdirectory and the formal name of the applet as an argument.

cabsign MyApplet "Super Duper Applet"

You'll see lots of messages scroll up the screen. When done, a new file with the applet directory's name and the suffix ".cab" will be created.

Note: if you don't have an active connection to the Internet when you do this, the timestamping process will fail. The resulting archive will be valid and signed, just not timestamped.

Note: the timestamping URL I give in my batch file above is for VeriSign. If your certificate wasn't issued by VeriSign then this probably won't work. Check with the CA which issued your certificate.

Verify the signed archive

The first time you create a signed archive you'll want to verify it. Do this using chktrust:

chktrust MyApplet.cab

If the archive is signed properly, you'll get a "Security Warning" dialog asking if you want to install and run "Super Duper Applet", which was signed by you (signature verified by VeriSign). If not, you won't.

Install the signed archive

Put the signed .cab archive into the web server directory containing the main class of your applet. Change the .html file that invokes the applet so that it mentions the archive:

<title>My Wonderful Signed Applet</title>
<hr>
<applet code="MyApplet.class" width=600 height=350>
<param name="CABBASE" value="MyApplet.cab">
</applet>
<hr>

Possible Problems

Timestamping may fail for a number of reasons:

• signcode can't reach the timestamping server because you aren't connected to the Internet
• signcode can't reach the timestamping server because there's heavy traffic between you and it
• You may have an incorrect timestamping URL
• The timestamping URL may not be the same CA as your certificate

If you don't see a security dialog when the applet is loaded into Explorer then the applet isn't properly signed and won't be allowed any privileges.

Note on Microsoft Security Levels

Internet Explorer actually supports three different security levels: "high", "medium" and "low." The batch file above assumes that you want the low security level, which grants all possible privileges to the applet. High level means that the applet is restricted to the sandbox, just like an unsigned applet. Medium level sounds more interesting: the applet has access to a certain amount of temporary hard disk space, and can do "user-directed" file I/O.

Problem: for your code to take advantage of these abilities you must use Microsoft-proprietary Java classes. This means that if you rely on these capabilities your code will be restricted to running on Microsoft platforms. Since I like conspiracy theories, I view this as one more attempt by Microsoft to lure programmers into writing Java code that only works on Microsoft platforms, thus subverting a major threat to their hegemony. Other, more charitable people may see this as Microsoft's generous efforts to enhance Java. You'll have to decide for yourself. For more information, see Signing a Cabinet File with Java Permissions using Signcode at <http://www.microsoft.com/java/sdk/20/tools/signcode.htm>.

Signing for both Navigator and Explorer

Although I've described the Navigator and Explorer signing processes separately, they can actually be done all at once and in the same directory. For instance, once you've set up everything as above, using the same top-level signing directory and applet directory, create the following DOS batch file called bothsign.bat:

call jarSign %1
call cabSign %1 %2

Now, invoking bothsign with the name of the applet's directory and the formal name of the applet will create both .cab and .jar archives, signed, sealed and delivered:

bothsign MyApplet "Super Duper Applet"

Once you've created both .cab and .jar archives for a given applet, you can use both in the same piece of HTML code; each browser will select the archive it understands. Use code like this:

<title>My Wonderful Signed Applet</title>
<hr>
<applet code="MyApplet.class" ARCHIVE="MyApplet.jar" width=600 height=350>
<param name="CABBASE" value="MyApplet.cab">
</applet>
<hr>

Ain't technology wonderful?

Links

Examples of signed pages

These are signed Java applets I know of that are publicly available on the Web. If you know of other examples please let me know.

I recently completed a set of signed applets for The Analytical Engine Online, a Computer Science textbook and web site. Each applet allows the user to save/load their work to/from their local hard disk, and are signed for both Internet Explorer and Communicator/Navigator. (Before you ask, I can't give out the source code for these.)

• Main page for The Analytical Engine Online: <http://www.pws.com/aeonline/course/index.html>
• Logic Simulator applet: <http://www.pws.com/aeonline/course/7/2/index.html>
• Expression parser applet: <http://www.pws.com/aeonline/course/6/2/index.html>
• CPU Simulator applet: <http://www.pws.com/aeonline/course/7/5/index.html>

Tools

The zigbert code signing tool and zip archiver (as of 1/7/98): <http://developer.netscape.com/software/signedobj/zig60win.zip>

Zigbert User's Guide (as of 1/7/98): <http://developer.netscape.com/library/documentation/signedobj/zigbert/index.htm>

The Microsoft Java SDK 2.01, which contains cabarc.exe, signcode.exe, chktrust.exe, signer.dll and javasign.dll (as of 1/7/98): <http://www.microsoft.com/java/download.htm>

Vendors

VeriSign, at <http://www.verisign.com/>, is the only full-service on-line vendor of software signing IDs ("certificate authority") that I know of. They also provide their customers with a timestamping service at <http://timestamp.verisign.com/scripts/timstamp.dll> (this URL can only be used by signcode as shown above). They have a useful page called Introduction to Digital IDs, including information on timestamping, at <http://digitalid.verisign.com/id_intro.htm>.

SECUDE is a new certificate authority; currently they only provide certificates for testing purposes: <http://www.secude.com/trustfactory/>

Thawte Certification, at <http://www.thawte.com/>, is a competitor of VeriSign's. They seem to sell all types of certificates via the Web, claiming to be cheaper. Unfortunately, my primary browser (IE 3.0/Mac) can't establish a secure connection to their server, which leads to lots of annoying error dialogs, so I haven't investigated further. Your mileage may vary.

Entrust is another certificate authority: they are at <http://www.entrust.com/>. They have a page offering free certificates at <http://www.entrust.com/freecerts/index.htm>, but I believe that the certificates aren't good for software signing.

Microsoft has a number of useful web pages:

• General developer web site: <http://www.microsoft.com/msdn/>
• Software development kits: <http://www.microsoft.com/msdn/sdk/>
• Java information: <http://www.microsoft.com/java/>
• Cabinet (.cab) file information: <http://www.microsoft.com/workshop/prog/cab/>
• Signing a Cabinet File with Java Permissions using Signcode: <http://www.microsoft.com/java/sdk/20/tools/signcode.htm>
• Signing and Checking Code with Authenticode: <http://www.microsoft.com/msdn/sdk/inetsdk/help/compdev/controls/authenticode/signing.htm>

Netscape also has a number of good pages:

• Java Capabilities API talks about the code you'll need to add to your applet to request privileges under Netscape: <http://developer.netscape.com/library/documentation/signedobj/capsapi.html>
• The JAR Format: <http://developer.netscape.com/library/documentation/signedobj/jarfile/jar.htm>
• Using JAR Installation Manager for SmartUpdate: <http://developer.netscape.com/library/documentation/communicator/jarman/index.htm>
• Object Signing FAQ: <http://developer.netscape.com/support/faqs/objfaq.html>
• Object Signing Resources: <http://developer.netscape.com/software/signedobj/index.html>
• Security - Frequently Asked Questions: <http://developer.netscape.com/support/faqs/champions/security.html>
• Netscape Object Signing: Establishing Trust for Downloaded Software: <http://developer.netscape.com/library/documentation/signedobj/trust/owp.htm>
• Signing Software with the Netscape Signing Tool [zigbert]: <http://developer.netscape.com/library/documentation/signedobj/zigbert/index.htm>
• Netscape System Targets: <http://developer.netscape.com/library/documentation/signedobj/targets/contents.htm>
• Activating Codebase Principals: <http://developer.netscape.com/library/technote/security/sectn2.html>
• A list of Certificate Authorities that support Netscape's products: <https://certs.netscape.com/client.html>

And of course, there's always Sun:

• Main Java site: <http://java.sun.com/>
• Java security pages: <http://java.sun.com/security/>
• Frequently Asked Questions - Applet Security: <http://java.sun.com/sfaq/>
• JDK 1.1: Signed Applet Example [this shows Sun's applet signing technology]: <http://java.sun.com/security/signExample/>

Other sources of information

For a good overview of this process, along with information on Netscape's Capabilities API, see Joe Bowbeer's article Signing Applets for Internet Explorer and Netscape Navigator: <http://ourworld.compuserve.com/homepages/jozart/article/index.html>. (Note: this article was in the June 1997 issue of JavaUniverse, which has since gone the way of all flesh. The author has reposted it on his own site.)

Disclaimer

I believe this document to be fairly complete and correct. However, it may contain errors of various magnitude. Although I'm interested in hearing about any such errors, and will attempt to fix those brought to my attention, this information comes with no warranty, and I am not responsible for any harm you may come to by using it. Sorry.

Now my lawyer is happy.

This document has been viewed 290 times since 3/10/98.

Top of Page | Home | Suitable Systems | Projects | Documents | Demos | Family | Links