Managing Certificates
The best way to feel comfortable with certificates is to actually start working with them. J2SE environment supports keystore files to store certificates and includes keystore file jre-homelibsecuritycacerts to hold a number of trusted certificates. We talk more about how to work with Java keystore files shortly. The MS-Windows operating system also bundles a number of different types of certificates within its certificate store. These certificates can be examined through Windows tools.
Windows Certificate Store
Let us explore the certificates stored on a Windows 2000 machine. We will go through the following sequence of steps: pick a specific certificate, export it into a certificate file and examine those files.
Go to the Windows Control Panel by selecting Start → Settings → Control Panel. Click on the Internet Options icon. This displays the Internet Properties panel. Click the Content tab. The resulting panel has a section on Certificates, as shown in screen-shot #1 in Figure 4-2. Click the Certificates button to bring up the Certificates panel (screen-shot #2).
Figure 4-2. Exporting a Certificate from Windows Certificate Store.
This panel shows several different certificates, grouped together in different categories. It also allows a new certificate to be imported from a file, an existing one to be exported, removed or viewed. We will pick a certificate under the tab Intermediate Certification Authorities, the one highlighted in screen-shot #2. View the details of this certificate. Notice that this certificate is signed by another certificate and the signing certificate is also available in the certificate store.
To export this certificate, click the Export button. This brings up a wizard (screen-shot #3), taking you through various steps in exporting the certificate, as shown in remaining screen-shots of Figure 4-2.
As you can see in screen-shot #4, you can export the certificate in one of the three formats: (i) DER encoded binary X.509; (ii) Base-64 encoded X.509; and (iii) Cryptographic Message Syntax Standard – PKCS#7 Certificates. First select (i) and save the exported certificate in the file verisign.cer. Next, after restarting the wizard, select (ii) and save the certificate in file verisignb64.cer. Finally, save all the certificates, known as certification path, selecting (iii) and including all certificates in the certification path, in file verisign.p7b.
Files verisign.cer and verisign.p7b are binary files. File verisignb64.cer is an ASCII file and can be displayed on screen. Let us examine its contents.
C:>type verisignb64.cer
-----BEGIN CERTIFICATE-----
MIIDZjCCAs+gAwIBAgIQDYtP7qrSGFv0dWqdKeF/+zANBgkqhkiG9w0BAQIFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC
eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1K
sm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7
wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7v
yds3ashKyAkG5JkCAwEAAaOBtDCBsTARBglghkgBhvhCAQEEBAMCAQYwNQYDVR0f
BC4wLDAqoCigJoYkaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS4xLjEuY3Js
MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZl
cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQBCfA7fjHlMrL8I7E1VL1CJoMVeTi5e
lTKbea1lEQscSlLE1agxIY7eEJtsCMUH5gO558g0eAkJ8rwGQvhajIPRit6qIvXZ
4yHSz2WMBjOwzSCyM80KvT7hncE1qWSwp6UkW+nxaOsTxHw39JRkDZrFvTMX74Mz
oD7lqj6u2HMfrQ==
-----END CERTIFICATE-----
What you see is base-64 encoding of the content in file verisign.cer, encapsulated between marker strings -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.
We use these files later in the chapter, while running the sample programs.
Hopefully, this makes you feel a bit more comfortable handling certificates. Later in this chapter, we learn about keytool, a command line utility to manage Java keystore files. Using this tool, it is possible to import the certificate exported from the Windows certificate store to a Java keystore file. We also learn how to create self-signed and CA signed certificates using Java tools. You can import these certificates to a Windows certificate store using the same Certificates panel. The process to import a certificate into the Windows certificate store is covered in Chapter 9, Web Application Security.
How does one get a CA signed certificate? For this, one needs to generate a Certificate Signing Request or CSR. A CSR is a digital document binding the identity information with the public key. It is sent to a CA to verify the fact that the requestor has the same identity as claimed in the CSR and to issue the certificate to the requestor. The process of CSR generation involves generating a public and private key pair, supplying the identity information and packaging this information in the appropriate format. Note that the private key itself is not part of the CSR.
The actual tools and the process to generate the CSR, submit it to the CA and retrieve the signed certificate depends on the requestor's operating environment and the guidelines specified by the CA. In rest of the section, we go over the steps involved in getting a CA-signed certificate using keytool, a command line utility packaged with J2SE.
Managing Certificates with keytool
You can generate self-signed certificates and manage them with utility keytool. It stores private keys and certificates in a keystore. This is the same keystore we talked about in Chapter 3, Cryptography with Java. The providers bundled with J2SE v1.4 support two different keystore types, JKS, and JCEKS, and provides limited, read-only support for type PKCS12. Types JKS and JCEKS are proprietary to Sun Microsystems and type PKCS12 is defined by PKCS#12 standard. Between types JKS and JCEKS, JCEKS provides better security. Additionally, JCEKS keystore can also hold secret keys, used for symmetric cryptography. By default, keytool uses JKS. We explicitly specify keystore type as JCEKS in our examples.
As we mentioned earlier, you can generate a private and public key-pair and a self-signed X.509 certificate using keytool. The generated key and the certificate are stored in a keystore as a key entry and this entry is identified by an alias. You can subsequently generate a CSR based on the information in this entry and submit the CSR to a CA for obtaining a proper, CA signed certificate. The CA signed certificate is then imported into the keystore to replace the self-signed certificate, completing the sequence of steps.
Let us go through these steps to understand this process better and become comfortable with using keytool.
Generating a Self-Signed Certificate
We generate a public and private key pair and a self-signed certificate by issuing the "keytool –genkey" command, specifying the keystore filename as test.ks, keystore type as JCEKS, keystore password as changeit, key entry alias as testkey, and retaining default parameters for key algorithm (DSA), key size (128 bits), signature algorithm (DSAWithSHA1), and validity period (90 days).
C:jstk>keytool -genkey -keystore test.ks -storepass changeit -storetype JCEKS -alias testkey What is your first and last name? [Unknown]: Pankaj Kumar What is the name of your organizational unit? [Unknown]: OpenView Business Unit What is the name of your organization? [Unknown]: Hewlett-Packard Co. What is the name of your City or Locality? [Unknown]: Santa Clara What is the name of your State or Province? [Unknown]: California What is the two-letter country code for this unit? [Unknown]: US Is CN=Pankaj Kumar, OU=OpenView Business Unit, O=Hewlett-Packard Co., L=Santa Clara, ST=California, C=US correct? [no]: yes Enter key password for <testkey> (RETURN if same as keystore password):
Pay attention to the questions asked. These are for collecting identity information. The answers form the distinguished name or identity of the subject. Alternatively, you could have supplied the identity information in a specially formatted string as the value of option –dname. For the answers shown above, this string would be: "CN=Pankaj Kumar, OU=OpenView Business Unit, O= Hewlett-Packard Co., L=Santa Clara, S=California, C=US"
Also, notice the prompt to select a password for the key entry, even though we have already specified a password for the keystore. This is so because each entry can have its own password for additional security. Pressing Enter without specifying a password assigns the keystore password to the key entry. At the end of the command, the new keystore file test.ks gets created in the current directory.
We have specified keystore type as JCEKS. Recall that the default type used by keytool is JKS. The type JCEKS must be specified for every execution of keytool on keystore file test.ks. This is somewhat tedious as it should be possible to determine the type by looking into the keystore file. However, this is not how keytool is written and it complains if you do not provide the type information while working on a JCEKS keystore.
Listing Contents of a Keystore
At this moment, the newly created keystore test.ks contains exactly one entry—the one having the generated private key and the self-signed certificate corresponding to this key. Let us list its contents:
C:jstk>keytool -list -keystore test.ks -storepass changeit -storetype JCEKS -v Keystore type: JCEKS Keystore provider: SunJCE Your keystore contains 1 entry Alias name: testkey Creation date: Sep 12, 2002 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=Pankaj Kumar, OU=OpenView Business Unit, O=Hewlett-Packard Co., L=Santa Clara, ST=California, C=US Issuer: CN=Pankaj Kumar, OU=OpenView Business Unit, O=Hewlett-Packard Co., L=Santa Clara, ST=California, C=US Serial number: 3d811944 Valid from: Thu Sep 12 15:46:28 PDT 2002 until: Wed Dec 11 14:46:28 PST 2002 Certificate fingerprints: MD5: F8:58:F1:AC:8F:47:96:EF:2C:E1:22:3E:20:CA:8A:95 SHA1: 5D:9D:61:AD:48:F0:69:FB:32:52:A4:6F:33:A0:F5:8D: 55:5D:F2:10 *******************************************
Look at the Owner and Issuer fields of the generated certificate—they are the same, as expected for a self-signed certificate. Also look at the Valid from field—the certificate is valid for 90 days from the time it was created. This is the default validity period assigned by the keytool. Another field of interest is Certificate chain length. We come back to this field later.
Generating a CSR
Our next operation is to generate a CSR based on the self-signed certificate that we just created. This is done with "keytool –certreq" command.
C:jstk>keytool -certreq -keystore test.ks -storepass changeit -storetype JCEKS -alias testkey -file test.csr
Like a X509 certificate, CSR content is also DER encoded and frequently converted to PEM format for easy exchange as an ASCII message. Output file test.csr contains the generated CSR in PEM format. You can view its contents by opening it with your favorite text editor.
CA Signed Certificate and Certification Path
The next step would be to submit this CSR to a CA and get a CA signed certificate. For this, you can either work with an established CA or use a program to setup your own CA. If you decide to setup your own CA, you could use the JSTK utility program certtool to do so. We talk about certtool and how to setup a minimal CA and sign certificates in a subsequent section.
For the time being, let us assume that you somehow get a CA certificate based on the generated CSR. What you get from a CA is not just the signed certificate but something known as a certificate chain or certification path and includes CA's certificate. If the signing CA is not a root CA, then the certification path will also have the certificate of its issuer and so on. The first element of a certification path is the signed certificate corresponding to the CSR. The last element is usually a self-signed CA certificate but could be any other trusted certificate, known as trust anchor. The structure of a certification path is specified in PKCS#7 standard in ASN.1 notation. The PKCS#7 certification path could be delivered as a DER encoded binary file or it may have been converted to a PEM format file.
Let us assume that the delivered certification path is in file test.p7b. The following command prints the contents of this file:
C:jstk>keytool -printcert -file test.p7b
Certificate[1]:
Owner: CN=Pankaj Kumar, OU=OpenView Business Unit,
O=Hewlett-Packard Co., L=Santa Clara, ST=California, C=US
Issuer: CN=JSTK CA, OU=JSTK Operations, O=JSTK Inc, C=US
Serial number: 3eb
Valid from: Fri Sep 13 12:55:00 PDT 2002
until: Sat Sep 13 12:55:00 PDT 2003
Certificate fingerprints:
MD5: 74:F1:D9:75:34:21:4A:A5:86:FC:E7:0B:A4:35:B2:90
SHA1: CF:1D:C9:2F:16:90:24:3E:84:86:7C:B5:EC:2E:24:6F:
C0:B6:9C:4F
Certificate[2]:
Owner: CN=JSTK CA, OU=JSTK Operations, O=JSTK Inc, C=US
Issuer: CN=JSTK CA, OU=JSTK Operations, O=JSTK Inc, C=US
Serial number: 64
Valid from: Fri Sep 13 11:42:00 PDT 2002
until: Thu Jun 09 11:42:00 PDT 2005
Certificate fingerprints:
MD5: 36:27:0E:D6:AA:25:20:89:C7:D9:F6:2D:2A:CC:EF:C5
SHA1: 83:FE:C0:F9:A4:CE:E5:7C:BD:2E:65:36:B8:7A:69:00:
7A:6C:D5:F7
As you can see, the file test.p7b has not only the signed certificate with the identity of the CSR but also the certificate of the signer.
Importing the CA Signed Certificate
The next and final step is to import this certificate into the keystore. This operation replaces the original self-signed certificate with the CA signed certificate in the keystore.
C:jstk>keytool -import -keystore test.ks -storepass changeit -storetype JCEKS -alias testkey -file test.p7b Top-level certificate in reply: Owner: CN=JSTK CA, OU=JSTK Operations, O=JSTK Inc, C=US Issuer: CN=JSTK CA, OU=JSTK Operations, O=JSTK Inc, C=US Serial number: 64 Valid from: Fri Sep 13 11:42:00 PDT 2002 until: Thu Jun 09 11:42:00 PDT 2005 Certificate fingerprints: MD5: 36:27:0E:D6:AA:25:20:89:C7:D9:F6:2D:2A:CC:EF:C5 SHA1: 83:FE:C0:F9:A4:CE:E5:7C:BD:2E:65:36:B8:7A:69:00: 7A:6C:D5:F7 ... is not trusted. Install reply anyway? [no]: yes Certificate reply was installed in keystore
This completes the process of obtaining a signed certificate.
Note that the import operation indicates that the CA certificate is not trusted. This is so because by default, this operation does not trust any CA certificate. You can ask this command to trust the certificates in keystore file %JRE_HOME%libsecuritycacerts by specifying "-trustedcacerts" option. View the CA certificates in this keystore by issuing this command:
C:jstk>keytool –list –v %JRE_HOME%libsecuritycacerts
Unless you got the signed certificate from a well-established CA, this list will not contain the CA that signed your certificate. To trust the CA that signed the certificate, you could do one of two things: import the CA certificate into %JRE_HOME%libsecuritycacerts or setup a different keystore to act as the truststore and import the CA certificate into this truststore.
Other Operations With keytool
A variety of additional operations are possible with keytool:
-keyclone: copy the contents of an entry to another entry with a different alias.
-export: get a certificate from an entry into a file.
-storepasswd: change the keystore password
-keypasswd: change the key entry password.
-selfcert: change the distinguished name associated with an entry.
To get a brief listing of commands and supported options, issue command "keytool" at the command prompt. For detailed descriptions, refer to the keytool documentation, available within SDK documentation and also online at http://java.sun.com/j2se/1.4/docs/tooldocs/windows/keytool.html.
Though keytool is convenient to use and quite adequate for development purpose, it is not designed for use in production systems.