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



Chapter 7   Installing and Uninstalling CMS Instances


After the initial installation of iPlanet Certificate Management System (CMS), you may need to install additional instances, remove unwanted instances, or duplicate configuration in multiple instances. This chapter describes how to manage these tasks by using Netscape Console, the single, unified administration interface for your network.

You can use Netscape Console only when Netscape Administration Server is running. During CMS installation, you specified a port number for the Administration Server instance you will use to administer Certificate Management System. If Administration Server is shut down, be sure to start it at this port. To minimize security risks, shut down the Administration Server when you have finished using Netscape Console. For more information about Netscape Console, see , "Administration Tasks and Tools."

The chapter has the following sections:



Installing Multiple CMS Instances

Multiple instances of Certificate Management System can run on the same machine. You might, for example, install multiple Registration Managers, all reporting to the same Certificate Manager, to handle requests from different types of users (end users, servers, and routers) or from users from different domains. For example deployment scenarios, see Chapter 4 "Planning Your Deployment."

Once Certificate Management System is installed on a machine, you can use that CMS installation to create multiple instances of the server on the same machine. Administration Server contains all the files necessary to install another instance of Certificate Management System on the same machine; you don't have to run the complete installation (setup) program again. However, you do need to run the CMS installation wizard each time you create an instance, so that you can configure the server and generate the required certificates. So, before attempting to create another instance of Certificate Management System, be sure to read about the installation wizard explained in Chapter 6 "Installing Certificate Management System."

When you install additional CMS instances on the same machine, you are required to specify different ports for each CMS instance to listen on. For example, you will have to set up one server to listen on port 443 and another server to listen on port 4430. However, if you install multiple CMS instances on a machine that has been set up with more than one IP addresses, you can configure each instance to listen to a specific IP address—this enables you to use same the port numbers for different CMS instances installed on the same machine.

Keep in mind that when you create a new instance, you'll be required to specify different port numbers; the installation wizard allows you to specify the port numbers only, not IP addresses. After you have successfully created the instance, you can edit the CMS configuration file to specify the IP addresses for individual CMS ports and then change the port numbers. For details on editing the configuration file to include the IP addresses, see "Step 2: Specify IP Addresses". For details on changing the port numbers, see "Configuring Port Numbers".

To create another instance of Certificate Management System with a separate configuration file (and certificates):

  1. Log in to Netscape Console (see "Logging In to Netscape Console").

  2. In the navigation tree at the left, expand the icon for your computer, then select the server group that contains the CMS instance you want to use as your source.

  3. From the Object menu, choose the Create Instance Of option and, in the pop-up menu that appears, choose Certificate Management System.

    As shown in this figure, you can also right-click to choose this option from the pop-up menu.

    The Create Server Instance dialog box appears.

  4. Type a unique name or identifier for the new instance.

    For the name, you can use any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type Siroe_root-CA as the instance name, but not Siroe root CA.

  5. Click OK.

    The instance you created appears in the navigation tree. Note that the instance name appears in the CMS (cert-<instance_id>) form, where <instance_id> is the name you specified for the new CMS instance. For example, if you named the instance Marketing_CA, the instance name in the navigation tree will be CMS (cert-Marketing_CA).

  6. To start the installation wizard, double-click the new instance in the navigation tree, and then use the installation wizard to finish configuring the new instance.

  7. Create the first agent for the new CMS instance.

    When you have finished setting up an additional CMS instance, you need to create at least one agent for that instance. If the new instance includes a Certificate Manager, you can create the administrator/agent as described in "Agent Certificate for a Certificate Manager" as you did for the first instance in the server root. If the new instance does not include a Certificate Manager—that is, if it contains a Registration Manager, Data Recovery Manager, Online Certificate Status Manager, Registration Manager and Data Recovery Manager, or Online Certificate Status Manager and Data Recovery Manager—you will need to use the CMS window to create a new agent. This is described in section "Agent Certificate for Other CMS Managers".



Cloning a Certificate Manager

Cloning a Certificate Manager refers to the process of creating two server processes performing the same CA functions: you create another instance of a Certificate Manager and configure it to use the same CA signing key and certificate and issue certificates with serial numbers that do not conflict or overlap with the serial numbers of the Certificate Manager that's being cloned or with the serial numbers of any other clones. The Certificate Manager that's being cloned is called the master Certificate Manager or master CA in this document.

You can use the cloning feature for CA scalability and for setting up a PKI with CAs organized in a flat structure as opposed to a hierarchical structure. For example, if you don't want your PKI to be a CA hierarchy comprising root and subordinate CAs, you can create multiple clones of a Certificate Manager and configure each clone to issue certificates that fall within a distinct range of serial numbers. Because clone CAs use the same CA signing key and certificate (as that of the master CA) to sign the certificates they issue, the issuer name in all the certificates in your PKI setup would be the same, as if they've been issued by a single CA.

The other advantage of cloning is that when you setup a clone Certificate Manager, it automatically sends the revocation status of the certificates it has issued to the master Certificate Manager. The clone Certificate Manager uses the master Certificate Manager's agent port to communicate this information; the communication is SSL-client authenticated. This way, the master Certificate Manager has the complete list of certificates revoked by all clone Certificate Managers and is able to generate a consolidated list of revoked certificates or a complete CRL.

Because the master Certificate Manager has the complete CRL, if you enable the OCSP-service feature built into the Certificate Manager, it can function as a full-fledged OCSP responder for your PKI—that is, irrespective of which clone Certificate Manager has issued the certificate, OCSP-compliant clients can directly query the master Certificate Manager for the revocation status of a certificate. (For information on enabling a Certificate Manager's OCSP service, see "Setting Up a Certificate Manager with OCSP Service".) So, CAs organized in a flat structure using the cloning method eliminate the need for you to install the standalone OCSP responder, the Online Certificate Status Manager, and configure each Certificate Manager to publish its CRL to the Online Certificate Status Manager.

To setup a clone a Certificate Manager (or a CA), follow these steps:


Step 1. Before You Begin

Before you start cloning a Certificate Manager:

  • Verify that the master Certificate Manager is installed and configured properly, and is started.

  • Check the master Certificate Manager's serial number range. The "Next serial number" field should be set to the next serial number of the certificate the CA will issue and the "Last serial number" field must be blank. To locate the panel that enables you to do this, see "Enabling End-Entity Interaction with a Certificate Manager".

  • If the master Certificate Manager's keys and certificates are stored in a hardware token, check the token vendor's documentation for copying the keys and certificates (from the original token to a new token accessible to the clone Certificate Manager). Keep the relevant instructions handy.

  • Decide how many clone CAs you need to deploy, and note the following for each clone CA.

    • CA's serial number range—Each clone Certificate Manager must be configured to issue certificates with unique serial numbers. Which means, when you configure a clone Certificate Manager, you must specify upper and lower bounds for the serial numbers and make sure that the serial-number range does not overlap with the one specified for another clone Certificate Manager.

      When specifying the serial number range for the first clone Certificate Manager, it's recommended that you start with, say, 0x100, as the starting/lowest serial number. This will ensure that the master Certificate Manager has sufficient serial numbers for its own certificates, such as the CA signing certificate, SSL server certificate, agent's certificate, and so on. The master Certificate Manager will also need distinct serial numbers in the future, for example, when you renew its certificates in the future. Any subsequent clone Certificate Manager does not need to make such a provision; its serial numbers only need to not overlap with the ones assigned to the previous clones.

    • CA's signing key and certificate—You must use the master Certificate Manager's signing key and certificate. If you do not use the master Certificate Manager's key and certificate databases, the clone Certificate Manager will need to generate a new signing key and certificate; consequently, it will not be a clone.

    • CA's SSL server key and certificate—This depends on the hostname of the clone Certificate Manager. If the clone Certificate Manager uses the same hostname as that of the master Certificate Manager, you can use the same SSL server certificate and key copied from the master Certificate Manager. If the hostnames are different, you must generate a new SSL server certificate for the clone Certificate Manager; the SSL server certificate DN contains the hostname as the common name (CN) attribute, so a clone with a different hostname must enroll for a new SSL server certificate.

      During the cloning process, the master Certificate Manager's SSL server certificate is automatically copied to the certificate database of the clone Certificate Manager. The clone Certificate Manager uses this certificate for SSL-client-authenticated communication with the master Certificate Manager. Don't be alarmed when you see the certificate in clone Certificate Managers' certificate databases. Also, be sure not to remove them from the master and clone Certificate Managers' databases.

    If you want to note the details such as the serial numbers and ports used by the clone CAs, use the section "Cloned Certificate Manager Configuration" in Chapter 5 "Installation Worksheet."


Step 2. Create Instances for Clone CAs

Depending on how many clone CAs you want to deploy, follow the appropriate instructions in this step to create that many CMS instances.

Depending on your master Certificate Manager's installation, there are three possible scenarios to install a clone Certificate Manager:


Installing Clone CA in Master CA's Server Group

If you want to install your clone Certificate Manager in the same server group as that of the Certificate Manager:

  1. Log in to Netscape Console of the master Certificate Manager (see "Logging In to Netscape Console").

  2. In the navigation tree at the left, expand the icon for your computer, then select the server group that contains the CMS instance you want to use as your master.

  3. From the Object menu, choose the Create Instance Of option and, in the pop-up menu that appears, choose Certificate Management System.

    As shown in this figure, you can also right-click to choose this option from the pop-up menu.

    The Create Server Instance dialog box appears.

  4. Type a unique name or identifier for the new instance.

    For the name, you can use any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type Clone1_of_root-CA as the instance name, but not Clone1 of root-CA.

  5. Click OK.

    The instance you created appears in the navigation tree. Note that the instance name appears in the CMS (cert-<instance_id>) form, where <instance_id> is the name you specified for the new CMS instance. For example, if you named the instance Clone1_of_root-CA, the instance name in the navigation tree will be CMS (cert-Clone1_of_root-CA).


Installing Clone CA in a Different Server Group

In a Windows NT installation of Certificate Management System, you cannot create more than one server group. In a Unix installation, you can create multiple server groups. For more information, see section "The Administration Server" of Managing Servers with Netscape Console.

If you want to install your clone Certificate Manager on the same host on which the master Certificate Manager is installed, but in a different server group:

  1. In the master Certificate Manager host machine, go to the directory that contains the CMS setup program.

  2. Run the setup program. For instructions, see "Stage 1. Running the Installation Script". Be sure to follow these guidelines:

    • When prompted to chose a server root or the location for the installation, specify a different directory/folder (than the one where the master Certificate Manager is installed). For example, if your master Certificate Manager is installed at /u/netscape/server4, you can specify /u/netscape/server4_clone1 as the server root for the clone instance.

    • When prompted to specify a configuration directory, select the option for an existing directory and specify the host name and port number of the Directory Server instance used by the master Certificate Manager.

    • When prompted to specify a port number for the Administration Server, be sure to specify distinct port number; each server group is managed by a separate Administration Server. Note the port number as you will need this later to log in to Netscape Console.


Installing Clone CA on a Separate Host

If you want to install your clone Certificate Manager on a different host than the one on which the master Certificate Manager is installed, you should run the CMS setup program on that host. For instructions, see "Stage 1. Running the Installation Script". (Note that you only need to complete Stage 1 and then proceed to "Step 3. Shutdown the Master CA" below.)


Step 3. Shutdown the Master CA

Stop the master Certificate Manager. If you need instructions, see "Stopping Certificate Management System".


Step 4. Copy Master CA's Certificate and Key Database

Because you want the clone Certificate Manager to own the same keys and certificates as that of the master Certificate Manager, you need to make available the keys and certificates used by the master Certificate Manager to each clone Certificate Manager.

  • If the master Certificate Manager's keys and certificates are stored in the internal/software token, you need to copy the key3.db and cert7.db files from the config directory of the master Certificate Manager to the config directory of each clone Certificate Manager. Here's how you do this:

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

    2. Locate files named cert7.db and key3.db.

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

    4. Copy the cert7.db and key3.db files from master Certificate Manager to the clone.

    5. Repeat steps c and d to copy the master Certificate Manager's key3.db and cert7.db files to the config directory of each clone Certificate Manager.

  • If the master Certificate Manager's keys and certificates are stored in the hardware token, you need to copy the keys and certificates following the instructions provided by the hardware-token vendor.


Step 5. Start the Master CA

Start the master Certificate Manager. If you need instructions, see "Starting Certificate Management System".


Step 6. Configure the Clone CA

Depending on how many CMS instances you've created for clone Certificate Managers, you should repeat the instructions in this step to configure each clone Certificate Manager.

To configure a clone Certificate Manager:

  1. Log in to or go to Netscape Console that shows the clone Certificate Manager instance.

  2. In the navigation tree, locate the instance ID for the clone you created, and double-click the instance.

    The CMS Installation Wizard starts.

  3. Follow the on-screen instructions to finish configuring the clone CA. During configuration, be sure to follow these:

    • Clone key and certificate materials—On this screen, click Yes to reuse the certificate and key material in the database files you copied from the master Certificate Manager. In the Instance Name field enter the instance ID of the master Certificate Manager. Select the token name where the keys and certificate are stored and enter the token's password, if required.

    • Clone key and certificate materials—On this screen, you choose whether to reuse the master Certificate Manager's SSL server certificate or create a new one. If you created the clone Certificate Manager on the same host as the master Certificate Manager, you can reuse the SSL server certificate. To reuse the SSL server certificate, select Yes, enter the instance ID of the master Certificate Manager, select a token, and enter the token password. If you do not or cannot reuse the SSL server certificate, select No and follow the screens that enable you to generate a new SSL server certificate.

    • CA's serial number range—On this screen, specify the lowest serial number the CA should assign to certificates it creates in the "Starting serial number" field. In the "Ending serial number" field, specify the highest serial number available for this CA. For both the fields, you can enter the number in decimal or hexadecimal (0xnn).

  4. Repeat steps 1 through 3 for each clone Certificate Manager.


Step 8. Establish Trust Between Master CA and Clone CAs

For the master Certificate Manager to trust the clone Certificate Manager, you associate the clone Certificate Manager as a trusted manager to the master Certificate Manager. For details about trusted managers, see "Trusted Managers".

The setup process involves the following steps:


Step A. Locate the Master CA's SSL Server Certificate

Depending on which CA issued/signed the master Certificate Manager's SSL server certificate, you can locate the certificate in either the internal database or the certificate database (cert7.db file).

  • If the issuer of the SSL server certificate is the master Certificate Manager itself, you can locate the certificate in the internal database by going to the Retrieval tab of the master Certificate Manager's end-entity interface.

  • If the issuer of the SSL server certificate is another CA, for example, a third-party CA, you can locate the certificate in the certificate database by using the certutil command-line tool. For more information about this tool, see Chapter 11 , "Certificate Database Tool" of CMS Command-Line Tools Guide.

Follow the instructions that's appropriate for you.

To locate the certificate in the Retrieval tab of the end-entity interface:

  1. Open web browser window.

  2. Go the master Certificate Manager's end-entity interface. The URL is in https://<hostname>:<SSL_port> or http://<hostname>:<port> format.

  3. Select the Retrieval tab, and in the left frame, click List Certificates.

  4. In the resulting form, click List.

    A list of certificates appear.

  5. Locate the Certificate Manager's SSL server certificate by looking at the subject name of the certificate.

    Typically, the SSL server certificate would be the second certificate.

  6. Click Details.

  7. In the resulting page, scroll to the section that says "Base 64 encoded certificate" and shows the certificate in its base-64 encoded format.

  8. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to the clipboard or a text file. (Alternatively, you can keep the browser window open and copy the certificate later in the procedure.)

    The copied information should look similar to the following example:

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

    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pYF
    0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAw
    MnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzA
    VBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJ
    ARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngjn
    jgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBA
    Fi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4xzmKdvQ6IqD2q8DBs9lRQu9

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

To locate the SSL server certificate in the master Certificate Manager's certificate database using the certutil tool:

  1. Open a terminal window in the system that hosts the master Certificate Manager.

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

  3. Next, run this command:

    <server_root>/bin/cert/tools/certutil -L -d <certdir>
    -n <certname> cert-<instance_id> -a

    replacing <certdir> with the directory containing a certificate database file, <certname> with the nickname of the SSL server certificate, and <instance_id> with the ID assigned to the master Certificate Manager instance.

    For example, your command might look like this:

    <server_root>/bin/cert/tools/certutil -L -d . -n Server-Cert
    cert-masterCA -a

    The SSL server certificate appears.

  4. View the certificate information. Make sure that the certificate you are looking at is the correct one; the certificate shows the DN that was specified for the certificate during the installation.

  5. Copy the base-64 encoded certificate, including the marker lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, to the clipboard or to a text file. The copied information should look like the example below:

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

    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pYF
    0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAw
    MnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzA
    VBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJ
    ARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngjn
    jgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBA
    Fi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4xzmKdvQ6IqD2q8DBs9lRQu9JYg129o

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


Step B. Create a Privileged-User Entry for Clone CAs

In this step, you create a privileged-user entry for all clone Certificate Managers in the internal database of the master Certificate Manager. As a part of creating this entry, you also add the new user entry to the Trusted Managers group in order to give the entry access privileges to the agent port of the master Certificate Manager.

To create a user entry with appropriate access privileges:

  1. Log in to or go to the CMS window for the master Certificate Manager (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears in the right pane.

  3. Click Add.

    The Select User Type window appears.

  4. Select Trusted Manager and click OK.

    The Edit User Information window appears.

  5. Specify information as appropriate.

    The information you enter here is to help you keep track of the clone Certificate Managers. The master Certificate Manager relies solely on its SSL server certificate (which you will add in Step 3) for authentication.

    User ID. Type an ID that will help you identify this user in the list of privileged users. The ID can be an alphanumeric string of up to 255 characters.

    Description. Type a description to identify that the user entry is for the clone Certificate Managers. The description can be an alphanumeric string of up to 255 characters.

    Group. Select Trusted Managers. For more information about this group, see "Group for Trusted Managers".

  6. Click OK.

    You are returned to the Users tab. The user you just added is displayed in the list of users.

  7. Select the user entry you just added for the clone Certificate Managers and click Certificates.

    The Manage User Certificates window appears.

  8. Click Import.

    The Import Certificate window appears.

  9. Click inside the text area, and paste the master Certificate Manager's SSL server certificate in its base-64 encoded form.

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

  10. Click OK.

    You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.

  11. To view the certificate you imported, select it and click View.

    The certificate information appears. Verify that the certificate you added is the correct one.

  12. Click Done.

    You are returned to the Users tab.

  13. Click Refresh.


Step 9. Test Clone-Master Connection

To test whether your clone-master CA setup is complete and functional, repeat these steps for each clone Certificate Manager.


Step A. Request a Certificate from the Clone CA

The steps outlined below explain how to request a client certificate from the clone Certificate Manager using the manual enrollment method. If you've configured the clone Certificate Manager for automated certificate issuance, for example for directory-based enrollment, you may use the appropriate form and request a certificate.

To request a client or personal certificate from the clone Certificate Manager:

  1. Open a web browser window.

  2. Go to the end-entity interface of the Certificate Manager you configured (or to the Registration Manager that's connected to this Certificate Manager).

    The URL is in this form: https://<hostname>:<end_entity_HTTPS_port> or http://<hostname>:<end_entity_HTTP_port>

  3. In the left frame, under Browser, click Manual.

    This opens the manual enrollment form.

  4. Fill in all the values and submit the request.

    The client prompts you to enter the password for your key database.

  5. When you enter the correct password, the client generates the key pairs.

    Do not interrupt the key-generation process.


Step B. Approve the Request

Skip this step if you requested the certificate using any of the automated enrollment methods. Complete this step if you used the manual enrollment form for requesting the certificate; the request you submitted is waiting in the agent queue for approval by an agent.

To approve the request:

  1. Go to the clone Certificate Manager's Agent Services interface.

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

  2. In the left frame, click List Requests.

  3. In the form that appears, select the "Show pending requests" option and click Find.

  4. In the list of pending requests, identify the request you submitted and click Details.

  5. Check the request to make sure that it has all the required attributes of a client certificate.

  6. Scroll to the bottom of the request form, and approve the request.

    You should see a confirmation page indicating that the certificate has been issued. If you're using the same browser for requesting the certificate and for agent operations, don't close the page until after you complete the next step.


Step C. Download the Certificate to the Browser

If you're using the same browser, to download the certificate into the certificate database of the browser:

  1. In the confirmation page, scroll down to the section that says "Installing this certificate in a client."

  2. Check the certificate details for the required extensions.

  3. Follow the on-screen instructions and download the certificate to your browser's certificate database.

If you're using a different browser, to download the certificate:

  1. Go to the end-entity interface of the Certificate Manager that issued the certificate.

  2. Select the Retrieval tab.

  3. Search for the certificate; it will be the last certificate.

  4. Click Details.

  5. Scroll to down to the section that enables you to download the certificate to the browser, and download the certificate.


Step D. Revoke the Certificate

To revoke the certificate you issued:

  1. Go to the end-entity interface for the Certificate Manager.

  2. Select the Revocation tab.

  3. In the left frame, click User Certificate.

    The User Certificate Revocation form appears.

  4. In the Revocation Reason section, select Unspecified and click Submit.

    The browser shows the "Select a Certificate" dialog box and prompts you to choose the certificate you want to revoke.

  5. Select the certificate you downloaded and click OK.

    The clone Certificate Manager revokes the certificate, updates the certificate status in its internal database, and sends details about the revoked certificate to the master Certificate Manager.


Step E. Check Master CA's CRL for the Revoked Certificate

To verify that the revoked certificate has been included in the master Certificate Manager's CRL:

  1. Go to the master Certificate Manager's Agent Services interface.

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

  2. In the left frame, click Update Certificate Revocation List.

  3. In the form that appears, select the algorithm that you want to use to sign the new CRL.

    • MD5 with RSA generates a 128-bit message digest. Most existing software applications that handle certificates support only MD5. This is the default algorithm.

    • SHA-1 with RSA generates a 160-bit message digest. Before choosing SHA-1 with RSA, make sure your applications support it. Netscape Navigator 3.0 (or later) and Enterprise Server 2.01 (or later) support SHA-1.

    • SHA-1 with DSA generates a 160-bit message digest. Before choosing SHA-1 with DSA, make sure your applications support it. Communicator 4.0 (or later) and Netscape server products with a version number greater than 4.0 support it.

    Before selecting an algorithm, make sure that Certificate Manager has the algorithm enabled.

  4. Click Display to examine the CRL (before updating it).

    The CRL appears in the browser window. In the list, look for the certificate revoked by the clone Certificate Manager. If you don't see the certificate, check logs to resolve the problem.

  5. If you want to update the CRL with the latest certificate revocation information, use the browser's Back button to return to the previous page and click Update.


Step 10. Use Master CA's Agent Certificate in Clone CAs

This step is optional.

The procedure below explains how to use the master Certificate Manager's agent certificate for a clone Certificate Manager (instead of creating a new agent certificates for clone CAs).

  1. Go to the configuration directory of a cloned CA: <server_root>/cert-<instance_id>config

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

  3. Locate this line: agentgateway.enableAdminEnroll=true

  4. Change the value to false: agentgateway.enableAdminEnroll=false

    This configures the cloned CA in to a mode where it expects a certificate (that was already issued and chains properly) to be presented when you access its agent interface.

  5. Restart the clone CA.

  6. Use Netscape Console and open the CMS window for the clone CA instance.

  7. Go to the "Users and Groups" section, create a new agent user, and add the master CA's agent certificate to the clone CA's certificate database.

    To add the correct certificate, check the serial number of the master CA's agent certificate; this certificate should already exist in one of the browsers that you use to access the master CA's agent interface. Use the serial number to search for the certificate in the master CA's certificate repository. Once you locate the certificate, look for its base-64 encoded form, copy it, and then paste it as the agent certificate in the clone CA.

    For step-by-step instructions to create an agent user, see "Setting up Agents Using the Manual Process".

  8. After creating the agent entry for the clone CA, go to https://<cloneCA hostname>:<agent_port> to verify that you can access its agent interface successfully.

  9. Repeat the above steps for other clone CAs.



Viewing Instance Information

In Netscape Console, you can view some of the basic information—the name and version number of the server, the directory in which it's installed, and date it was installed—about a CMS instance.

To view information pertaining to a specific CMS instance:

  1. Log in to Netscape Console (see "Logging In to Netscape Console").

  2. In the Console tab, double-click the server group that contains the CMS instance you want to view.

  3. In the list of server instances, select the CMS instance you want to view.

    The right pane shows information about the selected CMS instance.

    The information displayed includes the following:

    Server Name. A descriptive name of the CMS instance. You can change this name; see "Changing the Name of an Instance").

    Description. Additional information that helps you identify the CMS instance. You can change this description; see "Changing the Name of an Instance".

    Installation Date. The date the server was installed.

    Server Root. The directory that holds all the files for the selected CMS instance, the files of its Administration Server, and the files of any other Netscape servers in the same server group (that is, administered by that Administration Server). A host typically has only one server root, but more than one is possible, especially if different version numbers of the same server are installed on a single host.

    The default server root in Unix is usr/netscape/server4/ and in Windows NT is C:\Netscape\Server4.

    Product Name. The complete product name.

    Vendor. The name of the vendor.

    Version. The version number.

    Build Number. The number that identifies the build that was used for this installation.

    Security Level. The server's security level—whether the server is meant for use in the United States and Canada (domestic) or any other part of the world (export). (See "Configuring the Server's Security Preferences")

    Server Status. The server's status—whether it is started, stopped, or unknown; normally, unknown indicates that the server hasn't been configured properly.



Changing the Name of an Instance

Following installation, the name of a CMS instance is in the form:

CMS (cert-<instance_id>)

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

For example, if you installed an instance of Certificate Management System with an ID of testCA, the instance name will be cert-testCA.

You can change the instance name to a more descriptive one later. If you change the instance name, Certificate Management System uses the new name as a descriptive nickname for the instance. It shows the new name in Netscape Console only; it does not change the original instance ID in the configuration.

To change the name of a particular CMS instance:

  1. Log in to Netscape Console (see "Logging In to Netscape Console").

  2. In the Console tab, select the CMS instance you want to rename.

  3. Click Edit.

    Details about the selected CMS instance appear in the right pane.

    Specify the appropriate information:

    Server Name. Type a descriptive name for the server.

    Description. Type any additional description for the server. For example, you may want to type information that will help you identify this instance of Certificate Management System.

  4. Click OK.

    You are returned to the previous screen. The new name appears in the right pane.



Removing an Instance From a System

If you are sure you won't need a particular CMS instance anymore, you can use Netscape Console to remove the server instance from your machine. Removing a CMS instance is not the same as uninstalling Certificate Management System; when you uninstall Certificate Management System, its program files are deleted from the host machine. (For instructions, see "Uninstalling Certificate Management System".)

To remove a CMS instance from your machine:

  1. Log in to Netscape Console (see "Logging In to Netscape Console").

  2. In the Console tab, select the CMS instance you want to remove.

  3. From the Object menu, choose Stop; you can also right-click to choose this option from the pop-up menu (see the figure below).

  4. When the server has stopped, from the Object menu, choose Remove Server.

    As shown in the figure below, you can also right-click to choose this option from the pop-up menu.

  5. When prompted, confirm that you want to remove the server instance.

    The selected CMS instance is removed. The corresponding internal database is not removed. If you want to remove it, select the instance, and repeat steps 3 through 5.

    The Directory Server (configuration directory) and Administration Server binaries are also not removed; you require these to administer the remaining servers installed in the same server group.



Uninstalling Certificate Management System

To remove files pertaining to Certificate Management System from a host system, run the uninstallation program. Uninstalling Certificate Management System removes all the corresponding CMS instances from the navigation tree of Netscape Console. To remove a specific CMS instance, follow the instructions provided in "Removing an Instance From a System".

You can uninstall Certificate Management System in two ways:

  • From the command line (locally only)

  • On a Windows NT system, by using the Windows NT Add/Remove Programs Utility


Uninstalling From the Command Line

To uninstall Certificate Management System from the command line:

  1. Open a terminal window to your server.

  2. In a Unix system, log in either as root or using the server's user account (if that is how you started the server).

  3. At the command-line prompt, enter the following line:

    On Windows NT, enter <server_root>\uninst.

    On Unix, enter <server_root>/uninstall.

    The uninstallation program starts.


Uninstalling by Using the Windows NT Add/Remove Programs Utility

To remove Certificate Management System by using the Windows NT Add/Remove Programs utility:

  1. From the Start menu, choose Settings, then Control Panel.

  2. In the Control Panel, choose Add/Remove Programs.

  3. In the Add/Remove Programs Properties window, choose Netscape Server Products 4.2 <server_root>, and click Add/Remove.

  4. In the Netscape Server Uninstall window, make sure all the components are selected, and click Uninstall.

    The uninstallation program starts.



Upgrading From a Previous CMS Installation

If you have an existing installation of Certificate Management System version 4.2, you can upgrade to Certificate Management System 4.2, Service Pack 2 (SP2), by installing CMS 4.2-SP2 into the same server root as that of CMS 4.2. When prompted to specify the instance name, you must enter the name of the CMS instance that you want to upgrade. If the specified CMS instance exists in the selected server root, the installation program recognizes the instance and updates the existing configuration automatically. Note that during installation, you must specify the same port numbers that are in use by existing services, such as the Administration Server port for Netscape Console. If you have multiple CMS instances under the same server root, you must run the installation program for each instance.

Note the following:

  • Prior to attempting any upgrade from CMS 4.2 to CMS 4.2-SP2, always remember to shutdown all instances of the Console, as these clients are never shutdown by the upgrade process, and therefore, may not be correctly updated.

  • Only the CMS instance you specify in the upgrade panel is updated, although all of the global files are restored upon updating each and every instance. Therefore, you must perform the upgrade process for each and every CMS instance individually.

  • All CMS instances are shutdown each time so that any global CMS information may be updated.

  • Backup copies of the following list of original files and directories are saved with an underscore and timestamp appended (for example, classes/ becomes classes_20000506035603Z/) before the new file or directory replaces them:

    - Instance Specific:
          - classes/ (directory)
          - emails/ (directory)
          - restart-cert[.bat] (file)
          - start-cert[.bat] (file)
          - stop-cert[.bat] (file)
          - web/ (directory)

    - Globally Specific: (backed up for each instance)
          - bin/cert/classes/ (directory)

  • Since the start and restart scripts are always replaced on a per instance basis, any changes you have made will be backed up, and you must manually edit these scripts to put back your customizations.

  • All CMS instances are restarted. During restart, you are prompted for the single sign-on password, if automatic restart has not already been configured/reconfigured ahead of time.

  • There should be no reason to configure an updated instance (by running the CMS Installation Wizard), as there is on a first-time installation.

  • You may upgrade an instance numerous times to restore any corrupted global binaries. However, backup copies of the files and directories detailed above will be created upon each update.

  • Occasionally, upgrade does not allow you to specify the port number for the console to be reused. It is okay to use a different port number for the console, however, you must remember to use this new port number the next time that you login to Netscape Console.

  • Since upgrades must be done on a per instance basis, if you have two instances, and if you upgrade the first and then launch the console, you may notice that the instance that has not been upgraded will be displayed out of alignment within the GUI. You can consider this as a visual clue that you need to upgrade this instance as well. After upgrading this, the instance will appear aligned correctly within the GUI.

Follow the procedure below to upgrade a CMS instance:

  1. Identify the CMS 4.2 instance that you want to upgrade and note the corresponding server root and instance ID.

  2. Prior to attempting any upgrade, shutdown all instances of the Console, as these clients are never shutdown by the upgrade process, and therefore, may not be correctly updated.

  3. Extract files from the CMS archive; you can get the archive from the product CD or from the iPlanet download site (at http://www.iplanet.com).

  4. In the list of extracted files, locate this file: ns-certsrv4_2SP2.conf

  5. Go to the file structure of the CMS instance that you want upgrade, and navigate to the configuration directory of the internal database (the Directory Server instance used for storing CMS data): <server_root>/slapd-<cms_instance_id>-db/config

  6. Copy the ns-certsrv4_2SP2.conf file to this directory.

  7. Run the setup program.

    When you run the installation program for upgrading a CMS 4.2 instance, you will be presented with a series of screens or panels; the example below lists the panels on UNIX. Follow the on-screen prompts and complete the upgrade process.

    • Welcome

    • License

    • Product Selection

    • Location (You must specify the same server root or installation directory that was used for your 4.2 Console.)
      - Server Products Components
      - Core Components
      - Directory Suite Components
      - Administration Service Components
      - Certificate Server Components

    • Fully qualified domain name of machine

    • User and Group
      - System User
      - System Group

    • Configuration Directory Server Administration Identifier
      - Administrator ID
      - Password

    • Administration Server Port for Console (You must enter the same port number that was used for your 4.2 Console.)
      - Administration Server User
      - Certificate Server Identifier       (The CMS instance name that you enter in this panel must exist.)


Previous     Contents     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated April 02, 2001