The file containing the certificate that is being imported. The certificate must be in RFC 1421 format. The default is to read the data from
System.in .
The certificate file sent by a CA will contain a certificate chain. The first certificate in the chain will be for the alias itself and will be issued by the certificate authority; the next certificate in the chain
will be for the certificate authority and will be self−signed a root certificate or issued by another certificate authority, and so on until a self−signed certificate is present. While the encoding of the
chain is defined by RFC 1421, the format of the chain itself is often referred to as a Netscape certificate chain or a PKCS 7 certificate chain.
Keytool can read either format; if your CA gives
you a choice of formats, pick either one. −noprompt
Do not prompt the user about whether or not the certificate should be accepted. When this option is present, the certificate is always installed. Otherwise, if the root certificate in the chain is not from a
trusted certificate authority, the user will be prompted whether or not to install the certificate chain.
When you import a certificate from an unrecognized CA, the information contained in that certificate is printed out; this information includes the fingerprint of the certificate and the distinguished names
of the issuer and the principal. Well−known certificate authorities will publish their fingerprints on the Web, in trade papers, and elsewhere. It is very important for you to verify the displayed
fingerprint with the published fingerprint in order to verify that the certificate does indeed belong to the principal named in the certificate.
−trustcacerts Use the cacerts file to obtain trusted certificates from certificate authorities that have signed the
certificate that is being imported. Without this option, no CAs are considered trusted, and the user will always be asked whether or not to accept the certificate unless, of course, the
noprompt option is in
effect. If we saved the response from the CA in the file sdo.cer, heres how wed import it into our keystore:
piccolo keytool −import −file sdo.cer −alias sdo −trustcacerts Enter keystore password:
Certificate reply was installed in keystore
Assuming that the certificate is valid, this imports the new certificate into the keystore. The certificate is invalid if the public key for
sdo does not match the previously defined public key in the database or if the
certificate signature is invalid which would be the case if data in the certificate had been modified in transit. As a result of this command, the state of the
sdo entry has significantly changed:
When we created the key entry, the sdo
entry had a single certificate; that certificate was issued by sdo
. •
After the import command, the sdo
entry has two or more certificates in its certificate chain: the first certificate is issued by the certificate authority and has a principal of
sdo ; the last certificate is the
CAs self−signed certificate. There may be intermediate certificates in this chain. •
10.2.5 Creating a Certificate Entry
Certificate entries in a keystore are always created by importing an existing certificate. The certificate may be the root certificate of a known CA or the internal CA for your enterprise, or it may be a certificate that
verifies the identity of someone with whom you will exchange information. For example, if Im going to send you a digitally signed message, you must have my certificate issued by a CA within your keystore.
Certificate entries are created with the same import command that we just looked at. Lets say that I send you my certificate, and youve saved it to the file fromsdo.cer. Youd import it into your keystore like this:
piccolo keytool −import −alias sdo −file fromsdo.cer Enter keystore password:
Owner: EmailAddress=scott.oakssun.com, CN=Thawte Freemail Member Issuer: CN=Personal Freemail RSA 2000.8.30, OU=Certificate Services, O=Thawte,
L=Cape Town, ST=Western Cape, C=ZA Serial number: 3df48
Valid from: Thu Dec 28 22:18:29 EST 2000 until: Fri Dec 28 22:18:29 EST 2001 Certificate fingerprints:
MD5: BE:E1:5C:54:E8:60:D4:09:7D:D8:C5:16:56:CA:72:5A SHA1: 4F:22:2D:E9:1C:7D:A6:D6:E4:1B:92:A5:CC:BE:DC:E8:DD:65:F6:45
Trust this certificate? [no]: yes
Certificate was added to keystore
Note that in this example, we havent used the cacerts file to verify the certificate automatically and since the given CA doesnt exist in the cacerts file, that would fail anyway. This causes
keytool to print out the
certificate information; you should examine and verify its fingerprint before deciding whether or not to trust the certificate.
10.2.6 Modifying Keystore Entries
There is no way to modify a certificate entry in the keystore. You may delete an existing entry and add a new one if required.
There is one command that can modify the data within a key entry: −selfcert
Change the certificate chain associated with the target key entry. Any previous certificates including ones that may have been imported from a valid certificate authority are deleted and replaced with a
new self−signed certificate; this certificate can be used to generate a new CSR. The public and private keys associated with the alias are unchanged, but you may specify a new value for the DN on the
command line. Hence, one use for this command is to change the DN for a particular entry before generating a CSR request.
This command supports the following global options: −alias alias
−dname DN −keypass keypass
−keystore keystore −storepass storepass
−storetype storetype
It also supports these options: −sigalg algorithmName
Use the given algorithm to generate the signature in the self−signed certificate. −validity nDays
The number of days for which the self−signed certificate is valid. The default is 90 days. The −keyclone command is often used with this command, which can create a copy of the original entry
before the DN is changed:
−keyclone Clone the target entry. The cloned entry will have the same private key and certificate chain as the
original entry. This command supports the following global options: −alias alias
−keypass keypass −keystore keystore
−storepass storepass −storetype storetype
−v
It also supports these options: −dest newAlias
The new alias name of the cloned entry. If this is not specified, you will be prompted for it. −new newPassword
The new password for the cloned entry. If this is not specified, you will be prompted for it. Again, it is more secure to respond to a prompt because the password is masked than it is to supply it in plain
text at the command line.
To change the password associated with a particular key entry, use this command: −keypasswd
Change the password for the given key entry. This command supports the following global options: −alias alias
−keystore keystore −storepass storePassword
−storetype storetype −keypass originalPassword
It also supports this option: −new newPassword
Specify the new password for the entry. If this option is not supplied, you will be prompted for the new password.
Changing the password is one way to migrate entries from a JKS to a JCEKS keystore since you can specify a Chapter 10. Key Management
