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
−storepass storepass −storetype storetype
It also supports these options: −keyalg AlgorithmName
Use the given algorithm to generate the key pair. The default for this option is DSA; you must use an algorithm name that is supported by a security provider that you have installed.
−keysize keysize Use the given keysize to initialize the key pair generator. The default value for this option is 1024;
you must use a key size that is supported by the key algorithm you want to use.
−sigalg signatureAlgorithm Specify the signature algorithm that will be used to create the self−signed certificate; this defaults to
SHA1withDSA , which is supported by the Sun security provider. If youve specified a different key
algorithm e.g., RSA, youll have a different default signature algorithm e.g., SHA1withRSA
. −validity nDays
Specify the number of days for which the self−signed certificate should be valid. The default value for this option is 90 days.
The key entry that is created in this manner has the generated private key. In addition, the public key is placed into a self−signed certificate; that is, a certificate that identifies the holder of the public key using the
distinguished name argument and is signed by the holder of the key itself. This is a valid certificate in all senses, although other sites will probably not accept the certificate since it was not issued by a known CA.
However, the self−signed certificate can be used to obtain a certificate from a known CA, as well see in just a bit.
Heres how you use this command to create a key entry:
piccolo keytool −genkey −alias sdo −keyalg RSA Enter keystore password:
What is your first and last name?
[Unknown]: Scott Oaks
What is the name of your organizational unit?
[Unknown]: JSD
What is the name of your organization?
[Unknown]: Sun Microsystems
What is the name of your City or Locality?
[Unknown]: NY
What is the name of your State or Province?
[Unknown]: NY
What is the two−letter country code for this unit?
[Unknown]: US
Is CN=Scott Oaks, OU=JSD, O=Sun Microsystems, L=NY, S=NY, C=US correct?
[no]: yes
Enter key password for sdo
RETURN if same as keystore password:
At this point, we now have an entry for sdo
in the keystore. That entry has a self−signed certificate; note that we had the tool prompt us for all the entries that comprise the DN rather than attempting to type it all in on the
command line. We also chose to generate an RSA key pair since in later chapters, well want to use this key with SSL algorithms.
Be careful in selecting the values for the DN. Certain characters, such as commas, will become quoted. Unfortunately, quoted strings cannot be verified by other CAs. Hence, if you see quotes in the generated DN,
reenter the information so that it is not quoted.
While it is possible for a keystore to hold a key entry that stores a secret key, keytool
itself does not support creating such entries. Those entries can only be created programatically.
10.2.3 Generating a Certificate Request
If we want someone to accept the key we just generated, we need to obtain a certificate from a known CA. Known in this context means that we must already have the root certificate of the CA e.g., in the cacerts
file.
Which CA you choose is a complicated decision. As weve mentioned, CAs will take different steps to verify the identity of the person or organization to whom they issue a certificate. The certificate they issue will be
verified by a different root certificate as a result: if you want a simple, free certificate with little verification of your identity, you can get a Thawte Personal Certificate. If you want something with more assurance as to
your identity, you can pay for an SSL or developers certificate from Thawte. That process takes longer since Thawte will do an extensive check to make sure that you are who you represent yourself to be.
So the issue here is to whom you will present your certificate and what level of verification they will accept. For our testing purposes, the Thawte Personal Certificate will do just fine; if youre presenting a certificate to
a developers association, they may require a Verisign Class 3 certificate, and so on. Of course, the converse of this relationship should also hold: when someone presents you with a certificate, you should check who
issued it and what type it is in order to determine how careful the CA was in supplying the certificate.
In order to obtain a certificate from a CA, you must first generate a certificate signing request CSR. The CSR contains the distinguished name and public key for a particular alias and is signed using the private key
of the alias; the CA can then verify that signature and issue a certificate verifying the public key. CSRs are generated with this option:
−certreq Generate a certificate signing request. This command supports the following global options:
−alias alias −keypass keypass
−keystore keystore −storepass storepass
−storetype storetype −v
It also supports these options: −sigalg signatureAlgorithm
Use the given algorithm to sign the CSR. The CSR must be signed by an algorithm the CA expects, Chapter 10. Key Management
and the algorithm must be consistent with the key being verified. The default algorithm will be based on the type of key held by the alias.
−file outputFile Store the CSR in the given file. The format of the CSR is defined in PKCS10. The default is to write
the CSR to System.out
. Heres how to generate the CSR:
piccolo keytool −certreq −alias sdo −file sdoCSR.cer Enter keystore password:
Enter key password for sdo:
If you used the same password for the keystore and the key itself, you are only prompted once for the password.
Once you have the CSR in a file, you must send it to the CA of your choice. Different CAs have different procedures for doing this, but all of them will send you back a certificate they have signed that verifies the
public key you have sent to them. For simple testing, the quickest way to proceed is to register for a personal certificate at http:www.thawte.com. Once youve received email from Thawte and continued with the
registration process, you will arrive at https:www.thawte.comcgipersonalcertenroll.exe; make sure to follow the section entitled Developers of New Security Applications ONLY. Dont be dissuaded by the
statements that you should only follow that link if you know what youre doing; thats the section on their web site that allows you to paste in a CSR. However, if you do this you must generate the initial keypair with a
special value in the CN field; Thawte will tell you what that value is when you follow the links to request the certificate.
No matter which CA you use, youll eventually be sent back the certificate, which will be in RFC 1421 format.
10.2.4 Importing a Certificate
When the response from the CA comes, we must save it to a file from which we can import it. In order to import the certificate, we must already have the root certificate in our list of trusted certificate authorities, or
we must be prepared to accept the root certificate that keytool
presents to us. To import the certificate, use this command:
−import Import a certificate into the database. This command either creates a new certificate entry or imports a
certificate for an existing key entry. This command supports the following global options: −alias alias
−keypass keypass −keystore keystore
−storepass storepass −storetype storetype
−v
It also supports these options: −file inputFile
