Comparison with Previous Releases Summary

DNs are used by certificate authorities to refer to the entities to whom they supply a certificate. Hence, unlike an alias, the DN for a particular key is the same no matter what keystore it is located in: if I send you my public key, it will have the DN encoded in the public keys certificate. However, nothing prevents me from having two public keys with different DNs I might have one for personal use that omits references to my place of employment. And there is no guarantee that two unrelated individuals will not share the same DN in fact, you can count on this type of namespace collision to occur. The common name CN within a DN is usually the domain name of the organization to which the certificate belongs. In fact, SSL uses this convention to verify the identity of the server to which it connects. Whats in a Name? X509 certificates and many other ANSI standards make use of the idea of a distinguished name usually referred to as a DN. The distinguished name of an individual includes these fields: Common name CN The full common name of the individual. Organizational unit OU The unit the individual is associated with. Organization O The organization the individual is associated with. Location L The city where the individual is located. State S The stateprovince where the individual is located. Country C The country where the individual is located. The DN specification allows other fields as well, although these are the only fields used internally in Java. The organization that is associated with an individual is typically the company the individual works for, but it can be any other organization and of course, you may not be associated with an organization under a variety of circumstances. The idea behind a DN is that it limits name duplication to some extent. There are other people named Scott Oaks in the world, but only one who has a DN of: CN=Scott Oaks, OU=JSD, O=Sun Microsystems, L=NY, S=NY, C=US On the other hand, this is not absolute; there are many nonunique DNs. key entries A keystore may hold two types of entries. The first type of entry is called a key entry. A key entry may hold either an asymmetric key pair private key and public key certificate or a single secret key. If the entry holds a key pair, it may store a chain of certificates: the first certificate always contains the public key of the entity. Other certificates may be present that establish a chain to the root certificate of the CA that issued the entitys certificate. certificate entries A certificate entry contains only a public key certificate; there is no private key associated with this entry. Certificate entries hold a single certificate rather than a chain, and the certificate is self−signed. These certificates are generally the root certificates of certificate authorities that you trust to issue certificates. JKS, JCEKS, and PKCS12 The keystore is an engine within the Java API, and Suns various security providers supply three different algorithms of the keystore. The default algorithm is JKS and is supplied by the security manager within the core API. It is capable of reading and storing key entries and certificate entries; however, the key entries can store only private keys. If you want to use the keystore for secret keys, you must use the JCEKS implementation, which is supplied by the security provider that comes with JCE. The JCEKS keystore can hold either private or secret keys for each key entry. The private keys held by JKS or JCEKS are encrypted. The encryption used by JKS is weaker than that used by JCEKS; it was designed to pass the old export restrictions of the U.S. The JCEKS keystore provides a much stronger encryption. For these two reasons, JCEKS is a preferable keystore; for compatibility reasons the default keystore remains JKS. Both the Java key management API and keytool allow you to specify the algorithm name when operating on a keystore, so you can use either algorithm at any time. However, if you want to change the default algorithm, you can edit the JREHOMElibsecurityjava.security file, find the entry for keystore.type , and change it to read: keystore.type=JCEKS The PKCS12 algorithm does not supply a fully−functional keystore. You can read a keystore in this format and export information such as the encoded certificate from that keystore, but you cannot write or modify a keystore in that format. This format is used to import certificates from your Netscape browser into your Java keystore, as well show a little later. Trusted certificate authorities Suns implementation of Java comes with a set of trusted certificates from known certificate authorities. These certificates are held in JREHOMElibsecuritycacerts, which is itself a keystore. That keystore holds ten certificate entries, each of which is the root certificate of a CA. This keystore should usually be considered read−only: youll use it when you want to verify a certificate that was issued by one of these CAs, but you should not add your own key entries to this keystore. If your enterprise has its own certificate authority, or if you obtain the root certificate from another Chapter 10. Key Management well−known certificate authority, you may choose to install that certificate entry into the list of trusted certificate authorities. Otherwise, this keystore is best left unmodified. The CAs that are present in the cacerts file are listed here. Thawte Personal Basic CA Thawte Personal Freemail CA Thawte Personal Premium CA Thawte Premium Server CA Thawte Server CA Verisign Class 1 CA Verisign Class 2 CA Verisign Class 3 CA Verisign Class 4 CA Verisign Server CA The password for this keystore is changeit. Note that these CAs are the all from the same company. Part of the difference between them is historical Verisign and Thawte used to be different companies, but the more significant difference between them is the degree to which they verify the subject to whom the certificate is issued. You can get a certificate from the Thawte Personal Freemail CA for free and with relatively little information. If you want a certificate from the Verisign Server CA, you must provide a great deal of information which Verisign will go to great lengths to verify, and you must pay for the certificate. As we mentioned in the last chapter, the level at which a particular CA issues a certificate is very important in deciding whether or not you should trust the holder of the certificate.

10.2 The keytool

At an administrative level, keys are managed by keytool , a utility supplied with the JRE. This tool allows you to create new keys, import digital certificates, export existing keys, and generally interact with the key management system. The keytool has only a command−line interface; in this section, well look at the typical commands that add, modify, list, and delete entries in the keystore. Along the way, well see how you can create your own keys and certificates and how to get a valid certificate from an official certificate authority. As we understand the operations provided by keytool , well be poised to understand the underlying Java API that well examine later in this chapter.

10.2.1 Global Options to keytool

Keytool implements a number of global options −− options that are available to most of its commands. Well list these as appropriate for each command, but heres an explanation of what they do: −alias alias Specify the alias the operation should apply to e.g., −alias sdo . The default for this value is mykey. −dname distinguishedName Specify the distinguished name. There is no default for this value, and if you do not specify it on the command line, you will be prompted to enter it when it is needed. Letting keytool prompt you is generally easier since the tool will prompt for the name one field at a time. Otherwise, you must enter the entire name in one quoted string, like this: −dname \ CN=Scott Oaks, OU=JSD, O=Sun Microsystems, L=NY, S=NY, C=US −keypass password Specify the password used to protect the entire keystore. Access to any element in the keystore requires this global password. If this password is not provided on the command line, you will be prompted for it. This is more secure than typing it on a command line or in a script where others might see it. Passwords must be at least six characters long. For certain commands, the password may be omitted. −keystore filename Specify the name of the file that holds the keystore. The default value is HOME.keystore, as described before. −storepass password Specify the password used to protect a particular entrys private key. This is usually not and should not be the same as the global password. There should be a different password for each private key that is specific to that entry. This allows the keystore to be shared among many users. If the password is not provided on the command line, you will be prompted for it, which is the more secure way to enter this password. −storetype storetype Specify the type of keystore that the keytool should operate on. This defaults to the keystore type in the java.security file, which defaults to JKS, the keystore type provided by the Sun security provider. −v Verbose. Print some information about the operations keytool is performing. Now well look at the various commands that are available within keytool , and along the way well build up a keystore that well use in examples in later chapters.

10.2.2 Creating a Key Entry

Well start by creating a key entry that holds a private key and certificate. This is done by the following command, which creates the private key and a self−signed certificate that contains the corresponding public key: −genkey Generate a key pair and add that entry to the keystore. This command supports these global options: −alias alias −dname DN −keypass keypass −keystore keystore