Modifying Keystore Entries The keytool

The new global password for the keystore. If you do not specify this value, you will be prompted for it, which is more secure. Finally, you can get a summary of all commands with this command: −help Print out a summary of the usage of keytool .

10.2.10 Using Certificates from Netscape

If you have certificates that youve used in your Netscape browser, you can export them and use them with your Java programs as well. This is accomplished using the PKCS12 keystore format. As we mentioned, this is presently a one−way operation: you can read a PKCS12 keystore and export a certificate from it, but you cannot create or modify a PKCS12 keystore. The steps to accomplish this are as follows: Export your certificate from Netscape. The exact details of this vary by Netscape release, but under the Tools menu, select Security Info in Netscape 6, its called Personal Security Manager. Select your certificate, and then export it. You can export it to any file; the normal extension to use for the file is .p12. 1. Read the keystore. If you exported the certificate to a file called sdocer.p12, this command will list the certificate: piccolo keytool −list −keystore sdocer.p12 −storetype pkcs12 Enter keystore password: Keystore type: pkcs12 Keystore provider: SunJSSE Your keystore contains 1 entry: scott oakss verisign, inc. id, Sat Dec 30 18:39:54 EST 2000, keyEntry, Certificate fingerprint MD5: 4D:09:08:11:95:FC:33:1C:6D:B1:15:2D:C3:FB:87:F8 2. Export and import the certificate, if desired. If you use the export command to export the certificate, you may import it into a JKS or JCEKS keystore. Besides integrating it into a single source, this allows you to make modifications to the entry, such as changing its password and alias. 3.

10.3 The Key Management API

The keytool gives us the ability to create keys, obtain certificates, and so on. Now well turn our attention to using the key management facilities programatically: if you need to create a digital signature, youll use the key management API to locate the correct key. Similarly, you may choose to store secret keys for data encryption in the keystore. The key management API allows us to read and write keystores and their entries. In addition, the implementation of keytool has certain limitations: it cannot create entries that store secret keys, and it is difficult to share the keys in a keytool database among a widely dispersed group of people like all the employees of XYZ Corporation. We can, however, use the key management API to create a key management system that has whatever features we require. That framework is the ultimate goal of the following sections. First, however, lets take a look at the classes 188 that make up the key management API. We begin with the notion of the identity to whom a key belongs. In Javas key management model, the association between a key and its owner is application−specific, but it is generally modeled on the Principal interface.

10.3.1 Principals

Classes that are concerned with identities and key management in the Java security package generally implement the Principal interface java.security.Principal : public interface Principal Provide an interface that supports the notion of an entity. In particular, principals have a name, but little else. There is a single method that implementors of the Principal interface must implement: public String getName Return the name of the principal. This is typically an X.500 distinguished name, but it may be any arbitrary name. The only idea that the Principal interface abstracts is that principals have a name. The Java documentation states that a principal is anything that can have an identity, but dont be confused by that statement; the word identity is being overloaded in this context. There is an Identity class that implements the Principal interface, but there are classes implementing the Principal interface that are unrelated to the Identity class. In addition, although it is not officially deprecated, the Identity class is obsolete; it was used primarily in Java 1.1. Further confusion about this interface can arise because there are two Principal types in Java 2: the java.security.Principal interface and the org.omg.CORBA.Principal class. These are unrelated, and well discuss only the java.security.Principal interface throughout this book. The name that is stored in a principal is often an X.500 distinguished name DN. That is particularly true when a principal is used in certain certificates like X509 certificates; it is not an absolute requirement by any means. There are other methods listed in the Principal interface −− namely, the equals , toString , and hashCode methods. Theres no reason for those methods to be listed in the Principal interface since every class already inherits those methods from the Object class. If you implement the Principal interface, the only method you must implement is the getName method. You should make sure that the other methods of the Principal interface are implemented correctly −− but you should ensure these methods of the Object class are implemented correctly for all your classes, not just those that implement the Principal interface.

10.3.2 The KeyStore Class

The class that implements the keystore is the KeyStore class java.security.KeyStore : public class KeyStore Represent a set of private keys, aliases entities, and their corresponding certificates. A keystore object is typically one that has been read in from disk; that is, the KeyStore object is an in−memory representation of the keystore file. Chapter 10. Key Management The KeyStore class is an engine class; there is a corresponding KeyStoreSpi class that you can use to write your own keystore more about that a little later. As weve seen, the Sun−supplied algorithms for this engine are JKS, JCEKS, and PKCS12. Instances of the KeyStore class are predictably obtained via this method: public static final KeyStore getInstanceString type public static final KeyStore getInstanceString type, String provider Return an instance of the KeyStore class that implements the given algorithm, supplied by the given provider, if applicable. If you do not want to hardwire the name of the keystore algorithm into your application, you may use this method to return the string that should be passed to the getInstance method: public static final String getDefaultType Return the default keystore algorithm for the environment. This value is obtained by looking for a property called keystore.type in the java.security file; Suns version of Java sets the default value of this string to JKS. When the keystore object is created, it is initially empty. Although the getInstance method has constructed the object, it is not expected that the objects constructor will read in a keystore from any particular location. The interaction between the keystore object and the keytool database comes via these two methods: public final void loadInputStream is, char[] password Initialize the keystore from the data provided over the given input stream. The integrity of the keystore is protected by using a message digest: when the keystore is stored, a message digest that represents the data in the keystore is also stored. Before the digest is created, the password is added to the digest data; this means that the digest cannot be recreated from a keystore without knowledge of the password. This allows you to detect whether the keystore has been tampered with. The password for this method can be null , in which case the keystore is loaded and not verified. Its somewhat misleading to call this parameter a password, although thats what the javadoc calls it, and thats the term used by keytool . If you pass null for the password, youll always be able to read the keystore. Remember that a different password is used to decrypt the private keys in the keystore, so this isnt a security hole: if you dont have the password, you will be able to read only public certificates. If you use an incorrect password, an IO exception is thrown. You cannot require a password for the load method to succeed since the Sun implementation of the Policy class calls this method without a password when it constructs the information needed for the access controller. You may, of course, provide your own implementation of the Policy class that requires a password. If the class required to support the underlying message digest is not available, a NoSuchAlgorithmException is thrown. An error in reading the data results in an IOException , and generic format errors in the data result in a CertificateException . public final void storeOutputStream os, char[] password