![]() |
This site is under construction |
![]() |
Code Signing for Java Appletsby Daniel Griscom, griscom@suitable.com |
![]() |
3/10/98: | added hit counter to page (vanity, thy name is consultant...) |
3/6/98: | added links to example signed pages |
2/28/98: | fixed zigbert template line for listing databaseadded note about Entrust's free certificates added link to document on Netscape's Capabilities API added problem-solving sections |
2/3/98: | added note about why timestamping might fail added three new Netscape document links |
1/16/98: | updated URL of Signing Applets for Internet Explorer and Netscape
Navigator tweaked formatting |
1/15/98: | added note about activating codebase principals for Navigator added creation of test certificates for Authenticode changed incorrect msvcrt.dll to msvcrtd.dll added certificate authority Entrust added note about CA certificates being installed on browsers |
1/12/98: | added certificate authority Thawte |
1/10/98: | added table of contents added verification info for .jar files |
1/8/98: | noted bug in zigbert version 0.60/Aupdated to match changes in Microsoft's and Netscape's tools added information on timestamping archives enhanced and cleaned up batch files checked and updated links |
12/15/97: | joined split line in jarsign.bat |
12/12/97: | added note about zigbert and passwords |
12/5/97: | removed angle brackets from within zigbert documentation
link |
12/4/97: | updated location of Microsoft tools changed incorrect "zigsign.bat" references to "jarsign.bat" added certificate authority SECUDE |
10/29/97: | first release |
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.
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.
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 calledmsvcrtd.dll
(zigbert
was compiled with debugging on, and this is the debugging version ofmsvcrt.dll
, whose name stands for MicroSoft Visual C RunTime). Netscape has azigbert
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 ofmsvcrtd.dll
, find yourmsvcrt.dll
file (mine is inc:\windows\system\msvcrt.dll
), duplicate it, and rename the duplicatemsvcrtd.dll
. This seems to satisfyzigbert
, and everything works. (Hello, Netscape? Wanna fix a bug?)Summary:
- Use
zigbert
version 0.60, not 0.60/A- If
zigbert
complains that it needsmsvcrtd.dll
, then find your copy ofmsvcrt.dll
, duplicate it, and rename it tomsvcrtd.dll
.
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").
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.
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).
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.)
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 fromzigbert
and type in your password when prompted. I haven't tried it myself.
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.
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.
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>
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.
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.
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.
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.spcCheck 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.
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 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.
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.
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.
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>
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 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.
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>.
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?
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.)
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>
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:
Netscape also has a number of good pages:
zigbert
]:
<http://developer.netscape.com/library/documentation/signedobj/zigbert/index.htm>
And of course, there's always Sun:
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.)
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.
Copyright © 1998 Daniel T. Griscom |
Created on Macintosh computers. |