Java 1.2 Unleashed
Applet security is a major concern among Web users and applet developers. From a user's perspective, an exploitable applet security flaw could result in sensitive data being modified or disclosed, or their computer being rendered inoperable. From a developer's perspective, strong applet security is necessary to make Web users comfortable with using applets. However, too high a level of security limits their applets' capabilities.
The JDK 1.2 security model meets both user and developer needs. It allows users to maintain high levels of security, by default, and also to relax these security controls to take advantage of additional applet capabilities that are provided by developers they trust.
In this chapter, you'll learn how to use the JDK 1.2 security model to develop applets that extend the bounds of the applet sandbox and use previously restricted capabilities. First, you'll learn how to package your applets as Java Archive (JAR) files and how to digitally sign these files. You'll then learn how the JDK 1.2 security model supports trusted applets and how users can configure their Java Runtime Environment (JRE) to use trusted applets. You'll also learn about digital certificates and how they are used to support applet security. You'll get hands-on experience using the JDK 1.2 security tools and cover the JDK 1.2 Security API. When you finish this chapter, you'll be thoroughly introduced to applet security.
A JAR file is a compressed archive file that is created using the Java archive tool (jar), which is similar to the PKZIP program developed by Phil Katz. It combines multiple files into a single archive file that is compressed using the ZLIB compression library. Although jar is a general-purpose file archive and compression tool, its main purpose is to combine the files used by an applet into a single compressed file for efficient loading by a Java-enabled Web browser.
NOTE: A description of the ZLIB compression format is available at the URL http://www.cdrom.com/pub/infozip/zlib/.
Using jar with applets can greatly improve browser performance. Because all of the files used by an applet are combined into a single file, a browser only needs to establish a single HTTP connection with a Web server. This reduces the communication processing overhead on both the browser and the server. File compression reduces the time re- quired to download an applet by 50% or more. This benefits both the applet's user and publisher.
Another feature of JAR files is that they support the capability to sign archived files. This allows browsers to differentiate between untrusted applets and those applets that may be trusted to perform sensitive processing in a secure manner (because they are signed by a reputable identity). The sensitive processing that is permitted of trusted applets is determined by the local Java security policy.
The jar tool is easy to use. You invoke it using the following command line:
jar [options] [manifest] jar-file input-file(s)
The jar-file is the file that is to be used as an archive. The .jar extension should be supplied in the command line. The input-file(s) are written as a space-separated list of files to be placed in the archive. Filename wildcard characters may be used (for example, *.class).
The manifest is a file that contains information about the archived files. It need not be supplied--jar will create one automatically and store it as META-INF\MANIFEST.INF within the archive. Information about the manifest file can be found in the file docs\guide\jar\manifest.html that is included with the JDK 1.2 API documentation.
The jar options are used to control the input and output of the jar tool. They are described in Table 8.1.
| Option | Description |
| c | Creates a new (empty) archive file. |
| t | Displays the archive's table of contents. |
| x [file(s)] | Extracts the specified file(s). If no files are specified, all files are extracted. |
| f | Identifies the file to be created, listed, or extracted. |
| v | Generates verbose output. |
| u | Used to update an existing JAR file. |
| C | Used to change directories during execution of the jar command. |
| 0 | Stores files but does not compress them. |
| M | Skips creation of the manifest file. |
| m manifest | Uses the supplied manifest file. |
NOTE: The syntax of the jar tool is similar to the UNIX tar command.
NOTE: The @ character may be used in a jar command, followed by a file name. When this occurs, command arguments are taken from the file (one argument per line) and inserted into the command at the position of the @ character.
Examples of using the jar tool are provided in the following sections.
If you have ever used the UNIX tar command or the DOS PKZIP program, you will find the jar tool to be familiar and easy to use. In this section, you'll learn how to create a JAR file for the Edit applet that you developed in Chapter 7, "Working with the Canvas."
We'll use the Edit applet because it uses several .class files, which makes it a good candidate for archival and compression. Start by copying the Edit.java, MyList.java, FontDialog.java, and ColorDialog.java files to your ch08 working directory and then recompile these files. The following 11 .class files are created in your ch08 directory:
ColorDialog.class ColorDialog$ButtonHandler.class ColorDialog$WindowEventHandler.class Edit.class Edit$ButtonHandler.class Edit$FontSelectHandler.class FontDialog.class Edit$ColorSelectHandler.class FontDialog$ButtonHandler.class FontDialog$WindowEventHandler.class MyList.class
Let's use jar to archive and compress them into a file named edit.jar:
jar cf edit.jar *.class
List your directory to verify that the JAR file was created:
Directory of C:\jdk1.2\ju\ch08
. <DIR> 04-22-98 11:27a .
.. <DIR> 04-22-98 11:27a ..
COLORD~1 JAV 2,448 02-08-98 9:20a ColorDialog.java
EDIT~1 JAV 1,968 02-08-98 10:50a Edit.java
FONTDI~1 JAV 3,667 02-08-98 10:42a FontDialog.java
MYLIST~1 JAV 310 02-08-98 9:19a MyList.java
COLORD~1 CLA 2,908 04-22-98 11:34a ColorDialog.class
COLORD~2 CLA 1,324 04-22-98 11:34a ÂColorDialog$ButtonHandler.class
COLORD~3 CLA 615 04-22-98 11:34a ÂColorDialog$WindowEventHandler.class
EDIT~1 CLA 1,914 04-22-98 11:34a Edit.class
EDIT$B~2 CLA 1,545 04-22-98 11:34a Edit$ButtonHandler.class
EDIT$F~2 CLA 1,016 04-22-98 11:34a Edit$FontSelectHandler.class
FONTDI~1 CLA 3,880 04-22-98 11:35a FontDialog.class
EDIT$C~2 CLA 1,214 04-22-98 11:34a Edit$ColorSelectHandler.class
FONTDI~2 CLA 1,101 04-22-98 11:35a FontDialog$ButtonHandler.class
FONTDI~3 CLA 609 04-22-98 11:35a ÂFontDialog$WindowEventHandler.class
MYLIST~1 CLA 431 04-22-98 11:35a MyList.class
EDIT JAR 11,527 04-22-98 11:36a edit.jar
16 file(s) 36,477 bytes
2 dir(s) 197,722,112 bytes free
Note that bj.jar is only 11,527 bytes long. Because the 11 class files are 16,557 bytes, the jar tool compressed them to 70% of their original size. Now that the .class files are archived, delete them using del *.class.
Let's use the list option of the jar command to see what's inside the edit.jar file:
C:\jdk1.2\ju\ch08>jar tf edit.jar META-INF/MANIFEST.MF ColorDialog$ButtonHandler.class ColorDialog$WindowEventHandler.class ColorDialog.class Edit$ButtonHandler.class Edit$ColorSelectHandler.class Edit$FontSelectHandler.class Edit.class FontDialog$ButtonHandler.class FontDialog$WindowEventHandler.class FontDialog.class MyList.class
The only thing that looks out of place is the META-INF/MANIFEST.MF entry. That's the file used to keep a manifest of the JAR file's contents.
You're probably wondering how you would include the edit.jar file in an applet. The answer is that you add the ARCHIVE="edit.jar" attribute to the applet tag. This attribute tells the browser to load the edit.jar archive file to find the Edit.class file and other related classes. Listing 8.1 shows the file Edit.htm that is used to display the Edit applet.
<HTML> <HEAD> <TITLE>Text Editing</TITLE> </HEAD> <BODY> <APPLET CODE="Edit.class" ARCHIVE="edit.jar" HEIGHT=400 WIDTH=600> </APPLET> </BODY> </HTML>
You can view the Edit applet using the appletviewer tool, as follows (see Figure 8.1):
appletviewer Edit.htm
FIGURE 8.1. The Edit applet viewed by appletviewer.
The x option of the jar tool lets you extract the file's contents. You can use it to re- create the .class files that you deleted:
C:\jdk1.2\ju\ch08>jar xvf edit.jar
extracted: META-INF\MANIFEST.MF extracted: ColorDialog$ButtonHandler.class extracted: ColorDialog$WindowEventHandler.class extracted: ColorDialog.class extracted: Edit$ButtonHandler.class extracted: Edit$ColorSelectHandler.class extracted: Edit$FontSelectHandler.class extracted: Edit.class extracted: FontDialog$ButtonHandler.class extracted: FontDialog$WindowEventHandler.class extracted: FontDialog.class extracted: MyList.class
You can list your directory to see exactly what came back:
){kind=link}
C:\jdk1.2\ju\ch08>dir
Volume in drive C has no label
Volume Serial Number is 2747-15D2
Directory of C:\jdk1.2beta3\ju\ch08
. <DIR> 04-22-98 11:27a .
.. <DIR> 04-22-98 11:27a ..
COLORD~1 JAV 2,448 02-08-98 9:20a ColorDialog.java
EDIT~1 JAV 1,968 02-08-98 10:50a Edit.java
FONTDI~1 JAV 3,667 02-08-98 10:42a FontDialog.java
MYLIST~1 JAV 310 02-08-98 9:19a MyList.java
META-INF <DIR> 04-22-98 12:05p META-INF
EDIT~1 CLA 1,914 04-22-98 12:05p Edit.class
EDIT HTM 159 04-22-98 11:48a Edit.htm
COLORD~1 CLA 1,324 04-22-98 12:05p ÂColorDialog$ButtonHandler.class
COLORD~2 CLA 615 04-22-98 12:05p ÂColorDialog$WindowEventHandler.class
COLORD~3 CLA 2,908 04-22-98 12:05p ColorDialog.class
EDIT$B~1 CLA 1,545 04-22-98 12:05p Edit$ButtonHandler.class
EDIT$C~1 CLA 1,214 04-22-98 12:05p Edit$ColorSelectHandler.class
EDIT$F~1 CLA 1,016 04-22-98 12:05p Edit$FontSelectHandler.class
FONTDI~1 CLA 1,101 04-22-98 12:05p FontDialog$ButtonHandler.class
FONTDI~2 CLA 609 04-22-98 12:05p ÂFontDialog$WindowEventHandler.class
MYLIST~1 CLA 431 04-22-98 12:05p MyList.class
EDIT JAR 11,527 04-22-98 11:36a edit.jar
FONTDI~3 CLA 3,880 04-22-98 12:05p FontDialog.class
17 file(s) 36,636 bytes
3 dir(s) 194,150,400 bytes free
Note that the META-INF directory is created. This directory contains a single manifest file named MANIFEST.MF. The manifest file identifies each file in the JAR file, the digest algorithm used to calculate a digest of the file, and the file's digest value. Listing 8.2 provides an example manifest file.
Manifest-Version: 1.0 Created-By: Manifest JDK 1.2beta3 Name: ColorDialog$ButtonHandler.class SHA-Digest: w1HOCEWkiOt+ui0IpayJLHasnHQ= Name: ColorDialog$WindowEventHandler.class SHA-Digest: G2HtKJluU0aiT/7tB6YqXaBQea0= Name: ColorDialog.class SHA-Digest: z4qdRsSiiLgDBUAjsAmx02TQzuw= Name: Edit$ButtonHandler.class SHA-Digest: Huerm63Agb8edXJJsafVA623MPs= Name: Edit$ColorSelectHandler.class SHA-Digest: IZTp5mlHM8ar5zMHQwzDcN+tkuo= Name: Edit$FontSelectHandler.class SHA-Digest: Ez6+lfCLTC6UvJW+0QIZo6uBkMc= Name: Edit.class SHA-Digest: v2/cnmrXXlH1LsOx4kcAB4BN0jE= Name: FontDialog$ButtonHandler.class SHA-Digest: FrMHhW4wSQeywVXTQ7CjOnIi+yk= Name: FontDialog$WindowEventHandler.class SHA-Digest: Z4mmLOnJcgS2+XA1CWx1ImYkYV8= Name: FontDialog.class SHA-Digest: urXQWWNi9bd842Wq3lMHFZKO+tQ= Name: MyList.class SHA-Digest: yH75rAxTz5Lbesv/g0Tqll5QKdU=
Delete the .class files and the META-INF directory before going on to the next section.
The next thing that we're going to do is to digitally sign the edit.jar file. Chapter 3, "The Extended Java Security Model," provides an introduction to digital signatures, but we'll briefly review their use here.
A digital signature is a value that is computed from an object, such as an applet file, using a secret key. It indicates that the person who holds the secret key has verified that the contents of the object are correct and authentic.
Digital signatures often use public-key encryption algorithms--a private key is used for encryption, and a public key is used for decryption. To sign an object, the signer first calculates a digest of the object using a message digest algorithm, such as MD5. The digest serves as a fingerprint for the object. The digest is then encrypted using the private key of a public/private key pair to produce the object's digital signature.
The signature of a signed object is verified by decrypting the signature using the signer's public key. This produces a digest value. The object's digest is then calculated and compared to the decrypted digest value. If the calculated digest value and the decrypted digest values match, the signature is verified. Refer to Figure 3.14 in Chapter 3 for an illustration of this process.
Before we can sign an applet, we need to create a public/private key pair and make it available to the jarsigner tool. We'll use the keytool to create a keystore with the public/private key pair. A keystore is a database of keys and digital certificates that authenticate the values of the public keys. You'll learn to use the keytool to work with digital certificates later in this chapter in the section "Working with Certificates."
NOTE: The keytool and jarsigner tools of JDK 1.2 replace the javakey tool of JDK 1.1.
Keystore entries are associated with the identities of the subjects (people, organizations, software processes, and so on) to which a particular key belongs. These identities are referenced using aliases. For example, you might use the alias "John" to refer to John Doe's public key, "abc" to refer to the public key of the ABC Corporation, or "Me" to your own public and private keys. Aliases are case-insensitive. This means that "me", "Me", and "ME" are equivalent.
You generate a public/private key pair for yourself using the -genkey command of keytool. For example, the following command generates a key pair for the alias "Me" in the keystore "MyStore":
keytool -genkey -alias "Me" -keystore "MyStore"
The keytool then prompts you to enter a password for the keystore:
Enter keystore password: MyPassword
Enter a password, and then keytool prompts you for the following additional information:
What is your first and last name? [Unknown]: Jamie Jaworski What is the name of your organizational unit? [Unknown]: Software Development What is the name of your organization? [Unknown]: Jaworski & Associates What is the name of your City or Locality? [Unknown]: San Diego What is the name of your State or Province? [Unknown]: California What is the two-letter country code for this unit? [Unknown]: US Is <CN=Jamie Jaworski, OU=Just Me, O=Jaworski & Associates, L=San Diego, S=California, C=US> correct? [no]: yes
Finally, you are prompted to enter a password for your private key:
Enter key password for <Me>
(RETURN if same as keystore password):
I showed how I filled in this information. You would enter your own information, of course. This information is used to associate an X.500 distinguished name with the alias. The distinguished name is used as part of X.509 digital certificates. The following distinguished name subparts are supported:
This information can be supplied directly with the -dname option.
The last password is separate from the keystore password and is used to access the private key of the public key pair. This password can be specified directly using the -keypass option. If the password is not specified, the keystore password is used. The -keypasswd command is used to change this password.
The -keyalg option may be used to specify the algorithm used to generate the key pair.
NOTE: If the -keystore option is not supplied, keytool generates a keystore named .keystore that is stored in the directory specified by the user.home system property.
Currently, only the National Institute of Standards and Technology (NIST) Digital Signature Standard (DSA) key pair-generation algorithm is supported.
The -genkey command automatically generates a self-signed X.509 digital certificate for the key pair. The -sigalg option may be used to specify a signature algorithm. Currently, only DSA is supported. The -validity option may be used to specify the number of days for which the certificate associated with the key pair is valid. If this option is not used, the certificate is valid for 90 days.
[begNOTE: Make sure that you create a keystore of your own before going on to the next section.
Now that you have created a keystore with your public and private keys, you can use the jarsigner tool and your private key to sign a JAR file. The jarsigner tool is used for both signature generation and signature verification. We'll cover signature generation in this section and signature verification in the next section.
To sign a JAR file, you enter a jarsigner command in the following form:
jarsigner -keystore keystore -storepass storePassword -keypass keyPassword JARFileName alias
The parameters to this command are as follows:
Additional command parameters are available for the jarsigner command. Use jarsigner -help to obtain a description of these parameters.
I used the following command to sign the edit.jar file:
jarsigner -keystore MyStore -storepass MyPassword -keypass MyPassword edit.jar Me
If the -keystore option is not specified, the default (.keystore) keystore is used.
Signing a JAR file causes the file to be updated as follows:
The signature file identifies each file in the JAR file, the digest algorithm used in the signing process, and a digest value. The digest value is the digest computed from the file's entry in the manifest file. Listing 8.3 provides an example signature file.
Signature-Version: 1.0 SHA1-Digest-Manifest: Tskq+b1DaL4RUZxFfDGGyNkTTSY= Created-By: SignatureFile JDK 1.2beta3 Name: ColorDialog$ButtonHandler.class SHA1-Digest: 81+YE73yybQfZLZVz4dZxERJNio= Name: Edit$FontSelectHandler.class SHA1-Digest: y1/rJWyOTC+joWOnJM6ZL9fYlnI= Name: FontDialog$ButtonHandler.class SHA1-Digest: IzZObN+lcU8F1UN0SE8M7PR9tP8= Name: FontDialog$WindowEventHandler.class SHA1-Digest: O2L7SWIGmBGqVcFXz6j/dSKg2pw= Name: MyList.class SHA1-Digest: IMKvGp/HqIdw/6jxjUd+CtLMAmA= Name: Edit.class SHA1-Digest: N3l2zs8HBLOmLkcIA5MAs/xXC4A= Name: FontDialog.class SHA1-Digest: AGiOIM3EjO0RxwY/NRVkUrn8RuM= Name: ColorDialog$WindowEventHandler.class SHA1-Digest: yGf1SzyPh/AKEozcQK60du0Auig= Name: ColorDialog.class SHA1-Digest: hOJAXgIblOMG0tREBAcmH4Aqe6s= Name: Edit$ColorSelectHandler.class SHA1-Digest: 5iY/2gP4j64FTrrlPm1KEWEW/Q8= Name: Edit$ButtonHandler.class SHA1-Digest: 1jKW3bcg9iz9j36ozAtq1WdpoDQ=
The signature block file contains the signature of the signature file and a certificate that authenticates the public key corresponding to the private key used in the signature generation. The signature block file is a binary file.
NOTE: By default, jarsigner uses the SHA-1 digest and DSA signature algorithms to sign and verify JAR files. Other digest and signature algorithms may be installed and used instead of SHA-1 and DSA.
NOTE:A JAR file may have multiple signers. Each signer signs the JAR file in succession.
The jarsigner tool is also used to verify the signature of a signed JAR file. This is accomplished using the -verify option. The following jarsigner command form is used:
For example, the following command verifies the signature of edit.jar:
jarsigner -verify edit.jar
If the signature is valid, jarsigner produces the following output:
jar verified.
If the signature is invalid, jarsigner responds with an exception identifying why the failure occurred:
jarsigner: java.util.zip.ZipException: invalid entry size (expected 900 but got 876 bytes)
The jarsigner signature verification process is optimized for performance. This process consists of the following:
Any error encountered in the verification process results in the generation of a security exception.
The signing of JAR files provides the basis for developing an applet security policy. JAR files that are received from trusted sources whose signatures can be verified may be given greater privileges than JAR files that are unsigned or from an untrusted source. Chapter 3 covers the specification of a custom security policy. In this section, we'll show how to develop an applet security policy based on digital signatures.
Listing 3.1 in Chapter 3 shows the ReadFileApplet, which generates a security exception as the result of the applet trying to read a user's AUTOEXEC.BAT file. In this section, we'll develop a trusted version of ReadFileApplet that will successfully read your AUTOEXEC.BAT file without generating a security exception.
Copy the ReadFileApplet.java and ReadFileApplet.htm files from your ch03 directory to your ch08 directory, and compile ReadFileApplet.java. This produces two class files: ReadFileApplet.class and ReadFileApplet$ButtonHandler.class. Create a ReadFileApplet.jar file using the following command:
jar cf ReadFileApplet.jar ReadFile*.class
Now edit the ReadFileApplet.htm file to include the ReadFileApplet.jar file in an ARCHIVE attribute, as shown in Listing 8.4.
<HTML> <HEAD> <TITLE>An Applet that reads local files</TITLE> </HEAD> <BODY> <H1>An Applet that reads local files.</H1> <APPLET CODE="ReadFileApplet.class" ARCHIVE="ReadFileApplet.jar" HEIGHT=300 WIDTH=600> <PARAM NAME="fileName" VALUE="C:\AUTOEXEC.BAT"> Text displayed by browsers that are not Java-enabled. </APPLET> </BODY> </HTML>
NOTE: You may need to create an AUTOEXEC.BAT file for use in the example, if you don't have one already.
Now delete the ReadFileApplet.class and ReadFileApplet$ButtonHandler.class files and run the ReadFileApplet in appletviewer as follows:
appletviewer ReadFileApplet.htm
When you click the Read Local File button, appletviewer will generate a security exception, as shown in Figure 8.2.
FIGURE 8.2. Appletviewer generates a security exception when trying to run an untrusted applet.
Now we'll sign the applet and create a security policy that will trust the applet to read your AUTOEXEC.BAT file. Sign the applet using the keystore that you generated earlier in this chapter:
jarsigner -keystore MyStore -storepass MyPassword -keypass MyPassword ReadFileApplet.jar Me
Substitute your keystore, passwords, and alias, as necessary.
Next, create the policy file shown in Listing 8.5 and save it as my.policy in your ch08 directory. This policy specifies that the keystore "MyStore" should be used for signature verification. It grants any code signed by "Me" permission to read the AUTOEXEC.BAT file. Substitute your keystore and alias for "MyStore" and "Me". For more information on security policy specification, refer to Chapter 3.
Now use appletviewer to run ReadFileApplet with the new policy:
The -J option passes the -D option to the java interpreter. The -D option sets the java.policy property to my.policy.
Now click the Read Local File button. The appletviewer displays your AUTOEXEC.BAT file, as shown in Figure 8.3.
FIGURE 8.3. The ReadFileApplet is trusted to read your AUTOEXEC.BAT file.
In the previous example, you worked with JAR files that you signed yourself. You'll also create JAR files that you'll distribute to your users. As a user, you'll use JAR files signed by other trusted developers. In this section, you'll learn how to export digital certificates so that they can be used by others to verify the signatures of your JAR files. You'll also learn how to import the digital certificates of others.
A digital certificate is an object (file or message) signed by a certification authority that certifies the value of an person's public key. The X.509 certificates of the International Standards Organization are a popular digital certificate format. These are the certificates supported by the keytool.
NOTE: Digital certificates are introduced in Chapter 3.
The keytool allows you to import certificates that are created and signed by others. These certificates verify the public keys of other individuals. The keytool also allows you to export certificates that can be imported by others. We'll cover certificate exporting in the next section, and certificate importing in the section after that.
When you generate your public/private key pair, keytool generates a self-signed certificate for your public key. You can export this certificate using the -export command. This command is of the following form:
keytool -export -keystore keystore -alias alias -file fileName
You must substitute appropriate values for keystore, alias, and fileName.
For example, the following exports my self-signed certificate to the file MyCert:
keytool -export -keystore MyStore -alias Me -file MyCert
The command prompts me for a password and then tells me the status of the export:
Enter keystore password: MyPassword Certificate stored in file <MyCert>
I can now give this certificate to others so that they can import it into their keystores.
The -csr command is used to create a certificate signing request (CSR). The output of this command is a file containing certificate information that is to be provided by a certification authority. The certification authority signs a certificate with its private key that attests to the validity of your public key. A certification authority is a party that is trusted by the public to verify the public keys of others. You can import the certificate received from the certification authority, and you can also distribute it to others. The format of the -csr command is as follows:
keytool -csr -keystore keystore -alias alias -file fileName
For example, the following creates a CSR in the file MyCSR:
keytool -export -keystore MyStore -alias Me -file MyCSR
The command prompts you for a keystore password.
In order to use the certificates of others, you must import them into your keystore as follows:
keytool -import -keystore keystore -alias alias -file fileName
The file specified by fileName contains the certificate to be imported.
The following command imports the certificate contained in the MyCert file into the OtherStore keystore, giving it the alias Jamie:
keytool -import -keystore OtherStore -alias Jamie -file MyCert
The command prompts you for a password:
Enter keystore password: NewPassword
Then it generates the following type of output:
Owner: CN=Jamie Jaworski, OU=Software Development, O=Jaworski & Associates, L=San Diego, S=California, C=US Issuer: CN=Jamie Jaworski, OU=Software Development, O=Jaworski & Associates, L=San Diego, S=California, C=US Serial Number: 353e7a26 Valid from: Wed Apr 22 16:15:50 PDT 1998 until: Tue Jul 21 16:15:50 PDT Â1998 Certificate Fingerprints:
MD5: 70:BE:34:E8:D0:5A:A1:87:74:23:D4:81:0F:EC:AD:95
SHA1: D9:61:50:41:8C:47:75:35:D8:3A:C2:72:B1:44:A1:64:18:85:63:AB Trust this certificate? [no]:
Finally, keytool asks you whether or not to trust the certificate. You should only trust the certificates of those individuals that you trust.
The -list command lists the contents of the keystore or of a single entry.
For example, the following lists all entries in MyStore:
keytool -list -keystore MyStore Enter keystore password: MyPassword Your keystore contains 1 entry: me, Wed Apr 22 16:15:59 PDT 1998, keyEntry, Certificate MD5 Fingerprint: Â70:BE:34:E8:D0:5A:A1:87:74:23:D4:81:0F:EC:AD:95
To list a single entry, use the -alias option.
The -delete command deletes an alias from a keystore. It is used as follows:
keytool -delete -keystore keystore -alias alias
The -printcert command displays a certificate that is stored in a file. The command
keytool -printcert -file MyCert
generates the following output:
){kind=link}
){kind=link}
Owner: CN=Jamie Jaworski, OU=Software Development, O=Jaworski & ÂAssociates, L=San Diego, S=California, C=US
Issuer: CN=Jamie Jaworski, OU=Software Development, O=Jaworski & ÂAssociates, L=San Diego, S=California, C=US
Serial Number: 353e7a26
Valid from: Wed Apr 22 16:15:50 PDT 1998 until: Tue Jul 21 16:15:50 PDT Â1998
Certificate Fingerprints:
MD5: 70:BE:34:E8:D0:5A:A1:87:74:23:D4:81:0F:EC:AD:95
SHA1: D9:61:50:41:8C:47:75:35:D8:3A:C2:72:B1:44:A1:64:18:85:63:AB
Finally, the -help command can be used to obtain a list of all the commands supported by keytool. The command
keytool -help
generates the following output:
KeyTool usage:
-csr [-v] [-alias <alias>] [-sigalg <sigalg>]
[-file <csr_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
-delete [-v] -alias <alias>
[-keystore <keystore>] [-storepass <storepass>]
-export [-v] [-alias <alias>] [-file <cert_file>]
[-keystore <keystore>] [-storepass <storepass>]
-genkey [-v] [-alias <alias>] [-keyalg <keyalg>]
[-keysize <keysize>] [-sigalg <sigalg>]
[-dname <dname>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>]
-help
-import [-v] [-noprompt] [-alias <alias>]
[-file <cert_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
-keyclone [-v] [-alias <alias>] -dest <dest_alias>
[-keypass <keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
-keypasswd [-v] [-alias <alias>]
[-keypass <old_keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-list] [-v | -rfc] [-alias <alias>]
[-keystore <keystore>] [-storepass <storepass>]
-printcert [-v] [-file <cert_file>]
-selfcert [-v] [-alias <alias>] [-sigalg <sigalg>]
[-dname <dname>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>]
-storepasswd [-v] [-new <new_storepass>]
[-keystore <keystore>] [-storepass <storepass>]
The JDK 1.2 documentation describes all the commands and options of keytool.
The security tools covered in this chapter are implemented in terms of the Security API, which consists of the following five packages:
The java.security package is the core Security API package. It provides the classes and interfaces that support encryption and the computation of message digests and digital signatures. This package also provides key generation and management support, and the classes used in security policy implementation. The java.security.acl package consists of interfaces that can be used to implement access control policies. The java. security.cert package provides support for X.509 certificates. The java.security.interfaces package defines interfaces that are used to access the National Institute of Standards and Technology (NIST) Digital Signature Algorithm. The java.security.spec package provides algorithm-independent and algorithm-dependent classes that are used for keys and other algorithm parameters. The java.security.cert and java.security.spec packages are new to JDK 1.2.
In this chapter, you learned how to develop applets that extend the bounds of the applet sandbox and use new JDK 1.2 security features. You learned how to package your applets as Java Archive (JAR) files and how to digitally sign these files. You learned how to configure your runtime environment to use trusted applets. You also learned about digital certificates and how they are used to support applet security. You were introduced to the JDK 1.2 security tools and learned about the JDK 1.2 Security API. In the next chapter, you'll learn how to write window applications in Java.
© Copyright, Macmillan Computer Publishing. All rights reserved.