InfoCenter Home > 5.5.6.3.3: Administering trusted certificatesAdministrators use the Keytool utility to perform tasks that apply the keystore database or to the keystore entries: key pairs and trusted certificates. Administering a keystore database discusses the tasks that apply to the keystore database; Administering key pair entries discusses tasks that only apply to key pair entries, and Administering both certificate and key pair entries discusses the tasks that are common to both entry types. Understanding how the Keytool utility works provides conceptual information about the Keytool utility and Options used with the keytool command provides reference information for the options used with the keytool command. This article discusses the administrative tasks that apply only to managing trusted certificate entries in a keystore:
Managing trusted certificatesWhen the -genkey option is used with the keytool command to generate a new key pair entry, the public key is automatically wrapped into a self-signed certificate. A self-signed certificateis one in which the same entity acts as both the issuer (signer) of the certificate and as the authentication subject of the certificate. This self-signed certificate, containing the public key, takes the first position in the certificate chain that is associated with the corresponding private key. Further authentication can be obtained by submitting a certificate signing request (CSR) for the self-signed certificate to a certificate authority (CA). Adding a trusted certificate to the cacerts fileCombine the -trustcacerts option with the -import option when the keytool command is issued to add a new certificate to the list of trusted certificates (the cacerts file). See Generating a key pair entry for an example of how the -trustcacerts option is combined with the keytool command. See Security considerations for importing trusted certificates for security considerations related to trusted certificates. Regenerating a self-signed certificateCertain circumstances, for example, when an employee transfers to a different department within the same company, can necessitate the regeneration of a self-signed certificate in order to assign the same key pair to a different X.500 Distinguished Name. The procedure for this task follows:
The certificate is stored in the keystore as a single-element certificate chain. It is identified by the specified alias, and it replaces the original (obsolete) entry. The following command is an example combining the -selfcert option with other options: keytool -selfcert -alias PUB900 -keypass r82Rij -dname "cn=Barbara Brown, ou=purchaing, o=IBM c=US" Note that the command must be entered as single line. Multiple lines are used in the example due to space constraints. Also, the values for the -dname option must be specified in the order shown. This command generates a self-signed certificate for which the issuer and the subject are the same entity. The -selfcert option can be combined with the following options:
See Options used with the keytool command for descriptions of these options. Generating a Certificate Signing RequestTo generate a Certificate Signing Request (CSR), issue the keytool command in combination with the -certreq option. The following command is an example combining the -certreq option with other options: keytool -certreq -alias PUB700 -file csrFile This command does the following:
The -certreq option can be combined with the following options:
See Options used with the keytool commandfor a description of these options. Importing certificatesThe -import option reads the certificate from the cert_file file (or from standard input, if no file is given) and stores it in the keystore entry that is identified by the alias. The -import option can be used with the keytool command to import X.509 v1, v2, or v3 certificates and PKCS#7-formatted certificate chains. The data to be imported can be stored in binary encoding format or in printable encoding format (Base64 encoding). If printable encoding format is used, it must adhere to the Internet RFC 1421 standard, as shown: "- - - - -BEGIN CERTIFICATE- - - - -" certificate information- bounded by Begin-End string "- - - - -END CERTIFICATE- - - - -" The following command is an example combining the -import option with other options: keytool -import -alias PUB500 -file foreign.cer -keypass changeit -trustcacerts Note that the command must be entered as single line. This command does the following:
See The cacerts files for more information on how the keytool utility uses the cacerts file. See Security considerations for maintaining the cacerts file for information on keeping the cacerts file secure. The -import option can be combined with the following options:
See Options used with the keytool command for a description of these options. Exporting certificatesThe -export option reads the certificate associated with the specified alias from the keystore and places it in a file, which is supplied by the -file option (or by standard output, if no file is given). If the specified alias is associated with a trusted certificate, the default output is in binary code format. The -rfc option can be added to change the output to printable encoding format (Internet RFC 1421). If the specified alias is associated with a key pair entry, the first certificate in the chain, which authenticates the public key, is returned. The following command is an example combining the -export option other options: keytool -export -alias joebrown -file joebrown.cer This command reads the entry associated with the alias joebrown and places it in binary format into the file named joebrown.cer. A prompt is issued for the keystore password because the -storepass option was not included with the command. The -export option can be combined with the following options:
See Options used with the keytool command for a description of these options. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|