Previous     Contents     Index     Next     
iPlanet Certificate Management System Installation and Setup Guide



Chapter 14   Managing CMS Keys and Certificates


The main subsystems of iPlanet Certificate Management System (CMS)—the Certificate Manager, Registration Manager, Data Recovery Manager and Online Certificate Status Manager—use certificates for various purposes, including authentication during SSL-enabled communication. For example, when a Registration Manager forwards a certificate issuance request to a Certificate Manager for signing, the Certificate Manager expects the Registration Manager to have performed SSL client authentication before processing the request.

When you installed Certificate Management System, the installation program prompted you to generate the required certificates for the subsystems you chose to install. This chapter provides an overview of those certificates and it explains how to perform operations such as renewing the existing certificates before their validity period expires, getting new certificates for the subsystems, adding trusted CA certificates and certificate chains to the CMS trust database, and changing the trust setting of CA certificates. The chapter also explains the certificate Setup Wizard, which automates the process of requesting and installing CMS certificates.

The chapter has the following sections:



Keys and Certificates for the Main Subsystems

This section explains the various certificates required and used by the CMS managers:

The key pairs that correspond to certificates used by these subsystems can be stored either in an internal or an external token, or in both. It depends on the token you chose for the generation and storage of the keys and certificates. For information on tokens, see Tokens for Storing CMS Keys and Certificates.

As an administrator, you must make sure that the private keys that correspond to all certificates, especially the CA signing certificate, used by CMS managers are adequately protected. This includes protecting them from damage (in other words, by archiving and backing up the keys) as well as protecting them from unauthorized access or use. The passwords that protect the tokens containing these keys must also be carefully guarded. Access to the token itself should be limited.

  • If the keys are in the internal token (the key3.db file), make sure that only you or authorized administrators have access to this file. It's also important to know if the file is stored on backup tapes or is otherwise available for someone to intercept. Because the destruction of a private key in a disk crash can be disastrous if you are depending upon that key for a hierarchy of certificate authorities, backing up your key data is commensurately important. If you do make copies of your keys, however, you must protect your backups with the same level of security that you use for protecting your original keys.

  • If the keys are in an external token, such as a smart card, keep it in a locked facility. Also, periodically change the passwords that protect these keys. See Changing a Token's Password.

All CMS certificates have a validity period, as specified when the certificates were generated, beyond which they cannot be used. For a certificate to be valid beyond it's expiration date, it must ne renewed. For instructions to renew a CMS certificate, see section Renewing Certificates for the Subsystems.

All key pairs associated with CMS certificates must be well protected to ensure that they are never compromised. However, if you know or suspect that a key pair has been compromised, reissue the certificate with a new key pair. For instructions to get a new CMS certificate, see section Getting New Certificates for the Subsystems.


Certificate Manager's Key Pairs and Certificates

The Certificate Manager uses the following key pairs and corresponding certificates:


CA Signing Key Pair and Certificate

Every Certificate Manager you installed has a certificate, identified as the Certificate Manager CA signing certificate, whose public key corresponds to the private key the Certificate Manager uses to sign the X.509 certificates it issues. The first time you generated this certificate is when you installed the Certificate Manager. The default nickname for the certificate is caSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed, and the default validity period for the certificate is two years.

The subject name of the CA signing certificate reflects the name of your certificate authority (CA) as specified during the installation. All certificates signed or issued by the Certificate Manager include this name to identify the issuer of the certificate.

The Certificate Manager's status as a root or subordinate CA is determined by whether its CA signing certificate is self-signed or is signed by another CA.

  • If the Certificate Manager is a root CA, its CA signing certificate is self-signed—that is, the subject name and issuer name of the certificate is the same.

  • If the Certificate Manager is a subordinate CA, its CA signing certificate is signed by another CA, usually the one that is a level above in the CA hierarchy (which may or may not be a root CA). If you have deployed the Certificate Manager as a subordinate CA in a CA hierarchy, you must import your root CA's signing certificate into individual clients and servers before you can use the Certificate Manager to issue certificates to them.


    Note You cannot change the CA name; doing so would make all previously issued certificates invalid. Similarly, reissuing a Certificate Manager's CA signing certificate with a new key pair invalidates all certificates that have been signed by the old key pair.



wTLS CA Signing Certificate

During the installation of a Certificate Manager, you're given the option to enable issuance of Wireless Transport Layer Security (wTLS)-compliant certificates for use with wireless applications. If you chose to enable this option, the Installation Wizard transparently generates a wTLS CA signing certificate.

Note that for the wTLS CA signing certificate, the wizard does not generate a separate key pair. Instead, it uses the same key pair that you generated for the CA signing certificate, which is explained in section CA Signing Key Pair and Certificate. The subject name and validity period of the wTLS CA signing certificate will be the same as the one you specified for the CA signing certificate. The Certificate Manager uses the private key (that corresponds to the public key used to generate the wTLS CA signing certificate) to sign both X.509 and wTLS certificates it issues.


OCSP Signing Key Pair and Certificate

During the installation of a Certificate Manager, you're given the option to enable its OCSP-service feature. This feature enables the Certificate Manager to function as an OCSP responder, enabling OCSP-compliant clients to query the Certificate Manager for the revocation status of certificates issued by the Certificate Manager. For more information about an OCSP responder and setting up a Certificate Manager to function as an OCSP responder, see Chapter 21 "Setting Up an OCSP Responder."

Irrespective of whether you chose to enable the OCSP service feature, the Installation Wizard transparently generates a key pair and a corresponding certificate identified as the OCSP signing certificate. The reason for generating this certificate even if you chose to not enable the OCSP service is that you can enable the OCSP service feature in the CMS window after installation. This way, if you decide to enable the feature in a future date, you wouldn't have to go through the process of requesting an OCSP signing certificate.

Note that for generating the OCSP signing key pair, the wizard uses some of the information you provide for the CA signing key pair, which is explained in section CA Signing Key Pair and Certificate. The key type, key size, key algorithm, and validity period of the OCSP signing certificate is the same as the one you specified for the CA signing key pair. The subject name of the OCSP signing certificate is in the form CN=OCSP cert-<cms_instance_id>, and it contains extensions, such as OCSPSigning and OCSPNoCheck, required for signing OCSP responses.

The Certificate Manager uses the private key (that corresponds to the public key used to generate the OCSP signing certificate) to sign the OCSP responses it sends to the OCSP-compliant clients when queried about the revocation status of certificates. The Certificate Manager's signature provides persistent proof to the client that the Certificate Manager has processed the request.

The default nickname for the OCSP signing certificate is
ocspSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed.


CRL Signing Key Pair and Certificate

By default, a Certificate Manager you have installed uses the same key pair, the one that corresponds to the CA signing certificate explained in CA Signing Key Pair and Certificate, for signing certificates and certificate revocation lists (CRLs). For details about CRLs, see What's a CRL?.

If you want a Certificate Manager to use a separate key pair for signing the CRL it generates, you can do so after installation. The instructions are provided below. Note that a Certificate Manager's CRL signing certificate must be signed or issued by itself; make sure you submit the request to the Certificate Manager itself.

  1. Request and install a CRL signing certificate for the Certificate Manager. To do this, you may use either of these options:

    • Use the Certificate Setup Wizard available within the CMS window.

    • Use the Key Database (keyutil) tool to generate a key pair, the Certificate Database (certutil) tool to request a certificate for the key pair and install the certificate in the Certificate Manager's certificate database. For more information about the Key Database and Certificate Database tools, see CMS Command-Line Tools Guide.

    To request and install a CRL signing certificate for a Certificate Manager using its Certificate Setup Wizard, follow these instructions:

    1. Log in to iPlanet Console; see Logging In to iPlanet Console.

    2. Locate the CMS instance for the Certificate Manager, make sure it's started, and then log in to the CMS window of the Certificate Manager.

    3. Select the Configuration tab, and then select the Encryption tab.

    4. Click the Certificate Setup Wizard button to launch the wizard, which is explained in Certificate Setup Wizard.

    5. Select the option to request a certificate and then follow the on-screen prompts to generate a certificate request for the CRL signing certificate—in the Certificate Selection window, select Other and specify caCrlSigning as the certificate type in the associated text field.

    6. Once you have the certificate request ready, submit it to the Certificate Manager so that it can issue a certificate—in the request submission screen of the wizard, use the auto-submission feature by entering the Certificate Manager's hostname and port number so that the request gets added to the Certificate Manager's agent queue. For general instructions to use the wizard to request a certificate, see section Using the Wizard to Request a Certificate.

    7. Log in to the Agent Services interface, check the request for required extensions. For example, the CRL signing certificate must contain the Key Usage extension with the crlSigning bit set. (By default, the Certificate Manager's policy is configured to add the Key Usage extension with correct bits to the CRL signing certificate; see the policy rule named CRLSignCertKeyUsageExt, which is an instance of KeyUsageExt plug-in.)

    8. Approve the request.

    9. Once you have the CRL signing certificate ready, restart the wizard and install the certificate in the Certificate Manager's database. For general instructions to use the wizard to add a certificate, see Using the Wizard to Install a Certificate or Certificate Chain.

  2. After you've installed the certificate successfully, go to the Tasks tab and stop the Certificate Manager.

  3. Update the Certificate Manager's configuration to recognize the new key pair and certificate.

    1. In the Certificate Manager host machine, go to this directory: <server_root>/cert-<instance_id>/config

    2. Open the configuration file (CMS.cfg) in a text editor.

    3. Add the following lines to the configuration file:

      ca.crl_signing.cacertnickname=<nickname> cert-<instance_id>
      ca.crl_signing.defaultSigningAlgorithm=<signing_algorithm>
      ca.crl_signing.tokenname=<token_name>

    4. Edit the lines as below. Replace

      <nickname> with the name assigned to the CRL signing certificate.
      <instance_id> with the name assigned to the Certificate Manager instance.

      <signing_algorithm> with MD5withRSA, MD2withRSA, or SHA1withRSA, if the key type is RSA, or SHA1withDSA, if the key type is DSA.

      <token_name> with the name of the token used for generating the key pair and the certificate. If you used the internal/software token, use Internal Key Storage Token as the value.

      For example, your edited entries might look like this:

      ca.crl_signing.cacertnickname=crlSigningCert cert-demoCA
      ca.crl_signing.defaultSigningAlgorithm=MD5withRSA
      ca.crl_signing.tokenname=Internal Key Storage Token

    5. Save your changes and close the file.

  4. Restart the Certificate Manager. Now the Certificate Manager is ready to use the CRL signing certificate to sign the CRLs it generates.


SSL Server Key Pair and Certificate

Every Certificate Manager you have installed has at least one SSL server certificate. The first time you generated this certificate is when you installed the Certificate Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed.

The Certificate Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to the Certificate Manager itself, another internally deployed CA, or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.

The Certificate Manager uses its SSL server certificate to do SSL server-side authentication to the following:

  • The End-Entity Services interface (the HTTPS port)

  • The Certificate Manager Agent Services interface

  • Clone Certificate Managers, when used as a master Certificate Manager in a cloned CA setup (see Cloning a Certificate Manager)

By default, the Certificate Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Certificate Manager. For example, you can configure the Certificate Manager to use separate server certificates for authenticating to the End-Entity Services interface and Agent Services interface. For instructions, see Configuring the Server to Use Separate SSL Server Certificates.

If you configure the Certificate Manager for SSL-enabled communication with a publishing directory, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the publishing directory. This is the default configuration. You can configure the Certificate Manager to use an alternate certificate for this purpose; see Getting an SSL Client Certificate for a Subsystem.

If you configure the Certificate Manager to function as a trusted manager to a Data Recovery Manager, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the Data Recovery Manager. For details on trusted managers, see Trusted ManagersYou can also configure the Certificate Manager to use an alternate certificate for this purpose; see Getting an SSL Client Certificate for a Subsystem.


Note If you have installed the Certificate Manager with a Data Recovery Manager, both subsystems use the same SSL server certificate.



Remote Administration Server Certificate

Netscape Console (version 4.2) does not support the DSA key algorithm. To workaround this problem, during the installation of a Certificate Manager, the Installation Wizard transparently generates an SSL server certificate identified as the Remote Administration Server Certificate. The Certificate Manager uses the certificate for SSL server authentication to the remote administration interface, Netscape Console. The certificate is self-signed, and is generated with RSA key type and a key size of 512 bits. The validity period of the certificate is set to the same validity period that you chose for the SSL server certificate, which is used by the Certificate Manager for SSL server authentication to its HTTP interfaces; see SSL Server Key Pair and Certificate.

Note that the remote administration server certificate is not listed in the internal database, and thus, you'll not be able to list or search for it in the Retrieval tab of the Certificate Manager's end-entity interface. However, you'll see the certificate if you use the command-line tool, Certificate Database Tool (certutil) to list certificates in the Certificate Manager's certificate database (the cert7.db file):

  • The nickname for the certificate is
    Remote Admin Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed.

  • The CN component in both the subject name and issuer name of the certificate is set to CN=SSLserver cert-<instance_id>.

Like any certificate, the remote administration server certificate has a validity period. You must renew the certificate before it expires. For instructions to renew a certificate, see Renewing Certificates for the Subsystems.

Note that the "SSL Server for Remote Admin" option in the Certificate Setup Wizard allows you to renew the remote administration certificate by submitting the request to a CA only—it doesn't allow you to renew the certificate as a self-signed one (as done during installation). If the CA signing certificate of the CA to which you submit the renewal request is based on the DSA key algorithm, then resulting certificate will be unusable because Netscape Console doesn't support the DSA algorithm.

If you want to self sign the certificate, you must use certutil and keyutil tools to extract the key ID from the key database first and the generate a certificate for the key. The steps below outline how to use these tools to renew the certificate. Be sure to check the CMS Command-Line Tools Guide for details on certutil and keyutil tools to customize your commands to suit your requirements.

  1. Note the name (also called nickname) of the remote administration SSL server certificate; the default name is
    Remote Admin Server-Cert cert-<instance_id>.

  2. Stop Certificate Management System.

  3. Open a command window.

  4. Go to this directory: <server_root>/cert-<instance_id>/config

  5. Enter the command below, replacing <certname> with the name of the remote administration SSL server certificate. You may use the -h <tokenname> argument to specify whether the certificate database is on a particular hardware or software token.

    certutil -L -n "<certname>"

    For example, your command might look like this:

    certutil -L -n "Remote Admin Server-Cert cert-firefly"

    You should see detailed information about the remote administration SSL server certificate.

  6. Locate the "Subject Public Key Info:" section and then the Modulus section. For example:

    RSA Public Key:
          Modulus:
             00:f6:9e:71:37:62:af:7c:46:af:cb:bf:1e:d8:1a:
             64:0b:5e:71:e2:d8:ec:88:18:6d:eb:32:65:6f:f2:
             18:4b:ef:b3:70:ae:61:de:6f:21:d5:4e:0e:7b:9b:
             b7:42:98:94:1c:d7:46:42:53:39:db:10:07:6c:b8:
             75:7e:94:18:b5

  7. Note the second and third byte (f69e in the above example) in the modulus; this is the short key ID for the certificate.

  8. Delete the certificate you want to renew.

  9. Run the certutil command again to regenerate the certificate for the correct key and to add the resulting certificate to the database. Be sure to use the same name for the certificate and to add the required certificate extensions, such as the Key Usage extension. A sample command syntax is below:

    certutil -S -k <shortkeyID> -y rsa|dsa -n "<certname>"
    -s "<subject>" -t "<trustargs>" -x -m <serial-number>
    -v <valid-months> -d <certdir> -1)

    For example, your command might look like this:

    certutil -S -k f69e -y rsa -n "Remote Admin Server-Cert
    cert-firefly" -s "cn=SSLserver cert-firefly" -t "u,u,u" -x -m 3
    -v 12 -d . -1

  10. Restart Certificate Management System.


Registration Manager's Key Pairs and Certificates

The Registration Manager uses the following certificates:


Signing Key Pair and Certificate

Every Registration Manager you have installed has a certificate, identified as the Registration Manager signing certificate, whose public key corresponds to the private key the Registration Manager uses to sign certificate requests before sending them to the Certificate Manager for signing. The Registration Manager's signature provides persistent proof to the Certificate Manager that the Registration Manager has processed the request. The first time you generated this certificate is when you installed the Registration Manager. The default nickname for the certificate is raSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Registration Manager is installed.

The Registration Manager's signing certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to an internally deployed CA or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.

If you configure the Registration Manager to function as a trusted manager to another subsystem, the Registration Manager uses its signing certificate for SSL client authentication to the subsystem; this is the default configuration. For details, see Trusted Manager's Certificate for SSL Client Authentication.


SSL Server Key Pair and Certificate

Every Registration Manager you have installed has at least one SSL server certificate. The first time you generated this certificate is when you installed the Registration Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Registration Manager is installed.

The Registration Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to an internally deployed CA or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.

The Registration Manager uses its SSL server certificate to do SSL server-side authentication to the following:

  • The end entity services interface (the HTTPS port)

  • The Registration Manager Agent Services interface

By default, the Registration Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Registration Manager. For example, you can configure the Registration Manager to use separate server certificates for authenticating to iPlanet Console, the end entity services interface, and the Registration Manager Agent Services interface. For instructions, see Configuring the Server to Use Separate SSL Server Certificates.


Note If you installed the Registration Manager with a Data Recovery Manager, both subsystems use the same SSL server certificate.



Remote Administration Server Certificate

Similar to the Certificate Manager, the Registration Manager too has a remote administration server certificate. For details, see Remote Administration Server Certificate.


Data Recovery Manager's Key Pairs and Certificates

The Data Recovery Manager uses the following key pairs and certificates:


Transport Key Pair and Certificate

Every Data Recovery Manager you have installed has a Data Recovery Manager transport certificate. The public key of the key pair that is used to generate the transport certificate is used by the client software to encrypt an end user's encryption private key before it is sent to the Data Recovery Manager for archival; only those clients capable of generating dual-key pairs (one for signing and one for encryption) use the transport certificate. For more information on how this certificate is used, see Key Archival Process.

The first time you generated this certificate is when you installed the Data Recovery Manager. The default nickname for the certificate is
kraTransportCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Data Recovery Manager is installed.

The transport certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to the Certificate Manager that is installed in the same instance, internally deployed another CA, or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.


Storage Key Pair

Every Data Recovery Manager you have installed has a Data Recovery Manager storage key pair. The first time you generated this key pair is when you installed the Data Recovery Manager.

The Data Recovery Manager uses the public component of this key pair to encrypt (or wrap) end users' encryption private keys during the key archival operation; it uses the private component to decrypt (or unwrap) the archived key during the recovery operation. That is, the public key is used to encrypt the key repository the server uses to store end users' encryption private keys. For more information on how this key pair is used, see Chapter 22 "Setting Up Key Archival and Recovery."

Note that the public component of the storage key pair is not certified; there is no certificate that corresponds to the public key.

Keys encrypted with the storage key can be retrieved only by authorized key recovery agents. For details, see Key Recovery Agents and Their Passwords.


SSL Server Key Pair and Certificate

Every Data Recovery Manager you have installed has at least one SSL server certificate. The first time you generated this certificate is when you installed the Data Recovery Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Data Recovery Manager is installed.

The Data Recovery Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to the Certificate Manager that is installed in the same instance, an internally deployed CA, or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.

The Data Recovery Manager uses its SSL server certificate to do SSL server-side authentication to the following:

  • The end entity services interface (the HTTPS port)

  • The Data Recovery Manager Agent Services interface

By default, the Data Recovery Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Data Recovery Manager. For example, you can configure the Data Recovery Manager to use separate server certificates for authenticating to iPlanet Console, the end entity services interface, and the Data Recovery Manager Agent Services interface. For instructions, see Configuring the Server to Use Separate SSL Server Certificates.


Note If you installed the Data Recovery Manager with a Certificate Manager or Registration Manager, both subsystems use the same SSL server certificate.



Remote Administration Server Certificate

Similar to the Certificate Manager and Registration Manager, the Data Recovery Manager too uses a remote administration server certificate. For details, see section Remote Administration Server Certificate.


Online Certificate Status Manager's Key Pairs and Certificates

The Online Certificate Status Manager uses the following certificates:


OCSP Signing Key Pair and Certificate

Every Online Certificate Status Manager you have installed has a certificate, identified as the Online Certificate Status Manager signing certificate, whose public key corresponds to the private key the Online Certificate Status Manager uses to sign OCSP responses before sending them to OCSP-compliant clients. The Online Certificate Status Manager's signature provides persistent proof to an OCSP-compliant client that the Online Certificate Status Manager has processed the request. The first time you generated this certificate is when you installed the Online Certificate Status Manager. The default nickname for the certificate is ocspSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Online Certificate Status Manager is installed.

The Online Certificate Status Manager's signing certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to an internally deployed CA or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.


SSL Server Key Pair and Certificate

Every Online Certificate Status Manager you have installed has at least one SSL server certificate. The first time you generated this certificate is when you installed the Online Certificate Status Manager. The default nickname for the certificate is Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Online Certificate Status Manager is installed.

The Online Certificate Status Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to an internally deployed CA or a public CA. To find out the issuer name, follow the instructions in Viewing the Certificate Database Content.

The Online Certificate Status Manager uses its SSL server certificate to do SSL server-side authentication to the Online Certificate Status Manager Agent Services interface.

By default, the Online Certificate Status Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Online Certificate Status Manager. For example, you can configure the Online Certificate Status Manager to use separate server certificates for authenticating to iPlanet Console and the Online Certificate Status Manager Agent Services interface. For instructions, see Configuring the Server to Use Separate SSL Server Certificates.


Remote Administration Server Certificate

Similar to the Certificate Manager and Registration Manager, the Online Certificate Status Manager too uses a remote administration server certificate. For details, see section Remote Administration Server Certificate.



Tokens for Storing CMS Keys and Certificates


A token is a hardware or software device that performs cryptographic functions and optionally stores public-key certificates, cryptographic keys, and data defined by the application using the cryptographic services. Alternatively, a token can also be considered as a device that you can use to generate and store your key pairs and corresponding certificates.

Certificate Management System defines two types of tokens, internal and external, for storing key pairs and certificates that belong to the Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager.


Note Only those who have the password that protects a token can access it. For information on changing the password that protects a token, use the command-line utility called the Key Database Tool, which is explained in the CMS Command-Line Tools Guide.



Internal Token

An internal (software) token refers to a pair of software files, usually called certificate database and key database, that Certificate Management System uses to generate and store its key pairs and certificates. Certificate Management System automatically generates these files in the file system of its host machine when you choose to use the internal token for the first time. These files were created for you during CMS installation if you chose to use the internal token for key-pair generation.

In the CMS host system, the certificate database is identified by the name cert7.db; the key database is identified by the name key3.db. You can find both these files at this location: <server_root>/cert-<instance_id>/config


External Token

An external (hardware) token refers to an external hardware device, such as a smart card, FORTEZZA card, or other crypto card, that Certificate Management System uses to generate and store its key pairs and certificates. If you haven't already done so, consider using external tokens for generating and storing the key pairs and certificates used by Certificate Management System. These devices represent another security measure you can take to safeguard private keys because hardware tokens are sometimes considered more secure than software tokens. For additional details, check the literature provided by hardware-token vendors.



Installing External Tokens


Certificate Management System supports any hardware tokens that are compliant with PKCS#11 version 2.01. For details, see the information provided at this URL:

http://developer.netscape.com/support/faqs/pkcs_11.html

Certificate Management System also supports FIPS 140-1 Level 2 Security requirements, and it supports Level 3 Security requirements on Hardware Security Modules (HSMs) such as those manufactured by Ncipher and Chrysalis.

Note For detailed information about FIPS 140-1 security levels and their requirements, see http://csrc.nist.gov/publications/fips/.


Both the Certificate Manager and Data Recovery Manager (DRM) can store keys in certified FIPS 140-1 Level 3 tokens. You can enable FIPS 140-1 Level 3 Support during installation. When this option is enabled, the DRM will not set the password on a hardware token device.

For more information, see the following:

  • For detailed information on configuring Certificate Server to work with HSMs, see "Configuring Certificate Server for FIPS 140-1 Level 3 Support."

  • For detailed information about other manufacturers' hardware tokens, see the manufacturer's website or token documentation.

  • For detailed information about FIPS 140-1 levels of support, see http://csrc.nist.gov/publications/fips/.


Installing Level 2 External Tokens

To use external encryption devices or tokens, you need to take the following steps:


Step 1. Install the Cryptographic Device

To install the drivers provided by the device manufacturer, follow the instructions that came with the device. When you install a hardware token, you are given an opportunity to name it; be sure to use a name that will help you identify the token later.


Step 2. Install the PKCS #11 Module

PKCS #11 is a standard set of APIs and shared libraries used by Netscape and a number of encryption vendors. PKCS #11 isolates an application from the details of the cryptographic device, thus enabling the application to provide a unified interface for PKCS #11-compliant cryptographic devices.

The PKCS #11 module implemented in Certificate Management System (in Netscape Administration Server) enables it to support cryptographic devices supplied by many different manufacturers. Specifically, it allows Certificate Management System to plug in shared libraries or DLLs supplied by manufacturers of external encryption devices and use them for generating and storing keys and certificates for the CMS managers.

There are two ways in which you can install a PKCS #11 module, by using the interface provided within iPlanet Console or by using the command-line utility named modutil. Both the methods are documented below.

  • To install the PKCS #11 module using iPlanet Console:

    1. Log in to the CMS window (see Logging In to the CMS Window).

    2. From the Console menu, choose Manage PKCS#11.

      The PKCS #11 Management window appears.

    3. Click Add.

      The Add PKCS #11 Module window appears.

    4. Enter information as appropriate. If you choose JAR as your file type, you are required to provide the path to the JAR file that contains the DLLs. If you choose DLL as your file type, in addition to the path to the DLL you are also required to provide a name for the module you're attempting to install (so as to help you identify it easily later). The sample in the figure shows how you would install an nCipherTM token.

      Pick DLL to add a UNIX shared/dynamic library, which on a Solaris machine is identified with the .so extension.

    5. Click OK.

  • To install the PKCS #11 module using the modutil tool:

    1. Locate the CMS instance for which you want to install the PKCS #11 module.

    2. Open a terminal window.

    3. Go to the configuration directory of Administration Server; it is located here: <server_root>/admin-serv/config

    4. At the prompt, enter this command:

      <server_root>/shared/bin/modutil -dbdir . -nocertdb
      -create

      This creates the required security module database file (secmod.db) in the configuration directory.

    5. At the prompt, enter this command:

      <server_root>/shared/bin/modutil -dbdir . -nocertdb
      -add <module_name> -libfile <library_file>

      <library_file> specifies the path to the DLL or other library file containing the implementation of the PKCS #11 interface module.

      <module_name> specifies the name of the PKCS #11 module (which you specified in Step 1 when you installed the drivers).

      For example, if you are installing a LitronicTM token, the command would look like this:

      <server_root>/shared/bin/modutil -dbdir . -nocertdb
      -add CryptOS -libfile core32

    6. Copy the new secmod.db (secmodule.db on Unix) to the following location: <server-root>/cert-<instance_id>/config/

      This overwrites the old secmod.db in this directory.


Installing Level 3 External Tokens

This document provide details for configuring SunTM ONE Certificate Server 4.7 to work with Hardware Security Modules (HSM) such as those manufactured by Ncipher and Chrysalis. Topics included in this document are:

For detailed information about FIPS 140-1 levels of support, see http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf.


Overview of Configuration Steps

Configuring support for FIPS 140-1 Level 3 security is a two-part process. For Part 1, see the documentation that comes with the HSM. For Part 2, this document provides detailed instructions.

  1. Install the HSM.

  2. Install and Configure Certificate Server.

    1. Install of Certificate Server.

    2. Link the HSM manufacturer's library to Certificate Server.

    3. Configure Certificate Server


Part 1: Install the HSM

For detailed instructions, see the documentation that comes with the HSM, or visit the manufacturer's website.

For detailed information about Ncipher HSM products, go to the Ncipher website at http://www.ncipher.com/safebuilder/codesafe_specs.html

For detailed information about Chysalis HSM products, go to the Chrysalis website at http://www.chrysalis-its.com/trusted_systems/luna_ca3.htm.


Part 2: Install and Configure Certificate Server

In this part, you run the Certificate Server setup program, and then you run the Installation Wizard to create the first administrator.


2a. Install Certificate Server.

  1. Run the Certificate Server installation script.

    • To run the installation script in Windows, open the distribution directory for the system software you are using and double-click the file setup.exe.

    • To run the installation script in Solaris, change to the distribution directory (where you have downloaded the distribution files) and execute the file setup.

  2. Proceed through the Setup program following the instructions in the Installation and Setup Guide. When you reach the end of the program, the first phase of the installation is complete.

Figure 14-1    The Windows version of the Setup program uses a GUI; the Solaris version is text-base.


2b. Link the HSM library to Certificate Server.
In this step, you create the security module database and then add the HSM to that database. The following instructions assume you're using tsch (Solaris) or cmd (Windows).

  1. Go to the admin server config directory of the CMS installation.

    Solaris:  #> cd <server-root>/admin-serv/config

    Windows:  D:\> cd <server-root>\admin-serv\config

  2. Set the LD_LIBRARY_PATH equivalent:

    Solaris:

      #> setenv LD_LIBRARY_PATH <server-root>/lib:$LD_LIBRARY_PATH

    Windows:

      D:\> set PATH=<server-root>\lib;%PATH%

  3. Create the Certificate Server db.

    Solaris:

      #> ../../shared/bin/modutil -dbdir . -nocertdb -create

    Windows:

      D:\> ..\..\shared\bin\modutil -dbdir . -nocertdb -create

  4. Link the HSM library to the Certificate Server db.

    Solaris:

      #> ../../shared/bin/modutil -dbdir . -nocertdb -add     <HSM-manufacturer> -libfile <libraries>/<library>.so

    where <libraries> is the location of the manufacturer's libraries and <library> is the name of the manufacturer's library file.

    Windows:

      D:\> ..\..\shared\bin\modutil -dbdir . -nocertdb -add Chrysalis     -libfile <libraries\library>.dll

    where <libraries> is the location of the manufacturer's dll libraries and <library> is the name of the manufacturer's dll file.

  5. Verify that the HSM tokens are now available:

    Solaris:

      #> ../../shared/bin/modutil -dbdir . -nocertdb -list

    Windows:

      D:\> ..\..\shared\bin\modutil -dbdir . -nocertdb -list


2c. Configure the Cryptographic Tokens.
In this step, you run the Installation Wizard to configure the cryptographic tokens.

  1. To begin running the Installation Wizard, follow these steps:

    1. If iPlanet Console is not running, start it.

    2. On a Windows NT system, click
      Start>Programs>iPlanet Server Products> iPlanet Console

      Alternatively, click the iPlanet Console shortcut in the iPlanet Server Products directory that opens on your desktop after setup completes.

    3. On a Unix system, open a command shell, change to the directory /usr/iPlanet/servers, and execute the file startconsole.

    4. Log in as admin, giving the password <admin password>.

    The main window of iPlanet Console appears. Enter your information, and then click OK.

  2. In the navigation tree at the left, open your computer, then open Server Group.

  3. Select Certificate Server and double-click it; alternatively, you can also click the Open button on the Certificate Management System panel on the right.

    After a few moments, the Installation Wizard appears. You use the wizard to get the initial certificates and set the initial configuration for this instance of Certificate Management System.

    Introduction. Click Next.

  4. Proceed through the Installation Wizard using the instructions in the Installation and Setup Guide until you get to the following screen:



    1. Determine whether you want to install a Data Recovery Manager subsystem. A Data Recovery Manager performs the long-term archival and recovery of private encryption keys for end entities. If you plan to store keys so that you can recover them in the event a key becomes lost, corrupt, or compromised, then check this box. This is highly recommended. If you do not plan to store keys, then leave the box unchecked.

    2. If you want to co-locate the Certificate Manager and Data Recovery Manager (install instances of both on the same host), then check both of their checkboxes.

    3. If you want to install the Data Recovery Manager as a stand-alone instance, you can uncheck the Certificate Manager.

  5. Continue with the Setup program following instructions in the Installation and Setup Guide until you get to a Key-Pair Information screen. Each time you are prompted for Key-Pair Information (see Figure 14-2), repeat this step. Provide the following information, and then click Next:

    Token: Choose the FIPS Level 3 hardware token that you specified when you installed the HSM.
    FIPS Level 3: Check this checkbox.
    Password (again): Enter the PIN/password for the configured token.
    Key type: Select a value.
    Key length: Select a value.

Figure 14-2   

A Key-Pair Information window.

  1. Proceed through Installation Wizard using the instructions in the Installation and Setup Guide until you get to the Storage Key Creation window (see Figure 14-3). Provide the following information, and then click Next:

    Token: Choose a FIPS 140-1 Level 3 token other than the one you spcified in the Key-Pair Information window.
    FIPS Level 3: Check this checkbox.
    Password: Enter the PIN/password for the configured token.
    Key type: Select a value.
    Key length: Select a value.

Figure 14-3   

The Storage Key Creation window.

  1. Proceed through the Installation Wizard using the instructions in the Installation and Setup Guide until you reach the end.

Keys stored in the HSM will now be used for issuing End Entity certificates.



Managing Tokens Used by the Subsystems


There are two main tasks involved in managing the tokens used by Certificate Management System:


Viewing Tokens

To view a list of the tokens currently installed for a CMS instance:

  1. Log in to the CMS window (see Logging In to the CMS Window).

  2. Select the Configuration tab, and then in the right pane, select the Encryption tab.

  3. In the Map To section, check the Token drop-down list.

    It shows the names (as specified when the tokens were installed) of external tokens installed for the currently selected CMS instance. For information on installing external tokens, see External Token.


Changing a Token's Password

The token, internal or external, that stores the key pairs and certificates for the subsystems is protected (encrypted) by a password. To decrypt the key pairs or to gain access to them, you must enter that password. The first time you specified this password is when you used the token the first time, most likely during CMS installation.

It is good security practice to periodically change the password that protects your server's keys and certificates; changing the password periodically minimizes the risk of someone finding out the password. To change a token's password, use the command-line utility called the Key Database Tool, which is documented in CMS Command-Line Tools Guide.

Note that the single sign-on password cache stores the passwords for tokens in order to start the server using a single password; for details, see Required Start-up Information. Whenever you change the password, the cache is updated with the new password.



Hardware Cryptographic Accelerators


Certificate Management System allows you to use hardware cryptographic accelerators with external tokens. Many of the accelerators provide the following security features:

  • Fast SSL connections—speed is important if you want your Certificate Manager, Registration Manager, or Data Recovery Manager to be able to accommodate a high number of simultaneous enrollment or service requests.

  • Hardware protection of private keys—these devices behave like smart cards, in that they do not allow the private keys to be copied or removed from the hardware token. This is important if you are concerned about the risks associated with key theft from an active attacker of your online Registration Manager or Certificate Manager.



Certificate Setup Wizard


Certificate Management System provides a wizard, called the Certificate Setup Wizard, which automates the process of requesting and installing the certificates required by the CMS managers—Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager—installed in the currently selected CMS instance. For details about these certificates, see Keys and Certificates for the Main Subsystems.

The Certificate Setup Wizard is integrated into the CMS window, enabling you to accomplish the following tasks:

  • Renew certificates of the CMS managers installed in a CMS instance; renewing a certificate means getting a new certificate with the same subject name and public and private key material as that of the existing certificate, but with an extended validity period.

  • Request and install new certificates for the CMS managers installed in a CMS instance; reissuing or requesting a new certificate means getting a certificate based on a new public and private key pair.

  • Install CA certificates in the certificate or trust database of a CMS instance.

  • Install CA certificate chains in the certificate database of a CMS instance.

When you start the wizard, which you do by clicking the Certificate Setup Wizard button in the Encryption tab of the CMS window (see the figure on page 476), you are asked to specify whether you want to request or install a certificate. The wizard presents you with the screens appropriate to your choice and walks you through the entire process.

For installing certificates, except for cases when the certificate is self-signed by the CA, you will need to run the wizard twice: once, to request the certificate and once to install the certificate. The reason for this is, if you submit the certificate request to a non-local CA, you will have to wait for the certificate until it is delivered to you.

The following sections explain the process of requesting and installing a certificate by using the Certificate Setup Wizard:

For instructions on getting new certificates, see Getting New Certificates for the Subsystems. For instructions on renewing existing certificates, see Renewing Certificates for the Subsystems.


Using the Wizard to Request a Certificate

The Certificate Setup Wizard allows you to request any of the certificates used by the Certificate Manager, Registration Manager, Data Recovery Manager, or Online Certificate Status Manager installed in the currently selected CMS instance.

Using the wizard to request a certificate involves the following steps:


Step 1. Select the Operation

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

For the purposes of completing the instructions that follow, assume that you chose to request a certificate.


Step 2. Choose the Certificate

Choose the certificate (by name) that you want to request.

The drop-down list shows various certificates used by the currently selected CMS instance. Choose the one you want to request—which certificates you see in the list depends on the subsystems installed in the currently selected CMS instance. You may see a combination of the following options:

Depending on the certificate you want to generate, choose the one in the drop-down list:

  • Certificate Manager Signing Certificate—choose this option if you want to request a signing certificate for the Certificate Manager installed in the currently selected CMS instance. If you choose this option, you must also specify whether the certificate request is for a self-signed CA (also known as the root CA) or a subordinate CA.

  • Certificate Manager OCSP Signing Certificate—choose this option if you want to request an OCSP signing certificate for the Certificate Manager installed in the currently selected CMS instance.

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

  • Online Certificate Status Manager Signing Certificate—choose this option if you want to request a signing certificate for the Online Certificate Status Manager installed in the currently selected CMS instance.

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

  • SSL Server Certificate—choose this option if you want to generate an SSL server certificate request for the CMS managers installed in the currently selected CMS instance.

  • SSL Server Certificate for Remote Admin—choose this option if you want to generate a remote administration server certificate request for the CMS managers installed in the currently selected CMS instance.

  • Other—choose this option if you want to generate a certificate request for a certificate that is not generated by a CMS manager by default. For example, in a Certificate Manager, you can use this option to request a CRL signing certificate (see CRL Signing Key Pair and Certificate) or a separate SSL client certificate exclusively for authenticating to the publishing directory. Be sure to specify the certificate type in the adjoining field. By default only two certificate types are supported: caCrlSigning for the CRL signing certificate (see CRL Signing Key Pair and Certificate) and client for SSL client certificate (see Getting an SSL Client Certificate for a Subsystem)


Step 3. Specify the Key-Pair Information

Specify the key-pair information for the certificate to be requested.

You need to identify the following:

  • The token that contains the key pair for generating the certificate request—the drop-down list shows the names of tokens currently installed for the selected CMS instance; these are the tokens you can use now.

    • The internal token is identified as internal. You should choose this option if the key pair for the certificate you chose in the previous step is stored in the local key database.

    • The names of external tokens vary, matching the names specified when the tokens were installed. You should choose this option if the key pair for the certificate you chose in the previous step is in an external cryptographic device. If you don't see the token you want to use, exit from the wizard, make sure the token is installed properly, restart the server, and repeat the process. For information on using or installing external tokens, see Installing Level 2 External Tokens.

  • The key pair for generating the certificate request—you can choose to generate the certificate request based on an existing or a new key pair.

    • If you want to renew the certificate you selected in the previous step, use the existing key pair for generating the request. For example, you can extend the validity period of a certificate by renewing it.

      To generate a certificate request based on an existing key pair, select the token that contains the key pair you want to use for generating the request. The wizard automatically selects the key pair that corresponds to the certificate you chose in the previous step.

    • If you want a new certificate, use a new key pair for generating the request. For example, you may want to get a new SSL server certificate or may want to replace an existing certificate whose private key has been compromised.

      To generate a certificate request based on a new key pair, select the token that can generate the key pair you want to use for generating the request. For example, if you want to generate the key pair using an external cryptographic device, such as a smart card, select that as the token. In addition, you will be required to indicate details, such as the key algorithm and size for the key pair.

  • The type and length of the key pair—you are required to provide this information only if you chose to generate the certificate request based on a new key pair. For key type, you can choose RSA or DSA. Be sure to select a key type that the CA (to which you will later submit the request for signing) can certify.

    For key length, enter the size in bits.

    • If the key type is RSA, the key size can be 512, 1024, 2048, 4098, or custom.

    • If the key type is DSA, the key size can be 512, 1024, or custom (must be in increments of 64 bit).

    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. Note that you will see this screen only if you chose to generate the certificate for a new key pair.

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. Except for the SSL server certificate, the common name format 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 iPlanet Console, and locate the CMS host in the navigation tree.

  • Organizational unit—enter the organizational unit the server belongs to. For example, Corporate Security.

  • Organization—enter a description that identifies your organization. For example, Siroe Corporation.

  • Locality—enter the name of the city where your business is located. For example, Mountain View.

  • State or province—enter the name of the state or province where your business is located. For example, California.

  • Country—enter the name of the country where your business is located. For example, US.


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 default validity period is two years.


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 and CRL Extensions" in Appendix C of CMS Plug-Ins 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 iPlanet 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 in the certificate you are requesting.

  • Subject key identifier—select this option if you want to set the subject key identifier extension in the certificate you are requesting.

  • Key usage—select this option if you want to set the key usage extension in the certificate you are requesting. 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 http://www.ietf.org/rfc/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.

    Certificate Management System provides tools that generate MIME-64 encoded blobs for many standard extensions. You can use these tools for generating MIME-64 encoded blobs for any extensions that you may want to include in CA and other certificate requests. For details about these tools, check this directory in your CMS installation: <server_root>/bin/cert/tools

    Note that the text field provided for pasting the extension in general accepts a single extension blob. If you want to add multiple extensions, you should use the ExtJoiner program, which is also provided in the tools directory mentioned above. For instructions to use the program, see Chapter 5, "Extension Joiner Tool" of CMS Command-Line Tools Guide.


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-----

MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzAVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x

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

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. The name of the text file varies depending on for which key pair you generated the request. Table 14-1 lists them.


Table 14-1    Names of files created for certificate signing requests  

Filename

Certificate Signing Request

cacsr.txt  

Certificate Manager CA signing certificate  

ocspcsr.txt  

Certificate Manager OCSP signing certificate  

racsr.txt  

Registration Manager signing certificate  

kracsr.txt  

Data Recovery Manager transport certificate  

ocspcsr.txt  

Online Certificate Status Manager signing certificate  

sslcsr.txt  

SSL server certificate  

sslcsrradm.txt  

Remote administration server certificate  

othercsr.txt  

Other certificates, such as Certificate Manager CRL signing certificate or SSL client certificate  

Do not modify the CSR; you must send it to the CA as it is. You can either submit the request automatically or copy the request and manually submit it to the CA by visiting the URL it provides for this purpose. Note that the wizard's auto-submission feature—a feature that enables you to send the request directly to a remote CA without having to manually copy the base-64 encoded certificate and paste the request in an enrollment form—can be used to submit requests to a remote Certificate Manager or Registration Manager (if that Certificate Manager is configured to receive requests via the Registration Manager) only. It can't be used for submitting the request to a third-party CA. For a third-party CA, you must manually copy the certificate request and paste it into the text area provided in the CA's enrollment form.


Sending the CSR Automatically to a CMS Manager
To send the certificate signing request (CSR) automatically to a Certificate Manager:

  1. Type the appropriate values in the following fields:

    Send the request to a remote CMS now. Select this option.

    Host name. Type the fully-qualified host name (in the <machine_name>.<your_domain>.<domain> format) of the Certificate Manager to which you want to submit your request automatically. For example, CAmachine.siroe.com.

    EE port number. Type the end-entity port number. For example, 80.

    Yes, it's the SSL secure server port. Select this option if the end entity port number you specified is the SSL port for end entities.

  2. Click Next to submit your request to the CA.

    The Certificate Manager returns a request ID for your request. Note the request ID as you can use it later to get the certificate from the Certificate Manager to which you submitted the request.

    The request you submitted gets queued for agent approval—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 have agent privileges to the Certificate Manager, you can log in to its agent interface and approve the request yourself.

  3. Once the certificate has been issued, you can use the request ID to import the certificate into the wizard. Alternatively, you can also install the certificate following the instructions in Using the Wizard to Install a Certificate or Certificate Chain.


Sending the CSR Manually 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 certificate signing request (CSR) manually to an internal CA:

  1. 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.

  2. Open a web browser window.

  3. 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://<hostname>:<end_entity_port> or https://<hostname>:<end_entity_port>, where <hostname> is in the form <machine_name>.<your_domain>.<domain>

    The end entity services interface appears.

  4. Click the Enrollment tab.

  5. In the menu list, click the appropriate link:

    • If the CSR is for a subordinate CA certificate, in the Server section, click the Certificate Manager link.

    • If the CSR is for a Registration Manager's signing certificate, in the Server section, click the Registration Manager link.

    • If the CSR is for a Certificate Manager's OCSP signing certificate or Online Certificate Status Manager's signing certificate certificate, in the Server section, click the OCSP Responder link.

    • If the CSR is for an SSL server certificate or remote administration server certificate, in the Server section, click the SSL Server link.

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

    For information on how a form works, click the Help button provided on the form. Be sure to include the marker lines, -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----.

  7. Submit the request.

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

    Note that the you submitted gets queued for agent approval—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 have agent privileges to the Certificate Manager, you can approve the request yourself.

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


Sending the CSR to an External CA
An external CA is any public or third-party 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.

To send the CSR manually to an external or third-party CA:

  1. 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.

  2. Open a web browser window.

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

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

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

  6. Submit the request.

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

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


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 get the certificate from the CA and install it using the process outlined 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 a Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager

  • 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 495:


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 . 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. 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 CA signing certificate for the Certificate Manager installed in the currently selected CMS instance.

  • OCSP Signing Certificate—choose this option if you want to install an OCSP 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.

  • Online Certificate Status Manager Signing Certificate—choose this option if you want to install a signing certificate for the Online Certificate Status 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 CMS managers installed in the currently selected CMS instance.

  • SSL Server Certificate Remote Admin—choose this option if you want to install a remote administration server certificate for the Certificate Manager, Registration Manager, Data Recovery Manager, or Online Certificate Status Manager installed in the currently selected CMS instance.

  • Trusted CA Certificate Chain—choose this option if you want to install a trusted CA certificate chain; the CA certificate will be included in the chain.

  • Untrusted CA Certificate Chain—choose this option if you want to install an untrusted CA certificate chain.

  • Other—choose this option if you want to install any other certificate, for example, a CRL signing certificate or a SSL client 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-----

    MIICKzCCAZSgAwIBAgIBAzANgkqkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERMA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHawczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhdfNAQEBBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYzBcABu1AVyd7chRFOGD3wNktbf6hRo6EAmM5R1Askzf8AW7LiQZBcrXpc0k4du+2j6xJu2MPm8WKuMOTuvzpo+SGXelmHVChEqooCwfdiZywyZNmgaMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgD

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

  • The certificate is at the CMS where your request was sent— if you have previously sent the certificate request to a remote Certificate Manager automatically and have noted the request ID that you received in return, you can use it to retrieve the certificate from the Certificate Manager.


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 .



Configuring the Server's Security Preferences


Configuring a CMS manager's security preferences involves identifying the following:

  • The SSL server certificates a 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 a Certificate Manager must use for authenticating to the publishing directory (if the Certificate Manager is configured to publish certificates and CRLs to the 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 iPlanet 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

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:

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

  2. Go to this directory: <server_root>/cert-<instance_id>config

  3. Open the configuration file (CMS.cfg) in a text editor.

  4. 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 ServerCert_agt, the configuration should look like this:

      agentGateway.https.nickName=ServerCert_agt cert-<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 ServerCert_ee, the configuration should look like this:

      eeGateway.https.nickName=ServerCert_ee cert-<instance_id>

    • To change the certificate used for authenticating to the administration interface, iPlanet 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 ServerCert_admin, the configuration should look like this:

      radm.https.nickName=ServerCert_admin cert-<instance_id>

  5. Save your changes.

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


Getting an SSL Client Certificate for a Subsystem

By default, the Certificate Manager uses its SSL server certificate for SSL client authentication to the publishing directory. For details about publishing certificates and CRLs to a directory, see Chapter 19 "Setting Up LDAP Publishing."

If you want the Certificate Manager to use another certificate for authenticating to the publishing directory, you can do so. This section provides instructions for requesting and installing an SSL client certificate for a Certificate Manager and configuring it to use that certificate for SSL client authentication to the publishing directory.

  1. Log in to iPlanet Console; see Logging In to iPlanet Console.

  2. Locate the CMS instance for the Certificate Manager, make sure it's started, and then log in to the CMS window of the Certificate Manager.

  3. Select the Configuration tab, and then select the Encryption tab.

  4. Click the Certificate Setup Wizard button to launch the wizard, which is explained in Certificate Setup Wizard.

  5. Select the option to request a certificate and then follow the on-screen prompts to generate a certificate request for the client certificate—in the Certificate Selection window, select Other and specify client as the certificate type in the associated text field.

  6. Once you have the certificate request ready, submit it to a CA so that it can issue a certificate. For general instructions to use the wizard to request a certificate, see section Using the Wizard to Request a Certificate.

  7. If you submitted the request to a Certificate Manager and if you have agent privileges for that Certificate Manager, log in to its Agent Services interface, locate the request, and check the request for required extensions. (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.)

    Make sure that only the SSL Client option for certificate type is selected in the request. For certificates with no Netscape Certificate Type extensions, the Key Usage extension must be included with Signing and Encryption bits set.

  8. Approve the request.

  9. Once you have the certificate ready, restart the wizard and install the certificate in the Certificate Manager's database. For general instructions to use the wizard to add a certificate, see Using the Wizard to Install a Certificate or Certificate Chain.

    Note that the default nickname for the certificate is
    crlSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed.

  10. After you've installed the certificate successfully, go to the Tasks tab and stop the Certificate Manager.

  11. Configure the Certificate Manager to use this certificate.

    After you install the certificate, configure the Certificate Manager to use the new certificate for SSL client authentication to the publishing directory. For instructions, see Step 5. Identify the 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 14-4 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 domestic (US and Canada) version of Certificate Management System. Note that Certificate Management System has received retail status from the United States Department of Commerce Bureau of Export Administration; under new regulations, retail status makes it possible to export Certificate Management System with the same encryption and cryptographic features available in the US and Canada. For more information, see Appendix C "Export Control Information."

Figure 14-4    SSL version 2.0 and 3.0 cipher suites supported (in the domestic version)


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 iPlanet Console.


Caution

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.


Previous US law prohibited the export of software with strong encryption, so most browsers still in use outside of the US and Canada do not support 128-bit encryption. Disabling all 40-bit ciphers will ensure that all connections use higher-grade security, but will prevent access to your service to many users outside of the US and Canada.

Note that Netscape Communicator too has received retail status from the United States Department of Commerce Bureau of Export Administration; under new regulations, retail status makes it possible to export Communicator with the same encryption and cryptographic features available in the US and Canada.

Prior to the retail status, international users of Netscape Communicator (with encryption capability restricted to 40-bit encryption) could 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.

Because many of the features, such as issuance of dual certificates for dual key pairs and real-time verification of certificates using the OCSP protocol, supported in Certificate Management System require Communicator versions 4.7x or Netscape 6, it's recommended that you upgrade your browser. For information on downloading the browser, check this site:

http://home.netscape.com/download/


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:

  1. Log in to the CMS window (see Logging In to the CMS Window).

  2. Select the Configuration tab, and then in the right pane, select the Encryption tab.

  3. Click SSL Cipher Preferences, and choose the appropriate options.

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

  4. Click OK.

    You are returned to the Encryption tab.

  5. 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 the CMS managers installed in a CMS instance. 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, Data Recovery Manager, and Online Certificate Status Manager using the Certificate Setup Wizard. Alternatively, you can use the command-line utilities called the Key Database Tool and Certificate Database Tool. For details about these tools, check the CMS Command-Line Tools Guide.

Getting a new key pair and a corresponding certificate involves the following steps:


Step 1. Plan for the New Certificate

Getting a new certificate for a CMS manager 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, OCSP signing, CRL signing, SSL server, and remote administration certificates for the Certificate Manager; signing, SSL server, and remote administration certificates for the Registration Manager; transport, SSL server, and remote administration certificates for the Data Recovery Manager; and signing, SSL server, and remote administration certificates for the Online Certificate Status Manager. For details about the certificates used by a CMS manager, see Keys and Certificates for the Main Subsystems.

  • If you have deployed a Certificate Manager as your root CA and if you want to get a new self-signed CA certificate for that Certificate Manager, you must consider the possible effects on your PKI setup of changing the key pair of the root CA. If you reissue the Certificate Manager's CA signing certificate with a new key material, none of the certificates issued or signed by the CA using its old key will work; the reason for this is, when you change the root CA key, all certificates that rely on the CA certificate for validation will no longer be validated. For example, if the CA has issued certificates to subordinate Certificate Managers, Registration Managers, Data Recovery Managers, Online Certificate Status Manager, and agents, all those certificates will become invalid—the subsystems will fail to function, and agents will fail to access agent interfaces.

    Before getting a new self-signed certificate for the Certificate Manager, therefore, you must address issues involved in deploying the new root CA certificate across your enterprise. It is beyond the scope of this document to explain how you should deploy the new CA certificate.

  • If you have deployed a Certificate Manager as a subordinate CA (that's chained to a root CA) and if you want to get a new subordinate CA certificate for that 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 subordinate CA certificate for validation will no longer be validated. Before getting a new subordinate certificate, therefore, you must plan to address issues involved in deploying the new subordinate CA certificate across you enterprise.

  • If you have deployed a Certificate Manager and if you have configured it to publish CRLs to a Online Certificate Status Manager, you will need to identify the Certificate Manager to the Online Certificate Status Manager again. For details, see Step 3. Identify the CA to the OCSP Responder.

  • 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 a Certificate Manager and Data Recovery Manager—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, determine whether the Certificate Manager is used as a master CA in a cloned-CA setup; see Cloning a Certificate Manager. If it is, you'll have to update the clone CAs certificate databases with the new SSL server certificate.

    Also determine whether the Certificate Manager is configured to publish certificates and CRLs to an LDAP directory and whether it uses the SSL server certificate for SSL client authentication to the directory. If it does, you will have to request the certificate with the appropriate extensions, and after installing the certificate you will have to configure the publishing directory to use this certificate.

  • 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 (for example, the policy configuration) 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. For details, see Tokens for Storing CMS Keys and Certificates. 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; for instructions, see Installing Level 2 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 CMS managers. 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 above.

The Certificate Setup Wizard automates the process of installing certificates used by the CMS managers. You can 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:


Deploying Certificate Manager's CA Signing Certificate

If you reissued the Certificate Manager's CA signing certificate with a new key material, none of the certificates issued by the CA using its old key will work. For example, if the CA has issued certificates to subordinate Certificate Managers, Registration Managers, Data Recovery Managers, Online Certificate Status Manager, and agents, all those certificates will become invalid—the subsystems will fail to function and agents will fail to access the agent interfaces.

To reinstate your PKI setup, first you should get an agent certificate from the new CA so that you can get access to the Certificate Manager's agent interface. Once you have access to this interface, you will be able to approve new certificate requests from entities such as Registration Managers, Data Recovery Managers, Online Certificate Status Managers, and agents.

To request an agent certificate from the new CA:

  1. Go to this directory: <server_root>/cert-<instance_id>/config

  2. Open the configuration file, CMS.cfg, in a text editor.

  3. Locate the agentGateway.enableAdminEnroll parameter and change its value from false to true. The modified parameter should look like this:

    agentGateway.enableAdminEnroll=true

  4. Save your changes and close the file.

  5. Restart the server.

  6. Open a web browser window.

  7. Go to the Certificate Manager's agent interface.

    The URL is in this format: https://<hostname>:<agent_port>

  8. Enter all the information and request a new certificate.

    If you need more information on getting the first agent certificate, see Stage 3. Enrolling for Administrator/Agent Certificate.

  9. Once you get the certificate, install it in your browser.

  10. Access the Certificate Manager's agent interface using your new certificate.


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:

  1. 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.

  2. 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 Content.


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:

  1. Locate the enrollment page that embeds the key archival feature.

  2. 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 14-5 shows the default directory-based user enrollment form with the transport certificate-related information. (For more information, see Step C. Customize the Certificate Enrollment Form.)

Figure 14-5    Data Recovery Manager's transport certificate in the enrollment form


  1. 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.

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


Deploying a Subsystem's SSL Server Certificate

By default, the Certificate Manager and Registration Manager use a single SSL server certificate to do server-side authentication to all the CMS ports. If a Certificate Manager is configured for SSL-client-authenticated communication with the publishing directory, it also uses its SSL server certificate for authenticating to the publishing directory. Depending on the purpose for which you requested this certificate, you should configure the server appropriately.



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, Data Recovery Manager, or Online Certificate Status 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 subject name and public and private key material as that of the existing certificate, but with an extended validity period.

The sections that follow explain how to renew certificates for the Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager using the Certificate Setup Wizard. Alternatively, you use the command-line utility called the Certificate Database Tool, which is explained in CMS Command-Line Tools Guide.

Renewing an existing certificate involves the following:


Step 1. Plan for Certificate Renewal

Renewing a CMS manager'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, file, and OCSP responder with the most current certificate and CRL information. For details, see Chapter 19, Chapter 20, and, Chapter 21.

    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 the configured 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 Level 2 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 and that it's configured to set the required extensions in the certificate.

  • 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 CMS managers. 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.


Note When renewing a certificate, be sure to use the existing key pair to generate the certificate signing request.


Note that when you renew any of the CMS certificates using the wizard, it saves the old or previous certificate (in its base-64 encoded format) to a text file in the configuration directory, which is located here: <server_root>/cert-<instance_id>/config

The names of the text files vary depending on the certificate you choose for renewal. Table 14-2 lists them.


Table 14-2    Names of backup files created for old CMS certificates  

Filename

Renewed Certificate

prevCACert.txt.<timestamp>  

Certificate Manager CA signing certificate  

prevOCSPCert.txt.<timestamp>  

Certificate Manager OCSP signing certificate  

prevRACert.txt.<timestamp>  

Registration Manager signing certificate  

prevKRACert.txt.<timestamp>  

Data Recovery Manager transport certificate  

prevOCSPCert.txt.<timestamp>  

Online Certificate Status Manager signing certificate  

prevSSLCert.txt.<timestamp>  

SSL server certificate  

prevSSLRadmCert.txt.<timestamp>  

Remote administration server certificate  

prevOtherCert.txt.<timestamp>  

Other certificates, such as Certificate Manager CRL signing certificate or SSL client certificate  

prevClientCert.txt.<timestamp>  

SSL client  

The wizard also deletes the old certificate from the server's certificate database and adds the renewed certificate to the database, so that the server is able to use the renewed certificate upon restart. This feature restricts you to set the value of the notBefore attribute of the renewed certificate to either the current time or any time in the past, but not in the future.

If you set the validity period of the renewed certificate to begin on a future date and time, the server fails to use the certificate for its intended purposes. If this happens, you may either reinstall the old certificate (saved to the text file mentioned above) or renew the certificate again with an appropriate validity period.


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 CMS managers. For instructions on using the wizard, see Using the Wizard to Install a Certificate or Certificate Chain.


Step 4. Deploy the Renewed Certificate

Follow the instructions appropriate for the certificate you installed:

For all certificates, make sure the that CA-chain verification takes place smoothly. For example, if you requested the certificate from a different CA, be sure to import a CA certificate into the certificate database of the subsystem using the Certificate Setup Wizard. For instructions, see Using the Wizard to Install a Certificate or Certificate Chain. After you install the CA certificate, you can follow the instructions in see Changing the Trust Settings of a CA Certificateto trust the CA certificate you imported.


Deploying Certificate Manager's Renewed CA Signing Certificate

If you renewed a CA signing certificate, deploy it in the PKI environment that depends on this certificate for validation. For example, you'll need to add the renewed CA certificate to the certificate databases of clients that trust this CA. Similarly, if you have configured the Certificate Manager to publish CRLs to a Online Certificate Status Manager, you will need to identify the Certificate Manager to the Online Certificate Status Manager again. For details, see Step 3. Identify the CA to the OCSP Responder.

You might also need to get a new agent certificate. For instructions, see the procedure outlined in Deploying Certificate Manager's CA Signing Certificate.

It is beyond the scope of this book to explain how you should deploy the new CA certificate.


Deploying Registration Manager's Renewed Signing Certificate

Here's what you must do:

  1. 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:

    1. 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.

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

    3. 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.

  2. 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 Content.


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:

  1. Locate the page that embeds the key archival feature.

  2. 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 14-6 shows the default directory-based user enrollment form with the transport certificate-related information. (For more information, see Step C. Customize the Certificate Enrollment Form.)

Figure 14-6    Data Recovery Manager's transport certificate in the enrollment form


  1. 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.

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


Deploying a Subsystem's Renewed SSL Server Certificate

If you renewed the SSL server certificate of a Certificate Manager and if the Certificate Manager is used as a master CA in a cloned-CA setup (see Cloning a Certificate Manager), you should add the renewed SSL server certificate to the certificate databases of the clone Certificate Managers.

By default, the Certificate Manager and Registration Manager use a single SSL server certificate to do server-side authentication to all the CMS ports. If a Certificate Manager is configured for SSL client authenticated communication with the publishing directory, it also uses 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.


Step 5. Restart the Server

After you renew any of the CMS certificates using the wizard, you must restart the server. For instructions, see Restarting Certificate Management System.



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 (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 also provides a command-line utility called certutil for managing its certificate database. For details, check CMS Command-Line Tools Guide.



Viewing the Certificate Database Content

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

  1. Log in to the CMS window (see Logging In to the CMS Window).

  2. Select the Configuration tab, and then in the right pane, select the Encryption tab.

  3. Click Manage Certificate.

    The Certificate Database Management window appears.

    The window lists the certificates in a table, with each certificate occupying a row. The certificates are listed in alphabetical order. If the database contains multiple 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 certificate.

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

    Trust Status. Specifies whether the CA is trusted or untrusted. To change the trust setting, see .


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.


Note 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 .


To delete a CA certificate from the certificate database:

  1. Log in to the CMS window (see Logging In to the CMS Window).

  2. Select the Configuration tab, and then in the right pane, select the Encryption tab.

  3. 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.

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

  5. When prompted, confirm the delete action.

  6. Click Close.

    You are returned to the Encryption tab.

  7. 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 the CA certificates in its certificate database for validating certificates it receives during an SSL-enabled communication. For example, when a Certificate Manager is authenticating a Registration Manager that has sent a certificate signing request, the Certificate Manager checks its certificate database to see whether the CA that has 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. For instructions, 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:

  1. Log in to the CMS window (see Logging In to the CMS Window).

  2. Select the Configuration tab, and then in the right pane, select the Encryption tab.

  3. Click Manage Certificate.

    The Certificate Database Management window appears.

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

  4. 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."

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

  6. Click Close.

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

  7. Click Close.

    You are returned to the Encryption tab.

  8. 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.


Note Be sure to choose the "Other Trusted CAs" option in Step 2 of 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 iPlanet Console.


Previous     Contents     Index     Next     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated October 07, 2002