Creating a Certificate Signed by a Trusted Certificate Authority

Using a certificate that was signed by a well-known (trusted) certificate authority gives you the advantage that most SSL communication partners know and trust that CA, and they will, therefore, most likely (depending on their configuration) accept a new certificate. This is especially helpful when communicating with partners outside your organization and beyond your authority to change security options. The disadvantages are that it takes some time (a few days or weeks) to get an official certificate and the fact that it is not for free.

Creating a certificate signed by a well-known CA involves the creation of a key database and a certificate request that is then sent to the CA. After returning the certificate from the CA, it needs to be stored in the key

database. These steps are detailed below using the GUI of the ikmgui utility. 1. Create server key database (.kdb file):

• Select New... from the on Key Database File pull-down menu on the top of the main window (Figure 23 ).

• On the dialog window that pops up, select CMS key database file in the Key database type selection list and then type in the name and location of the key database file to be created. This file has an extension of .kdb, as, for example, in ldap_key.kdb. Then, click on OK to close the dialog panel.

• A new dialog pops up that requests your input for a password for the key database file, an optional expiration time, and whether or not the password is to be stashed to a file. Enter a password, an optional expiration time, and make sure that you check the check box next to Stash the password to a file?; otherwise, the IBM SecureWay Directory cannot open the database file. Click on OK to close this dialog. The

password is then encrypted and stored in a file with the same name as the key database file but with an extension of .sth.

Your database file is now created. To proceed, you can now create a certificate request.

2. Create a certificate request.

• Select New Certificate Request... from the Create pull-down menu in the main window. In the dialog window that shows up, you will have to fill in the following information for the request:

• Key label (a clear, descriptive label for the certificate)

• Key size (512 or 1024, depending on security requirements and country version of the ikmgui utility)

• Common name

• Organization and other pertinent information to identify the owner of the certificate

• Full path of the file name for the certificate request file • Click on OK to create the request

The file created (default file name is certreq.arm) contains the certificate request.

3. Send the certificate request, that is, the certreq.arm file, to the certificate authority of your choice by mail or Web (follow their instructions, which can be found on their Web sites).

(While you are waiting for the certificate authority to process and return your certificate, you can enable SSL security by creating, storing, and importing a self-signed certificate using the procedure described in the next section.)

Once the certificate has been returned to you by the CA, you have to store it into the key database file.

4. Store the certificate into your database.

• On the ikmgui main menu (Figure 23 ), make sure that your key database file is open (check the filename in the Key database information portion of the window). If it is not open, choose Open... from the Key Database File pull-down menu and open your file. • Select Personal Certificates from the selection list in the lower Key

database content portion of the window. • Click on Receive... on the right of the window.

• Supply the information about the file containing the signed certificate and click on OK.

This adds the certificate to the key database file. You will see the new certificate in the list under Personal Certificates.

5. A root certificate of the CA must be stored in the key database file. By default, root certificates of the most common CAs are already present in the file; so, you do not need to add them again. A trusted root is simply an X.509 certificate that has been signed by a trusted entity (for example, Verisign). You can see what root certificates there are by selecting Signer Certificates from the selection list in the Key database content portion of the main window. If your CA is not present in that list, obtain a root certificate from this CA and add it by clicking on Add... on the right of the window.

This concludes the creation of a certificate signed by a well-known CA. You may choose to created a self-signed certificate instead (or while waiting on the certificate from the CA), which is described in the following section.

5.4.2 Creating a Self-Signed Certificate

You can use the ikmgui utility to create a self-signed certificate to enable SSL sessions between clients and servers. The steps are essentially the same except that, in this case, you are your own CA, and you will be creating your own root certificate. The advantages of using this type of certificate is a quick start, it is free, and you have no dependencies on other organizations. The drawback, on the other hand, is that each client or server using this kind of certificate needs to have the new root certificate imported, which may impose some administrative burden.

Use the following procedures to set up your site with a self-signed certificate, using the ikmgui utility (the first step is identical with the described above). 1. Create server key database (.kdb file).

• Select New... from the on Key Database File pull-down menu on the top of the main window (Figure 23 ).

• On the dialog window that pops up, select CMS key database file in the Key database type selection list and then type in the name and location of the key database file to be created. This file has an extension of .kdb, as, for example, in ldap_key.kdb. Then, click on OK to dismiss the dialog panel.

• A new dialog pops up that requests your input for a password for the key database file, an optional expiration time, and whether or not the password is to be stashed to a file. Enter a password, an optional expiration time, and make sure that you check the check box next to Stash the password to a file?; otherwise, the IBM SecureWay Directory

cannot open the database file. Click on OK to close this dialog. The password is then encrypted and stored in a file with the same name as the key database file but with an extension of .sth.

Your database file is now created. To proceed, you can now create a self-signed certificate.

2. Create a self-signed certificate.

• Select New Self-Signed Certificate... from the Create pull-down menu in the main window (Figure 23 ). In the dialog window that shows up, you will have to fill in the following information:

• Key label (a clear, descriptive label for the certificate)

• Key version (normally X509 V3, unless you have reasons for other versions)

• Key size (512 or 1024, depending on security requirements and country version of the ikmgui utility)

• Common name

• Organization and other pertinent information to identify the owner of the certificate

• Validity period in days

• Click on OK to create the certificate

This creates a certificate and adds it to the list of Personal Certificates shown in the main window.

3. From the certificate just created above, you need to extract the root certificate that is necessary for other communication partners (clients and/or servers) to recognize the newly created certificate. Here are the steps for exporting the root certificate:

• Select the new certificate’s entry in the Personal Certificate list and click on Extract Certificate... on the bottom right in the main window. • Select Base64-encoded ASCII data from the Data type list and enter a

file name (with an .arm extension) and a location (directory) for the new root certificate to be exported to. Then click on OK to export the root certificate. (If you want to create a file for the JNDI SSLight client key class, you must select SSLight key database class as data type when creating a file with an .class extension. See also 8.1.4, “JNDI and Security” on page 230.)

You have now created a file that holds your own root certificate. This must be imported to all communication partners that will use SSL to connect to this machine.

• Make sure the file created in the previous step is available from this system, for example, on a diskette.

• Invoke the ikmgui utility on the receiving system.

• If not already done, create a key database file (see first step above for creating a self-signed certificate).

• In the Key data contents portion of the window, select Signer Certificates from the selection list and click on Add... on the right. • Select Base64-encoded ASCII data from the Data type list and type

the certificate file name and location into the appropriate fields. Then, click on OK to import the certificate.

• On the upcoming dialog, supply a label for this certificate and click on OK.

The steps as described above need to be done on each machine that will communicate using this certificate with the machine on which the certificate was created.

Each LDAP server should have its own certificate. Sharing certificates across multiple LDAP servers is not recommended. By using different certificates and private keys for each server, your security exposure is minimized should a keyring file for one of the servers be compromised.