You do not have a secure network connection until you have created a key for
secure network communications and received a certificate from a certificate
authority (CA) who is designated as a trusted CA on your server. Use IKEYMAN
to create key databases, public-private key pairs, and certificate requests.
If you are acting as your own CA, you can use IKEYMAN to create self-signed
certificates. If you act as your own CA for a private Web network, you have
the option to use the server CA utility to generate and issue signed certificates
to clients and servers in your private network.
You can use IKEYMAN only for configuration tasks related to public-private
key creation and management. You cannot use IKEYMAN for configuration options
that update the server configuration file, httpd.conf. For options that update
the server configuration file, you must use the IBM Administration Server.
This appendix provides detailed information on tasks you can perform using
the IBM Key Management Utility (IKEYMAN). It does not explain how to configure
security options that require updates to the server configuration file.
You do not have a secure network
connection until you have created a key for secure network communications and
received a certificate from a certificate authority (CA) who is designated as
a trusted CA on your server. Use IKEYMAN to create the key database
file, public-private key pair, and certificate request. After you
receive the CA-signed certificate, use IKEYMAN to receive the certificate into
the key database where you created the original certificate request.
This section provides a quick reference of IKEYMAN tasks and detailed
descriptions of the most common tasks.
When you create a new key database, you specify a key database
password. This password is important because it protects the private
key. The private key is the only key that can sign documents or decrypt
messages encrypted with the public key. It's a good practice to
change the key database password frequently.
Use the following guidelines when specifying the password:
The password must be from the U.S. English character
The password should be at least six characters and contain at least two
nonconsecutive numbers. Make sure the password doesn't consist of
publicly obtainable information about you, such as the initials and birth date
for you, your spouse, or children.
Stash the password.
If you specify an expiration date for the password, keep track of when to
change it. If the password expires before you change it, a message will
be written to the error log. The server will start, but there will not
be a secure network connection if the password has expired.
The initial configuration setting for the default key database name is
key.kdb. If you use key.kdb as your default key database
name, you do not need to register the database with the server. The
server will use the initial setting on the KeyFile directive in the
configuration file. If you do not use key.kdb as your default key database name or if you create additional key databases,
you must register those databases.
It usually takes two to three weeks to get a certificate from a well-known
CA. While waiting for a certificate to be issued, you can use IKEYMAN
to create a self-signed server certificate to enable SSL sessions between
clients and the server.
You also use this procedure if you are acting as your own CA for a private Web network.
Use this procedure to receive a certificate that is
electronically mailed to you from a certificate authority (CA) who is
designated as a trusted CA on your server. By default, the following CA
certificates are stored in the key database and marked as trusted CA
IBM World Registry CA
Integrion CA Root (from IBM World Registry)
VeriSign Class 1 Public Primary CA
VeriSign Class 2 Public Primary CA
VeriSign Class 3 Public Primary CA
VeriSign Class 4 Public Primary CA
VeriSign Test CA
RSA Secure Server CA (from VeriSign)
Thawte Personal Basic CA
Thawte Personal Freemail CA
Thawte Personal Premium CA
Thawte Premium Server CA
Thawte Server CA
The Certificate Authority may send more than 1 certificate. In addition to the certificate for your server,
the CA may also send additional Signing certificates or Intermediate CA Certificates. For example, Verisign
includes an Intermediate CA Certificate when it sends a Global Server ID certificate. Before receiving the
server certificate, you will first need to receive any additional Intermediate CA certificates. Follow the
instructions in Storing a CA's certificate to receive Intermediate CA Certificates.
If the CA who issues your CA-signed certificate is not a trusted CA in the
key database, you must first store the CA's certificate and designate the
CA as a trusted CA. Then you can receive your CA-signed certificate
into the database. You cannot receive a CA-signed certificate from a CA
who is not a trusted CA. For instructions, see Storing a CA's certificate.
To receive the CA-signed certificate into a key database:
Enter ikeyman on a command line on Unix or start the Key Management utility in the IBM HTTP Server folder on Windows NT.
Select Key Database File from the main UI, then select
In the Open dialog box, enter your key database name or click
on key.kdb if you are using the default. Click
In the Password Prompt dialog box, enter your correct password,
then click OK.
Select Personal Certificates in the Key Database content frame,
then click the Receive button.
In the Receive Certificate from a File dialog box, enter the name of a
valid Base64-encoded file in the Certificate file name text
field. Click OK.