Netscape Certificate Management System Administrator's Guide: Keys and Certificates

For key length, enter the size in bits. The choices for RSA key type are 512, 1024, 2048, or custom. The choices for DSA key type are 512, 1024, or custom. Keep in mind that generating a new key pair takes time--the longer the key length the longer the time the wizard takes to generate it.

Step 4. Specify the Subject Name for the Certificate

Specify the subject name, in distinguished name (DN) format, for the certificate to be requested.

You can either enter values for individual DN attributes required to build the subject DN or build the complete subject DN string yourself. If you enter values for individual DN attributes, the wizard constructs the subject DN string.

If you want to enter values for individual DN components, provide the following information:

Common name--enter the name as appropriate. The common name format, except for the SSL server certificate, can be a descriptive name of up to 255 characters; for example, you can name the Certificate Manager's signing certificate as "Root CA for ABC Corporation"; similarly, you can name the Registration Manager's signing certificate as "Registration Authority for North America". For a SSL server certificate, the name must be the fully qualified host name of Certificate Management System in this form:

<machine_name>.<your_domain>.<domain>

To determine the machine and domain names, go to Netscape Console, and locate the CMS host in the navigation tree.

Organizational unit--enter the organizational unit you belong to.

Organization--enter a description that identifies your organization.

Locality--enter the name of the city where you business is located.

State or province--enter the name of the state or province where your business is located.

Country--enter the name of the country where your business is located.

Important When choosing subject names for certificates, be sure to follow the information provided in "Role of Distinguished Names in Certificates".

Step 5. Specify the Validity Period

You need to complete this step only if you chose to generate a self-signed CA certificate request.

Specify the starting and ending dates of the validity period for the certificate request you want to generate. You can also specify the time at which the validity period should start and end on those dates. The date and time are in the form YYYYMMDD (Year, Month, Day) and HHmmSS (Hour, Minute, Second), in that order.

The default validity period is one year.

Step 6. Specify Extensions

You need to complete this step only if you chose to generate a CA signing certificate request for a Certificate Manager (deployed as either the root CA or a subordinate CA).

This screen allows you to set the standard X.509 version 3 extensions and Netscape-defined extensions for the certificate to be requested. The required extensions are chosen by default. If you want to change the default choices, be sure to read the general guidelines explained in "Certificate Extensions" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.

Also note that certificate extensions are required if you are setting up a hierarchy of certificate authorities (CAs). Subordinate CAs must have certificates that include the extension identifying them as either a subordinate SSL CA (which allows them to issue certificates for SSL) or a subordinate email CA (which allows them to issue certificates for secure email). If you disable certificate extensions, you will not be able to set up CA hierarchies. For more information on CA hierarchies, see "Certificate Hierarchies" in Appendix D of Managing Servers with Netscape Console.

You can set the following extensions:

Basic constraints--select this option if you want to set any of the Basic Constraints extension bits in the certificate you are requesting. When you select the option, the associated fields are enabled. You should select the ones you want to set.

Netscape certificate type--select this option if you want to set any of the Netscape Certificate Type extension bits in the certificate you are requesting. When you select the option, the associated fields are enabled. You should select the ones you want to set.

Authority key identifier--select this option if you want to set the authority key identifier extension.

Subject key identifier--select this option if you want to set the subject key identifier extension.

Key usage--select this option if you want to set the key usage extension. If you choose this option, the digital signature (bit 0), non repudiation (bit 1), key Certificate Sign (bit 5), and CRL sign (bit 6) bits are set by default. The extension is marked critical as recommended by the PKIX standard and rfc 2459 (see ftp://ftp.isi.edu/in-notes/rfc2459.txt for a description of the Key Usage extension).

Extension in MIME 64 DER encoding--select this option if you want to specify any custom extension. When you select the option, the associated text field is enabled. You should paste your extension (in MIME 64 DER encoded format) into the text field.

Step 7. Copy the Certificate Signing Request

Based on the information you've entered in the previous steps, the wizard now displays the certificate signing request (CSR).

The request is in a base-64 encoded PKCS #10 format and is bounded by the marker lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----.

An example is show below:

-----BEGIN NEW CERTIFICATE REQUEST-----

MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21td W5pY2F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5M DIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQ LEwZQZW9wbGUxFzAVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0e TEjMCEGCSqGSIb3DbndgJARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAY JYIZIAYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamG dYql2w4hIBgdR+jWeLmD4CP4xzmKdvQ6IqD2q8DBs9lRQu9JYg129oaCLpZfMNTPnMc3WPKO2pWZW Um7waHEtdbo9vSpbJkXTM/2GhWbsO5vLdeOxrPGxihkHgV/ vmqCl4HW7AorqGgyfygbhgthgutrhryj

-----END NEW CERTIFICATE REQUEST-----

Do not modify the CSR; you must send it to the CA as is.

Copy the CSR, including the marker lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----, to a text file. If you are running the wizard on a Windows NT system, you can also copy the CSR to the Windows clipboard. In a Unix system, you may have to open an application, such as Netscape Composer, with a clipboard.

The wizard also copies the CSR to a text file it creates in the configuration directory, which is located at

<server_root>/cert-<instance_id>/config/...

<server_root> is the directory where the CMS binaries are kept. You first specified this directory during installation.

<instance_id> is the ID for this instance of Certificate Management System. You first specified this when you installed this server.

The name of the text file varies depending on for which key pair you generated the CSR:

If the CSR is for a Certificate Manager CA signing certificate, the file name will be cacsr.txt.

If the CSR is for a Registration Manager signing certificate, the file name will be racsr.txt.

If the CSR is for a Data Recovery Manager transport certificate, the file name will be kracsr.txt.

If the CSR is for a SSL server certificate, the file name will be sslcsr.txt.

Step 8. Check the Certificate Request Status

The wizard now informs you of the status of the request.

If you requested a self-signed CA certificate, the wizard automatically submits the CSR to the CA. If the CSR includes all the required information, the CA signs the certificate and returns it to the wizard, which then installs it in the appropriate token.

If you requested any other certificate, you must submit the CSR to a CA of your choice manually. This is explained in Step 9.

Step 9. Send the Certificate Signing Request to a CA

This step in not part of the wizard process. Follow these instructions to manually send the CSR to a CA of your choice. The CA can be internal or external.

An internal CA is any CA deployed internally by your organization--for example, a Certificate Manager installed in the same or another instance of Certificate Management System. See "Sending the CSR to an Internal CA".

An external CA is any public CA. Before sending the CSR to a public CA, make sure that the CA can issue the certificate you want to request. Also, it is a good idea to read the policy statement published by a CA to see whether the CA imposes any restrictions on the validity period or usage of the certificate. See "Sending the CSR to an External CA".

Sending the CSR to an Internal CA

The following instructions assume that your internally deployed CA is a Certificate Manager and that you are using the default HTML forms provided for end-entity enrollment. If you have customized these forms, you should follow the appropriate instructions.

To send the CSR manually to an internal CA:

Locate the text file to which you copied the CSR earlier (see "Step 7. Copy the Certificate Signing Request").

Open a web browser window.

Enter the URL to the CA's home page.

By default, the CA's home page is the end entity services interface. Depending on the port at which the CA is listening to end-entity requests (see "End-Entity Ports") the URL to the end entity services is one of the following:

http://<host_name>:<end_entity_port>

https://<host_name>:<end_entity_port>

where <host_name> is in the form <machine_name>.<your_domain>.<domain>

The end entity services interface appears.

Click the Enrollment tab.

In the menu list, click the appropriate link:

If the CSR is for a subordinate CA certificate, select the manual enrollment link in the Certificate Manager Enrollment section.

If the CSR is for a Registration Manager's signing certificate, select the manual enrollment link in the Registration Manager Enrollment section.

If the CSR is for an SSL server certificate, select either the manual or the directory-based link in the Server Enrollment section.

For information on how the default server enrollment forms work, see "Certificate Issuance to Servers".

In the form that appears, enter the required information and paste the CSR from the text file.

Be sure to include the marker lines, -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----.

Submit the request.

When the CA sends you a response, save the information in a text file for future reference or inquiry.

If you submitted the request using a manual enrollment form, the request gets queued.

An agent needs to process and approve the certificate request, which the CA signs then and delivers back to the email address specified in the request. You can contact the CA agent to find out when the certificate will be delivered to you.

If you submitted the request using an automated enrollment form, the request gets processed automatically by the CA.

Keep in mind that the CA can reject or queue the request if it fails any of the authentication or policy checks. A request that gets queued must be processed manually by an agent.

When you receive the certificate from the CA, install it following the instructions in "Using the Wizard to Install a Certificate or Certificate Chain".

Sending the CSR to an External CA

To send the CSR manually to an external CA:

Locate the text file to which you copied the CSR (see "Step 7. Copy the Certificate Signing Request").

Open a web browser window.

Navigate to the CA's home page by entering the appropriate URL in the browser window.

Locate the form that allows you to submit certificate requests for servers.

Enter the required information and paste the CSR from the text file.

Be sure to include the marker lines, -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----.

Submit the request.

When the CA sends you a response, save the information in a text file for future reference or inquiry.

When you receive the certificate from the CA, install it following the instructions in "Using the Wizard to Install a Certificate or Certificate Chain".

Using the Wizard to Install a Certificate or Certificate Chain

The Certificate Setup Wizard allows you to install or import the following certificates into either an internal or external token used by the currently selected CMS instance:

Any of the certificates used by the Certificate Manager, Registration Manager, and Data Recovery Manager installed in the currently selected CMS instance

Any other trusted CA certificates (certificates of CAs that you want to trust)

Certificate chains

A certificate chain typically includes a collection of certificates: the subject certificate, the trusted root CA certificate, and any intermediate CA certificates needed to link the subject certificate to the trusted root. However, the certificate chain the wizard allows you to import must include only CA certificates; none of the certificates can be a user certificate.

In a certificate chain, each certificate in the chain is encoded as a separate DER-encoded object. When the wizard imports a certificate chain, it imports these objects one after the other, all the way up the chain to the last certificate, which may or may not be the root CA certificate. If any of the certificates in the chain already exist in the local certificate database, the wizard replaces them by the ones included in the chain. If the chain includes intermediate CA certificates, the wizard adds them to the certificate database as untrusted CA certificates.

The certificate or certificate chain you provide to the wizard for installation must be in one of the data formats supported by the wizard. This is explained in "Data Formats for Installing Certificates and Certificate Chains".

Using the wizard to install a certificate or certificate chain involves the following steps, described in detail on page 218:

Step 1. Select the Operation

Step 2. Select the Certificate or Certificate Chain

Step 3. Specify the Location of the Certificate

Step 4. View the Certificate or Certificate Chain

Step 5. Install the Certificate or Certificate Chain

Step 6. Verify the Certificate Status

Data Formats for Installing Certificates and Certificate Chains

The wizard can accept certificates and certificate chains in several data formats. This section briefly explains the data formats recognized by the wizard.

Binary Formats

The wizard can recognize certificates and certificate chains in the following binary formats:

DER-encoded certificate

This is a single binary DER-encoded certificate.

PKCS #7 SignedData objects

This is a PKCS #7 SignedData object. The only significant field in the SignedData object is the certificate. In particular, the signature and the contents are ignored. The PKCS #7 format allows multiple certificates to be downloaded at once.

DER-encoded certificates

These are DER-encoded certificates that may or may not be wrapped in a base-64 encoding package surrounded by the delimiters -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.

Netscape Certificate Sequence

This is a simpler format for downloading certificate chains. It consists of a PKCS #7 ContentInfo structure, wrapping a sequence of certificates. The value of the contentType field should be netscape-cert-sequence, while the content field is the following structure:

CertificateSequence ::= SEQUENCE OF Certificate

This format allows multiple certificates to be downloaded at once.

Text Formats

The wizard can also import certificates and certificate chains in text formats. Here's what you should be aware of when using the wizard to install a certificate or certificate chain in text format:

The text format must begin with the following line:

-----BEGIN CERTIFICATE-----

Following this line should be the certificate data, which can be in any of the binary formats described in "Binary Formats". This data should be base-64 encoded as described by RFC 1113 (for details, see http://www.scit.wlv.ac.uk/rfc/rfc11xx/RFC1113.html).

Following the certificate data must be this line:

-----END CERTIFICATE-----

Step 1. Select the Operation

Indicate whether you want to request a certificate or install a certificate.

For the sake of completing the instructions that follow, assume that you chose to install a certificate.

Step 2. Select the Certificate or Certificate Chain

Select the certificate you want to install.

The drop-down list shows various options:

Any of the certificates used by the subsystems--Certificate Manager, Registration Manager, or Data Recovery Manager--installed in the currently selected CMS instance.

Any other trusted CA certificates

Certificate chains

Depending on whether you want to install a CMS certificate, any other trusted CA certificate, or a CA certificate chain, choose the appropriate option from the list box:

Certificate Manager Signing Certificate--choose this option if you want to install a signing certificate for the Certificate Manager installed in the currently selected CMS instance.

Registration Manager Signing Certificate--choose this option if you want to install a request signing certificate for the Registration Manager installed in the currently selected CMS instance.

Data Recovery Manager Transport Certificate--choose this option if you want to install a transport certificate for the Data Recovery Manager installed in the currently selected CMS instance.

SSL Server Certificate--choose this option if you want to install an SSL server certificate for the Certificate Manager, Registration Manager, or Data Recovery Manager installed in the currently selected CMS instance.

Server Certificate Chain--choose this option if you want to install a CA certificate chain; the CA certificate will be included in the chain.

Other Trusted CA Certificate--choose this option if you want to install a trusted CA certificate.

Step 3. Specify the Location of the Certificate

Locate the certificate or certificate chain you want to install.

You can keep the certificate or certificate chain in a text file or copy it to the text area on the wizard screen. Here is some information that will help you decide on the location.

Keeping the certificate or certificate chain in a text file

The wizard can import a certificate or certificate chain from a text file in text as well as binary formats; see "Data Formats for Installing Certificates and Certificate Chains". If you have copied the certificate or certificate chain to a text file, you will be required to provide the wizard with the absolute path to that file. The file must be located in the host system the wizard is running. If the file is located elsewhere, exit from the wizard, copy the file to the local disk, and restart the wizard.

Copying the certificate or certificate chain to the text area on the wizard screen

You can paste the certificate or certificate chain into the text area provided by the wizard. This is a text input field, so you can paste the certificate or certificate chain in text format only. For example, if you are installing a certificate, it base-64 encoded certificate blob should look similar to this:

-----BEGIN CERTIFICATE-----

MIICKzCCAZSgAwIBAgIBAzANgkqkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERMA8GA1UEChMITmV 0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2 MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHawczEXMBUGA 1UEAxMOU3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhdfNAQEBBQADgY0AMIGJAoGBAMr6eZiPGfjX3u RJgEjmKiqG7SdATYzBcABu1AVyd7chRFOGD3wNktbf6hRo6EAmM5R1Askzf8AW7LiQZBcrXpc0k4d u+2j6xJu2MPm8WKuMOTuvzpo+SGXelmHVChEqooCwfdiZywyZNmgaMa2MS6pUkfQVAgMBAAGjNjA0 MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNVHMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhk iG9w0BAQQFAAOBgQBtI6z07Z635DfzX4XbAFpjlRlAYwQzTRYx8GfcNAqCqCwaSDKvsujvwbf91o3 j3UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RCaIDy84hW3WWehBUqVK5 SYzJ4oTjx7dwNMdGwbWfpRqjd1A==thghtelirhe395uy85ifnf8HUYUHU

-----END CERTIFICATE-----

Step 4. View the Certificate or Certificate Chain

The wizard displays the certificate or certificate chain you have chosen to install. Make sure you have chosen the right one; otherwise, use the Back button to go back and locate the right one. Specify a nickname for the certificate.

Step 5. Install the Certificate or Certificate Chain

The wizard shows the certificate or certificate chain information you have selected for installing. You should check the information to make sure that you have chosen the correct one for installing.

After verifying that the certificate you have chosen is the correct one, click the Install button. The wizard installs the certificate or the CA chain in the token you have chosen.

If you installed a certificate that has been issued by CA whose certificate chain doesn't exist in the certificate database, you must add that CA's certificate chain to the database. To add the CA chain to the database, copy the CA chain to a text file, start the wizard again, and install the CA chain.

If you installed (or imported) a certificate chain, the wizard adds (to the local trust database) the first certificate in the chain as a trusted CA certificate and any subsequent certificates as untrusted CA certificates. For more information on how the wizard installs a certificate chain, see "Using the Wizard to Install a Certificate or Certificate Chain".

Step 6. Verify the Certificate Status

This step is applicable only if you installed a certificate chain.

After you install a certificate chain in the trust database of a CMS instance, check the trust status of each certificate that got installed, and make sure that the correct CA certificates are trusted. For instructions, see "Changing the Trust Settings of a CA Certificate".

Configuring the Server's Security Preferences

Configuring the server's security preferences involves identifying the following:

The SSL server certificates the server must use for authenticating to the end entity, agent, and administration interfaces. For details, see "Configuring the Server to Use Separate SSL Server Certificates".

The SSL client certificate the server must use for authenticating to the publishing directory. For details, see "Getting an SSL Client Certificate for a Subsystem".

The version of SSL that an instance of Certificate Management System must use during SSL communication. The latest version is SSL version 3, but many older clients use SSL version 2. Because client authentication is required for performing privileged operations, you must enable SSL version 3 ciphers supported by Certificate Management System. For details, see "Setting Up Cipher Preferences for SSL Communications".

Configuring the Server to Use Separate SSL Server Certificates

You can configure a CMS instance to use separate SSL server certificates for authenticating to Netscape Console, the Agent Services interface, and the end entity services interface.

This configuration involves the following steps:

Step 1. Get the Required SSL Server Certificates

Step 2: Update the Configuration

Step 1. Get the Required SSL Server Certificates

You must first request and install the required number of SSL server certificates for the particular CMS instance. For instructions, see "Getting New Certificates for the Subsystems".

Once you have installed the certificates, you should be able to see them in the list of SSL server certificates in the Encryption tab of the CMS window.

Step 2: Update the Configuration

After you verify that the certificates are installed, configure the server as follows:

Stop the CMS instance; see "Stopping Certificate Management System".

Open the configuration file (CMS.cfg) in a text editor; to locate the file, see "Locating the Configuration File".

Change the configuration:

To change the certificate used for authenticating to the Agent Services interface, locate the agentGateway.https.nickName parameter and change its value to the nickname of the new SSL server certificate.

For example, if the nickname of the SSL server certificate is SSLServerCert_agt, the configuration should look like this:

agentGateway.https.nickName=SSLServerCert_agt <instance_id>

To change the certificate used for authenticating to the end-entity services interface, locate the eeGateway.https.nickName parameter and change its value to the nickname of the new SSL server certificate.

For example, if the nickname of the SSL server certificate is SSLServerCert_ee, the configuration should look like this:

eeGateway.https.nickName=SSLServerCert_ee <instance_id>

To change the certificate used for authenticating to the administration interface, Netscape Console, locate the radm.https.nickName parameter and change its value to the nickname of the new SSL server certificate.

For example, if the nickname of the SSL server certificate is SSLServerCert_admin, the configuration should look like this:

radm.https.nickName=SSLServerCert_admin <instance_id>

Save your changes.

Start the server; see "Starting Certificate Management System".

Getting an SSL Client Certificate for a Subsystem

By default, both Certificate Manager and Registration Manager use their SSL server certificates for SSL client authentication to the publishing directory. If you want these subsystems to use other certificates for authenticating to the publishing directory, you can do so. This section explains how to get an SSL client certificate for a subsystem and how to configure the subsystem to use that certificate for authenticating to the publishing directory.

Getting an SSL client certificate for a subsystem involves the following steps:

Step 1. Generate a Key Pair for the Subsystem

Step 2. Generate a Certificate Signing Request for the Key Pair

Step 3. Submit the CSR to the CA

Step 4. Ask an Agent to Approve the Request

Step 5. Install the Certificate in the Internal Database

Step 6. Configure the Subsystem to Use This Certificate

Step 1. Generate a Key Pair for the Subsystem

Generate a key pair for the subsystem following the instructions in "Generating a New Key"; see Appendix E, "Key Database Tool".

Step 2. Generate a Certificate Signing Request for the Key Pair

Generate a certificate signing request (CSR) for the key pair following the instructions in "Creating a Certificate Request"; see Appendix D, "Certificate Database Tool". Be sure to include your email address in the request so that the CA can deliver the certificate to you.

Step 3. Submit the CSR to the CA

Submit the CSR to the CA. Because the request needs some modifications, be sure to use the manual enrollment process; this way you can tell the person who will process your request about the changes he or she must make before approving the request. For example, if you are submitting the request to a Certificate Manager (CA), be sure to use the manual enrollment form; do not use the automated enrollment forms, such as the directory-based server enrollment form. Include your email address in the request so that the CA can deliver the certificate to you.

Step 4. Ask an Agent to Approve the Request

If you submitted the request to a Certificate Manager (CA), ask its agent to process the request. The agent must make sure that only the SSL Client option for certificate type is selected in the request, and then approve it. (For certificates with no Netscape Certificate Type extensions, the key usage extension must be included with signing and encryption bits set.)

If you submitted the request to any other CA, you must ask the person managing that CA to make the same changes to the request before approving it.

Step 5. Install the Certificate in the Internal Database

When you receive the request, follow the instructions in "Adding a Certificate to the Database" (see Appendix D, "Certificate Database Tool") and install the certificate in the token you used to generate the key pair.

Step 6. Configure the Subsystem to Use This Certificate

After you install the certificate, configure the corresponding subsystem to use the new certificate for SSL client authentication to the publishing directory. To configure the Certificate Manager, see "Identifying a Certificate Manager's Publishing Directory". To configure the Registration Manager, see "Identifying a Registration Manager's Publishing Directory".

Setting Up Cipher Preferences for SSL Communications

A cipher is the algorithm used in encryption. Some ciphers have stronger encryption capabilities than others. Generally speaking, the more bits a cipher uses during encryption, the harder it is to decrypt the data.

When a client initiates an SSL connection with Certificate Management System, it lets the server know what ciphers it prefers to use to encrypt information. In any two-way encryption process, both parties must use the same ciphers. A number of ciphers are available; your server needs to be able to use the most popular ones.

SSL Ciphers Supported in Certificate Management System

Figure 8.1 shows the ciphers supported by Certificate Management System (on the server side). The figure shows SSL 2.0 and 3.0 ciphers supported in the US (or domestic) version of Certificate Management System. The export version of the software shows only those ciphers that are currently permitted by United States law.

Figure 8.1 SSL version 2.0 and 3.0 cipher suites supported (in the US version of the software)

You can choose ciphers from the SSL 2.0 protocol, as well as from SSL 3.0. To specify which ciphers your server can use, check them in the list of ciphers to enable them. Unless you have a compelling reason not to use a specific cipher, you should check them all, except as noted in the warning that follows. For a detailed description of ciphers, see "Ciphers Used with SSL" in Appendix E of Managing Servers with Netscape Console.

Warning You might not want to check the options that say "No Encryption, only MD5 message authentication" and "No Encryption, only Fortezza and SHA message authentication." The reason for this is, if no other ciphers are available on the client side, the server will use these and no encryption will occur.

Another reason not to enable all ciphers is to prevent SSL connections with less than optimal encryption. US law prohibits the export of products with 128-bit encryption, so overseas clients might be using only 40-bit encryption, which is not as difficult to crack as 128-bit. Disabling all 40-bit ciphers effectively restricts access to browsers available only in the United States.

Note that international users of Netscape Communicator (with encryption capability restricted to 40-bit encryption) can use Netscape's International Step-Up program to step up to stronger encryption, 56-bit, 128-bit, or 168-bit. Step-up refers to the ability of export browsers to establish strong SSL sessions with domestic SSL servers, if they have the appropriate step-up certificates.

For general information on the International Step-Up program and getting step-up certificates, see the information available at the following URL:

http://home.netscape.com/products/security/technology/128bit.html

For information on configuring up your clients and servers for the international step-up feature (after you get the step-up certificates), see the information available at this URL:

http://developer.netscape.com/tech/security/stepup/overview.html

Configuring the Server to Use Specific Ciphers

You can set a number of systemwide preferences for SSL by specifying the ciphers that Certificate Management System should recognize and use during SSL communication; the server applies the cipher settings you choose to all the SSL (HTTPS) ports it uses.

To change the cipher settings for a CMS instance:

Access the CMS window (see "Accessing the CMS Window").

Click the Configuration tab, and then in the right pane, click the Encryption tab.

Click SSL Cipher Preferences, and choose the appropriate options.

For details, see "Setting Up Cipher Preferences for SSL Communications".

Click OK.

You are returned to the Encryption tab.

To save your changes, click Save.

The CMS configuration is modified. If the changes you made require you to restart the server, you will be prompted accordingly. In that case, restart the server.

Getting New Certificates for the Subsystems

You may need to get new certificates for Certificate Management System. Getting a new certificate means getting a certificate based on a new public and private key pair.

The sections that follow explain how to get new certificates for the Certificate Manager, Registration Manager, and Data Recovery Manager using the Certificate Setup Wizard. Alternatively, you can use the command-line utility called the Certificate Database Tool; for details about this utility, see Appendix D, "Certificate Database Tool".

Getting a new certificate involves the following steps:

Step 1. Plan for the New Certificate

Step 2. Request the New Certificate

Step 3. Install the New Certificate

Step 4. Deploy the New Certificate

Step 1. Plan for the New Certificate

Getting a new certificate for a subsystem requires careful planning. This section provides some guidelines that will help you request and install the new certificate.

Determine which certificate you want to get

You can get CA signing and SSL server certificates for the Certificate Manager; signing and SSL server certificates for the Registration Manager; and transport and SSL server certificates for the Data Recovery Manager.

If you want to get a new self-signed CA certificate for a Certificate Manager, you must consider the possible effects on your PKI setup of changing the key pair of the root CA (also called CA key rollover). When you change the root CA key, all certificates that rely on the CA certificate for validation will no longer be validated. Before getting a new self-signed certificate for a Certificate Manager, therefore, you must address issues involved in deploying the new CA certificate across your enterprise.

If you want to get a new subordinate CA certificate for a Certificate Manager, you must consider the possible effects on your PKI setup of changing the key pair of the subordinate CA. When you change the subordinate CA key, all certificates that rely on the CA certificate for validation will no longer be validated. Before getting a new subordinate certificate, you must plan to address issues involved in deploying the new subordinate CA certificate across you enterprise.

If you want to get a new signing certificate for a Registration Manager, check whether the Registration Manager has been set up as a trusted manager for any other subsystems--that is, you must identify the subsystems that have been configured to receive requests from this Registration Manager; see "Trusted Managers". You will need to replace the existing signing certificate with the new one in all these subsystems.

If you want to get a new transport certificate for a Data Recovery Manager, you must identify the end-entity interfaces or forms that have been set up for the archival of end users' encryption private keys; see "How Key Archival Works". You will need to replace the existing transport certificate with the new one in all these forms.

If you want to get a new SSL server certificate for a Certificate Manager or Registration Manager, decide whether you want the subsystem to also use this certificate for SSL client authentication to the publishing directory. If so, you will have to request the certificate with the appropriate extensions set, and after installing the certificate you will have to configure the publishing directory.

You can get any number of SSL server certificates.

Decide on the CA that will sign the certificate

If you want to get a new self-signed CA certificate, you don't have to make this decision, because the CA itself signs it. For all other certificates, you must decide on the CA that will sign the certificate.

If you want the certificate to be signed by an internally deployed CA, check to be sure that the CA can issue the certificate you want request.

If you want the certificate to be signed by a public CA, find out the following:

Does the public CA have a public policy statement? If one is available, read it; it may help you decide whether to request the certificate from this CA.

Is the public CA's certificate already installed in the trusted CA in the trust database of Certificate Management System? If not, do you want to install it?

Is the public CA a trusted CA in the trust database of Certificate Management System? If not, do you want to trust it?

Can the public CA issue the certificate you want to request?

Does the public CA impose any restrictions on certificates it issues? For example, if you are planning for requesting a subordinate CA certificate for a Certificate Manager, you may want to find out whether the public CA imposes any restrictions on the validity period, volume, or type of certificates your CA can issue. If you are planning for requesting a signing certificate for a Registration Manager, you may want to find out whether the public CA imposes any restrictions on the validity period or the number of certificate requests the Registration Manager can sign using the certificate. If you are planning for requesting a transport certificate for a Data Recovery Manager, you may want to find out whether the public CA imposes any restrictions on the validity period or the number of keys the Data Recovery Manager can archive using the certificate.

What information does the public CA expects you to provide with the certificate request?

How long will the public CA take to deliver the certificate, and how will the certificate be delivered to you? (The most common delivery mechanism is by email.)

Determine the token for generating the key pair

Identify the token, internal or external, that you want to use to generate the key pair for the certificate and to store the certificate. If you want to use an existing token, you must know the password that protects the token. If the token is external, make sure that the token is installed properly; see "Installing External Tokens".

Determine certificate formulation information

Decide on the subject DN and nickname for the certificate you want generate. Also decide on details such as the key algorithm, key size, extensions, and validity period for the certificate.

Step 2. Request the New Certificate

Once you have all the information, go ahead and request the certificate. The Certificate Setup Wizard built into the CMS window automates the process of requesting certificates used by the Certificate Manager, Registration Manager, and Data Recovery Manager. You can use this wizard to generate a new certificate request and submit the request to any CA for signing. For instructions, see "Using the Wizard to Request a Certificate".

Step 3. Install the New Certificate

When you receive the certificate from the CA, you must install it in the token that contains the key pair for this certificate; it must be the token you used to generate the request in Step 2.

The Certificate Setup Wizard automates the process of installing certificates used by the Certificate Manager, Registration Manager, and Data Recovery Manager. You may use this wizard to install the new certificate. For instructions, see "Using the Wizard to Install a Certificate or Certificate Chain".

Step 4. Deploy the New Certificate

In this step, follow the instructions appropriate for the certificate you installed:

If you installed a new CA signing certificate for a Certificate Manager, see "Deploying Certificate Manager's CA Signing Certificate".

If you installed a new signing certificate for a Registration Manager, see "Deploying Registration Manager's Signing Certificate".

If you installed a new transport certificate for a Data Recovery Manager, see "Deploying Data Recovery Manager's Transport Certificate".

If you installed a new SSL server certificate, see "Deploying a Subsystem's SSL Server Certificate".

Deploying Certificate Manager's CA Signing Certificate

If you installed a new CA signing certificate, you must deploy it in the PKI environment that depends on this certificate for validation. It is beyond the scope of this book to explain how you should deploy the new CA certificate. You may find it useful to go over some of the deployment issues discussed in the document available at this URL:

http://help.netscape.com/kb/server/980710-25.html

Deploying Registration Manager's Signing Certificate

If you installed a new Registration Manager signing certificate, you must also install this certificate in the certificate database of all subsystems (Certificate Manager, Registration Manager, and Data Recovery Manager) that trust this Registration Manager.

Here's what you must do:

Install the new signing certificate in the subsystems' certificate databases.

Because the Registration Manager uses its signing certificate for SSL client authentication to the subsystems, you must add the new signing certificate to the internal database of all subsystems that have been configured to receive requests from the Registration Manager.

To add the new certificate to a subsystem's internal database:

Note the instance ID and host name of the Registration Manager for which you got the new signing certificate; this information will help you to identify the Registration Manager in a subsystem's list of privileged users.

Copy the new signing certificate, in base-64 encoded format, to a text file.

Add the new certificate to the individual subsystem's internal database following the instructions in "Changing a Privileged User's Certificate". Repeat this step for all subsystems that receive requests from this Registration Manager.

Ensure that the CA that signed the Registration Manager's certificate is in the certificate database of the subsystem.

When a Registration Manager does SSL client authentication using its new certificate, the subsystem, as a part of validating the certificate presented by the Registration Manager, checks its trust database for the CA (certificate) that signed the Registration Manager's new certificate. If the subsystem does not find the CA as a trusted CA in its trust database, it rejects the Registration Manager.

For instructions on checking the trust database of a subsystem, see "Viewing the Certificate Database Contents".

If you don't find the CA certificate, add it to the database as a trusted CA. For instructions on adding a CA certificate to the trust database of a subsystem, see "Installing a New CA Certificate in the Certificate Database".

If you find the CA certificate, verify its trust status. If it is untrusted, change the status to trusted. For instructions on changing the trust setting of a CA certificate, see "Changing the Trust Settings of a CA Certificate".

Deploying Data Recovery Manager's Transport Certificate

Because clients capable of generating dual key pairs use the transport certificate for encrypting end users' encryption private keys before sending them to the Data Recovery Manager, you must update the appropriate enrollment or key archival page to identify and use the new transport certificate. Otherwise, the Data Recovery Manager will fail to archive users' encryption private keys.

In general, here's what you need to do:

Locate the enrollment page that embeds the key archival feature.

View the HTML source, and identify the parameter that corresponds to the Data Recovery Manager's transport certificate.

The default enrollment forms for end users embed this feature. Figure 8.2 shows the default directory-based user enrollment form with the transport certificate-related information highlighted. (For more information, see "Step 3. Customize the Certificate Enrollment Form".)

Figure 8.2 Data Recovery Manager's transport certificate information in the default enrollment form

Replace the current MIME-64 string with the one for the new transport certificate.

To copy the MIME-64 string for the new transport certificate, locate the new transport certificate; the MIME-64 string for the certificate will be listed there.

Repeat steps 1 through 3 for any additional enrollment or key archival pages.

Deploying a Subsystem's SSL Server Certificate

To configure the server to use this certificate for authenticating to one of the clients, see "Configuring the Server to Use Separate SSL Server Certificates". To configure the Certificate Manager to use this certificate for authenticating to the publishing directory, see "Identifying a Certificate Manager's Publishing Directory". To configure the Registration Manager to use this certificate for authenticating to the publishing directory, see "Identifying a Registration Manager's Publishing Directory".

Renewing Certificates for the Subsystems

All certificates used by Certificate Management System have a validity period beyond which they are not usable, unless the validity period is extended. For Certificate Management System to function properly, you must renew the certificates used by the Certificate Manager, Registration Manager, or Data Recovery Manager before they expire. For example, if you generated these certificates during CMS installation with a validity period of two years, at the end of which they will all expire; you must consider renewing them well in advance, maybe two months in advance.

When you renew a certificate, you get a new certificate with the same public and private key material as the existing certificate, but with a new name or an extended validity period, or both.

The sections that follow explain how to renew certificates for the Certificate Manager, Registration Manager, and Data Recovery Manager using the Certificate Setup Wizard. Alternatively, you use the command-line utility called the Certificate Database Tool; for details about this utility, see Appendix D, "Certificate Database Tool".

Renewing an existing certificate involves the following:

Step 1. Plan for Certificate Renewal

Step 2. Renew the Existing Certificate

Step 3. Install the Renewed Certificate

Step 4. Deploy the Renewed Certificate

Step 1. Plan for Certificate Renewal

Renewing a subsystem's certificate requires careful planning. This section provides some guidelines that will help you renew the certificate smoothly.

Before renewing a certificate:

Note the subject DN and nickname of the certificate you want to renew.

If you are planning on renewing the CA signing certificate of a Certificate Manager, make sure that the Certificate Manager has updated your LDAP directory with the most current certificate information (see "Configuring a Certificate Manager for LDAP Publishing") and CRL (see "Configuring a Certificate Manager for Publishing CRLs").

When you renew its CA signing certificate, the Certificate Manager automatically formulates a new certificate with the same public key and other details from the existing certificate, and publishes the new CA certificate to your LDAP directory.

Identify the token, internal or external, that contains the keys for the certificate you want to renew. To use an existing token, you must know the password that protects the token. If the token is external, make sure that the token is installed properly; see "Installing External Tokens".

Decide on the validity period of the renewed certificate.

Decide on the CA that will sign the certificate. If you want the certificate to be signed by a public CA, find out what information you need to provide with the certificate request. If you want the certificate to be signed by an internally deployed CA, check to be sure it can issue the certificate you want to request.

Find out how long the CA will take to deliver the certificate to you. Make sure the renewed certificate is delivered to you well in advance so that you have a buffer period for installing and testing the renewed certificate, before the current certificate expires.

Find out how the certificate will be delivered to you; the most common delivery mechanism is email. Make appropriate arrangements to receive the certificate.

If you want to renew a subordinate CA certificate, plan how you will deploy the renewed CA certificate to end entities that rely on this certificate for validation.

If you want to renew a root CA certificate, plan how you will deploy the renewed root CA certificate in your enterprise.

Step 2. Renew the Existing Certificate

Once you have all the information, go ahead and renew the certificate. The Certificate Setup Wizard built into the CMS window automates the process of renewing certificates used by the Certificate Manager, Registration Manager, and Data Recovery Manager. The wizard can generate a certificate request based on the existing key pair and submit the request to a CA for signing. For instructions on using the wizard, see "Using the Wizard to Request a Certificate".

Important Be sure to use the existing key pair to generate the certificate signing request.

Step 3. Install the Renewed Certificate

When you receive the renewed certificate from the CA, you must install it in the token that contains the key pair for the certificate; this is the token you used to generate the request in Step 2.

The Certificate Setup Wizard automates the process of installing certificates used by the Certificate Manager, Registration Manager, and Data Recovery Manager. For instructions on using the wizard, see "Using the Wizard to Install a Certificate or Certificate Chain".

Step 4. Deploy the Renewed Certificate

In this step, you must follow the instructions appropriate for the certificate you installed:

If you installed a renewed CA signing certificate for a Certificate Manager, see "Deploying Certificate Manager's Renewed CA Signing Certificate".

If you installed a renewed signing certificate for a Registration Manager, see "Deploying Registration Manager's Renewed Signing Certificate".

If you installed a renewed Data Recovery Manager transport certificate, see "Deploying Data Recovery Manager's Renewed Transport Certificate".

If you installed a new SSL server certificate, see "Deploying a Subsystem's Renewed SSL Server Certificate".

Deploying Certificate Manager's Renewed CA Signing Certificate

If you installed a new CA signing certificate, deploy it in the PKI environment that depends on this certificate for validation. It is beyond the scope of this book to explain how you should deploy the new CA certificate. You may find it useful to go over some of the deployment issues discussed in the document available at this URL:

http://help.netscape.com/kb/server/980710-25.html

Deploying Registration Manager's Renewed Signing Certificate

Here's what you must do:

Install the renewed signing certificate in the subsystem's certificate database.

Because the Registration Manager uses its signing certificate for SSL client authentication to the subsystems, you must add the renewed signing certificate to the internal database of all subsystems that have been configured to receive requests from the Registration Manager.

To add the renewed certificate to a subsystem's internal database:

Note the instance ID and host name of the Registration Manager for which you got the signing certificate; this information will help you to identify the Registration Manager in a subsystem's list of privileged users.

Copy the renewed signing certificate, in base-64 encoded format, to a text file.

Add the renewed certificate to the individual subsystem's internal database following the instructions in "Changing a Privileged User's Certificate". Repeat this step for all subsystems that receive requests from this Registration Manager.

Ensure that the CA that signed the Registration Manager's certificate is in the trust database of the subsystem.

When a Registration Manager does SSL client authentication using its renewed certificate, the subsystem, as a part of validating the certificate presented by the Registration Manager, checks its trust database for the CA (certificate) that signed the Registration Manager's renewed certificate. If the subsystem does not find the CA as a trusted CA in its trust database, it rejects the Registration Manager.

For instructions on checking the trust database of a subsystem, see "Viewing the Certificate Database Contents".

If you don't find the CA certificate, add it to the database as a trusted CA. For instructions on adding a CA certificate to the trust database of a subsystem, see "Installing a New CA Certificate in the Certificate Database".

If you find the CA certificate, verify its trust status. If it is untrusted, change the status to trusted. For instructions on changing the trust setting of a CA certificate, see "Changing the Trust Settings of a CA Certificate".

Deploying Data Recovery Manager's Renewed Transport Certificate

Because clients capable of generating dual key pairs use the transport certificate for encrypting end users' encryption private keys before sending them to the Data Recovery Manager, you must update the appropriate enrollment or key archival page to identify and use the renewed transport certificate. Otherwise, the Data Recovery Manager will fail to archive users' encryption private keys.

In general, here's what you need to do:

Locate the page that embeds the key archival feature.

View the HTML source, and identify the parameter that corresponds to the Data Recovery Manager's transport certificate.

The default enrollment forms for end users embed this feature. Figure 8.3 shows the default directory-based user enrollment form with the transport certificate-related information highlighted. (For more information, see "Step 3. Customize the Certificate Enrollment Form".)

Figure 8.3 Data Recovery Manager's transport certificate information in the default enrollment form

Replace the current MIME-64 string with the one for the renewed transport certificate.

To copy the MIME-64 string for the renewed transport certificate, locate the certificate; the MIME-64 string for the certificate will be listed there.

Repeat steps 1 through 3 for any additional key archival or enrollment pages.

Deploying a Subsystem's Renewed SSL Server Certificate

By default, a Certificate Manager and Registration Manager use a single SSL server certificate to do server-side authentication to all the CMS ports. If configured for LDAP publishing, they also use the SSL server certificate for authenticating to the publishing directory. The Certificate Manager, if configured to function as a trusted manager to a Data Recovery Manager, also uses its SSL server certificate for SSL client authentication to the Data Recovery Manager. Depending on the purpose for which the certificate being renewed is used currently, you should configure the server appropriately.

To configure the server to use this certificate for authenticating to one of the clients, see "Configuring the Server to Use Separate SSL Server Certificates".

To configure the Certificate Manager to use this certificate for authenticating to the publishing directory, see "Identifying a Certificate Manager's Publishing Directory".

To configure the Registration Manager to use this certificate for authenticating to the publishing directory, see "Identifying a Registration Manager's Publishing Directory".

Managing the Certificate Database

Each CMS instance has a certificate database (cert7.db), which is maintained in its internal token. This database contains certificates belonging to the subsystems installed in the CMS instance (for details, see "Keys and Certificates for the Main Subsystems") and various CA certificates the subsystems use for validating the certificates they receive.

Whether you use an internal token or an external token for generating and storing key pairs, Certificate Management System always maintains its list of trusted and untrusted CA certificates in its internal token.

You may need to add new certificates to the database, remove unwanted certificates from the database, or change the trust settings of CA certificates in the database. This section explains how to view the contents of the certificate database, delete unwanted certificates, and change the trust settings of CA certificates installed in the database using the CMS window. For information on adding certificates to the database, see "Certificate Setup Wizard".

Note Certificate Management System provides a command-line utility called certutil for managing its certificate database. See Appendix D, "Certificate Database Tool".

Viewing the Certificate Database Contents

Each CMS instance has a certificate database that contains the list of certificates the server uses.

To view the contents of the database:

Access the CMS window (see "Accessing the CMS Window").

Click the Configuration tab, and then in the right pane, click the Encryption tab.

Click Manage Certificate.

The Certificate Database Management window appears.

The window lists the certificates in a table, with each certificate occupying a row. The CA certificates are listed in alphabetical order. If the database contains multiple CA certificates with the same nickname, they are sorted by their validity periods; the most recently requested certificate is placed at the top.

For each certificate, you see the following information:

Certificate Name.

Specifies the nickname of the CA certificate.

Expiry Date. specifies the date (and time) on which the CA certificate expires.

Trust Status. Specifies whether the CA is trusted or untrusted. To change the trust setting, see "Changing the Trust Settings of a CA Certificate".

Deleting a Certificate from the Certificate Database

By default, the CMS certificate database includes a few public or third-party CA certificates. As an administrator, you should periodically check the contents of the certificate database and make sure that it doesn't include any unwanted CA certificates. For example, if the database includes CA certificates that you don't ever want to trust in your PKI setup, you should delete them.

Removing unwanted certificates also reduces the size of the certificate database.

Important When deleting CA certificates from the certificate database, be careful not to delete the intermediate CA certificates, which help a subsystem chain up to the trusted CA certificate. If in doubt, leave the certificates in the database as untrusted CA certificates; see "Changing the Trust Settings of a CA Certificate".

To delete a CA certificate from the certificate database:

Access the CMS window (see "Accessing the CMS Window").

Click the Configuration tab, and then in the right pane, click the Encryption tab.

Click Manage Certificate.

The Certificate Database Management window appears. The window lists all the certificates for the selected instance of Certificate Management System; the list is a table, with each certificate occupying a row.

Select the CA certificate you want to delete, and click Delete.

When prompted, confirm the delete action.

Click Close.

You are returned to the Encryption tab.

To save your changes, click Save.

The CMS configuration is modified. If the changes you made require you to restart the server, you will be prompted accordingly. In that case, restart the server.

Changing the Trust Settings of a CA Certificate

Certificate Management System relies on CA certificates in its certificate database for validating certificates it receives during an SSL communication. For example, when a Certificate Manager is authenticating a Registration Manager that has sent a certificate signing requests, the Certificate Manager checks its certificate database to see whether the CA that signed the certificate presented by the Registration Manager is included in the database as a trusted CA.

You may need to change the status of a currently trusted CA to untrusted (or vice versa) temporarily or permanently. For example, you may be notified that a CA is experiencing technical difficulty that prevents certificate authentication. By making the CA certificate untrusted, you can prevent entities whose certificates have been signed by that CA from successfully authenticating to Certificate Management System. You can then return the trust option to trusted when the CA notifies you that the problem has been resolved.

If you want to untrust a CA permanently, you should consider removing its certificate from the trust database altogether. See "Deleting a Certificate from the Certificate Database".

Changing the trust setting changes the trust flag (or bit) in the CA certificate.

To change the trust setting of a CA certificate:

Access the CMS window (see "Accessing the CMS Window").

Click the Configuration tab, and then in the right pane, click the Encryption tab.

Click Manage Certificate.

The Certificate Database Management window appears.

The window lists the CA certificates currently installed for the selected CMS instance; the list is a table, with each CA certificate occupying a row.

Select the CA certificate whose trust setting you want to modify, and click Edit.

The Certificate Information window appears.

The window shows detailed information about the selected certificate, including serial number, validity period, subject name, issuer name, certificate fingerprint, and trust status.

If the certificate you selected is currently trusted, the window shows a button named "Change to Untrusted." If it is untrusted, the window shows a button named "Change to Trusted."

Click Change to Untrusted or Change to Trusted, as appropriate.

Click Close.

You are returned to the Certificate Database Management window. The certificate now shows a different trust status.

Click Close.

You are returned to the Encryption tab.

To save your changes, click Save.

The CMS configuration is modified. If the changes you made require you to restart the server, you will be prompted accordingly. In that case, restart the server.

Installing a New CA Certificate in the Certificate Database

You may need to install new trusted CA certificates in the certificate database of a CMS instance. For example, assume that you renewed the signing certificate of a Registration Manager. Also assume that the CA that signed the Registration Manager's certificate is not included in the trust database of the Certificate Manager that has been configured to sign certificate requests from this Registration Manager.

When the Registration Manager attempts to request a service from the Certificate Manager (using the renewed certificate for SSL client authentication), the Certificate Manager fails to authenticate the Registration Manager. This happens because, as a part of validating the certificate presented by the Registration Manager, the Certificate Manager checks its certificate database for the CA that signed the Registration Manager's certificate. The Certificate Manager does not find the CA listed in its trust database as a trusted CA, so it rejects the Registration Manager's service request.

The Certificate Setup Wizard built into the CMS window automates the process of installing trusted CA certificates in the certificate database. For instructions on using the wizard, see "Using the Wizard to Install a Certificate or Certificate Chain".

Important Be sure to choose the "Other Trusted CAs" option in Step 2 in the wizard process.

Installing a CA Certificate Chain in the Certificate Database

Any client or server software that supports certificates maintains a collection of trusted CA certificates in its certificate database. These CA certificates determine which other certificates the software can validate--in other words, which issuers of certificates the software can trust. In the simplest case, the software can validate only certificates issued by one of the CAs for which it has a certificate. It's also possible for a trusted CA certificate to be part of a chain of CA certificates, each issued by the CA above it in a certificate hierarchy; for details on certificate hierarchies and certificate chains, see "How CA Certificates Are Used to Establish Trust" in Appendix D of Managing Servers with Netscape Console.