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 Server (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 iPlanet Console, the single, unified administration interface for your network.

You can use iPlanet Console only when iPlanet 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 iPlanet Console. For more information about iPlanet 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 iPlanet Console (see Logging In to iPlanet 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 iPlanet Console of the master Certificate Manager (see Logging In to iPlanet 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 iPlanet 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/iplanet/servers, you can specify /u/iPlanet/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 iPlanet 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 iPlanet 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-----

    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRz
    Y2FwZSBDb21tdW5pYF0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X
    DTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ld
    HNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzAVBgoJkiaJk
    IsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSI
    b3DbndgJARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANL
    ADBIAkEAoYiYgthgtbbnjfngjnjgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZI
    AYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kT
    XawbwamGdYql2w4hIBgdR+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-----

    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRz
    Y2FwZSBDb21tdW5pYF0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X
    DTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ld
    HNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzAVBgoJkiaJk
    IsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSI
    b3DbndgJARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANL
    ADBIAkEAoYiYgthgtbbnjfngjnjgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZI
    AYb4QgEBAQHBAQDAgCAMA0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kT
    XawbwamGdYql2w4hIBgdR+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 iPlanet 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 iPlanet 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 iPlanet 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 iPlanet Console (see Logging In to iPlanet 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 ).

    Description. Additional information that helps you identify the CMS instance. You can change this description; see .

    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 iPlanet 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/iplanet/servers/ and in Windows NT is C:\iPlanet\Servers.

    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 iPlanet 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 iPlanet Console (see Logging In to iPlanet 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 iPlanet 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 iPlanet Console (see Logging In to iPlanet 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 iPlanet 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 iPlanet Server Products 4.7 <server_root>, and click Add/Remove.

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

    The uninstallation program starts.

If you want to install a separate, stand-alone version of iPlanet Console for any reason, you can download it from this site: http://www.iplanet.com/downloads/patches/



Upgrading From Version 4.2 SP2 to Version 4.7


The only direct migration path to Certificate Server 4.7 is from version 4.2, Service Pack 2 (SP2). If you have an existing installation of Certificate Management System version 4.2 or earlier, you must first upgrade to version 4.2SP2. Follow the instructions in the section Upgrading to Version 4.2 SP2.

If you already have an existing installation of Certificate Server 4.2 SP2, use the following instructions.


The CMS Migration Tool

Certificate Server 4.7 provides a utility that migrates certificates, keys, CRLs, and related user information contained in the Internal DB directories. The tool migrates only Certificate Server instances, and only on a single host; it does not span multiple machines. There are two versions of the migration utility, one for Unix and one for Windows. All steps listed in the migration tool documentation are performed.

Log files containing migration details can be found in the following directories:

Solaris:

/47_binaries_location/migration_MM-DD-YYYY-HH_MM_SS.log for   migration details

Windows:

\47_binaries_location\migration-MMDDYYYY.log


Known Issues and Workarounds

  • If you're upgrading a Windows NT or 2000 installation:

    • If you use a third-party tool such as MKS toolkit, then the PATH should have the MKS toolkit as the last entry. Otherwise, the perl script will fail to execute.

    • During the migration and after Certificate Server 4.2SP2 is uninstalled, if this message displays: "There are files marked for deletion upon next Reboot, Do you wish to Reboot now?" do not reboot; enter "No."


Before You Begin

You should address the following issues before running the migration tool:

  • Migration to Certificate Server 4.7 can be performed only on the same machine where Certificate Server 4.2SP2 is installed.

  • Back up the your CMS 4.2SP2 installation in case you need to recover your data.

  • Gather information about the servers running on the system. For example, you should know the server names, ports, and plug-ins being used, and so on.

  • Know the passwords for the iPlanet Console administrator, the Certificate Server administrator, the LDAP data bases, the single sign-on for each instance.

  • Close the 4.2SP2 Certificate Server window, and close any instances of iPlanet servers before starting the migration process.

  • Process all 4.2SP2 pending certificate requests.

  • Close all sessions to Certificate Server 4.2SP2. Do not access Certificate Server until after the migration process is completed.

  • On Unix, you should run the migration tool as the same user who installed CMS 4.2SP2.

  • Know the location of the unzipped Certificate Server 4.7 binaries.

  • If a Certificate Server instance has been deleted from the installation, then delete its corresponding internal database instance.

  • The migration tool needs ample space to backup the Certificate Server instances. Be sure that there is sufficient disk space in /var/tmp and the new 4.7 installation directory for Unix/Solaris, or in the default system drive for Windows NT/2000.

  • On Windows only:

    • Prior to running the migration tool, you should install PERL on a directory other than the one that contains the PERL that comes with Certificate Server 4.2SP2. If the PATH to PERL is set to the PERL that comes with Certificate Server 4.2SP2, the PATH will be invalid after uninstallation.

    • If possible, take a system image of your machine for recovery purposes.

    • You should run the migration tool as Administrator.


Running the Migration Tool on Unix

The Unix version is a bourne shell script and is supported on Solaris.

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

  2. Extract files from the Certificate Server archive; you can get the archive from the product CD or from the iPlanet download site (at http://wwws.sun.com/software/download/).

  3. In the list of extracted files, locate this file: /dist/MigrationSolaris.

  4. Run the following command:

    cd <extracted root>/dist

  5. Run the migration tool:

    . /MigrationSolaris

  6. The script prompts you to provide the following information:

    1. Installed location of CMS 4.2 SP2:

    2. Do you want the Migration script to run the cmsbackup tool for each CMS instance?

    3. Install location for CMS 4.7:

    4. Location of extracted CMS 4.7 distribution:

    5. Please make sure that at least <X> space is available in the respective partitions. Continue?

    6. Please verify the Admin password for the Administration Server:

    7. Please enter the password for the configuration Directory Manager:

    8. Please enter the Single Sign-On password:

  7. After the script has finished running, verify that the new installation works and that your data has been successfully migrated.

  8. Manually uninstall Certificate Server 4.2 SP2.


Running the Migration Tool on Windows

This is PERL script using PERL 5.005 or higher.

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

  2. Extract files from the Certificate Server archive; you can get the archive from the product CD or from the iPlanet download site (at http://wwws.sun.com/software/download/).

  3. In the list of extracted files, locate this file: MigrationNt.pl

  4. Run the migration tool:

    MigrationNt.pl

    You can invoke the script with the -v option to see debug messages.

  5. The script will prompt you to provide the followin information:

    1. The absolute pathname of the 4.2 SP2 Certificate Server Root Directory:

    2. The absolute pathname for the new 4.7 Certificate Server Root Directory:

    3. The absolute pathname of the CMS 4.7 binaries:

    4. Please verity the Admin password for the Administration Server:

    5. What is the Directory Manager Password?

    6. Do you want to delete the temporary backup files?

  6. After the script has completed, reboot the computer system.

  7. Verify that the new installation works and that your data has been successfully migrated.

The migration tool for Windows automatically uninstalls the 4.2SP2 installation. It is a good practice to check the old installation directory and to delete any remaining files.



Upgrading to Version 4.2 SP2


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 iPlanet 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 iPlanet 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.sun.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 © 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated October 07, 2002