Administrator's Guide Netscape Certificate Management System

Previous      Contents      Index      DocHome      Next

Chapter 17   Configuring CMS for High Availability

This chapter explains how to create and configure the Netscape Certificate Management System for high availability. CMS allows you to clone various subsystems and run the cloned instances on different machines. This provides failover support by ensuring that CMS services continue, even if the machine on which the master instance was installed goes down.

The following sections provide an overview of CMS high availability, recommendations about configurations that work best, and information about how to install and configure each of the subsystem clones:

• CMS High Availability Overview
• Cloning the Certificate Manager
• Cloning the Online Certificate Status Manager
• Cloning the Data Recovery Manager

CMS High Availability Overview

---

High availability systems reduce unplanned outages and other problems by making one or more subsystem clones available for failover. When a host machine goes down in an unplanned outage, high availability systems can handle requests and perform services from an alternate system in a seemless, uninterrupted way.

High availability configurations also allow you to take down systems for repair, troubleshooting, or other administrative tasks without interrupting the services of a system such as CMS.

Typically, master and cloned instances are installed on different machines, and those machines are placed behind a load balancer. The load balancer accepts HTTP and HTTPS requests made to the CMS system and directs those requests appropriately between the two machines. In the event that one machine fails, the load balancer will transparently redirect all requests to the machine that is still up and running until such time as the other machine is brought back online. The cloning feature in CMS also supports scalability by assigning the same task to separate instances on different machines (e.g., handling certificate requests) in a seemless way.

The following subsystems can be cloned and run on different hosts:

• Certificate Manager (CA) (see Certificate Manager)
• Data Recovery Manager (DRM) (see Data Recovery Manager)
• Online Certificate Status Manager (see OCSP Responder)

Architecture of a Failover System

The diagram in Figure 17-1 shows one way to set up a cloned CMS system. In this system, a separate OCSP Responder subsystem is handling certificate verification by taking advantage of the CRL Publishing feature.

Figure 17-1    CMS Setup Example

As this diagram indicates, only one of the CAs can generate the CRLs. See Cloned-Master CA Conversion for more information about configuring a clone for CRL generation during failover.

Load balancing

The load balancer in front of a CMS system is what provides the actual failover support in a high availability system. A load balancer can also provide the following advantages as part of a CMS system:

• DNS round robin, a feature for managing network congestion that distributes load across several different servers.
• Sticky SSL, which makes it possible for a user returning to the system to be routed the same host they used previously.

Consult the documentation for the load balancer you intend to use with CMS to read more about the features, advantages, and configuration of a load balancer.

Cloning the Certificate Manager

---

Once you have installed the first Certificate Manager instance and configured it properly (see "Cloning Preparation" below), you can create a clone of the first CA by following the instructions in "Cloning the CA."

Cloning Preparation

Before you can create a clone, you must make sure that the instance you are cloning has been properly installed and configured, since some of that configuration data is copied over to the new instance. In particular you must verify the following aspects of the master CA:

1. The master CA must have been fully configured with the installation wizard. To review this configuration process for the master CA, see Configuring the Certificate Manager. Also verify the following:
• Check the master Certificate Manager's serial number range. The "Ending certificate number" field must not be blank.

The serial number range of the cloned Certificate Manager must be unique, and must not overlap with that of the master Certificate Manager.
 

• Check the master Certificate Manager's request number range. The "Ending request number" field must not be blank.

The request number range of the cloned Certificate Manager must be unique, and must not overlap with that of the master Certificate Manager.
 

• Verify that this master instance is running.

The CA instance automatically starts up once it's been properly configured. If you need to start or restart the Certificate Manager manually, you may do so by invoking the start-cert or restart-cert commands, which are available in the CA instance directory:
 

<serverRoot>/cert-<instance_id>/
 

• Make sure that you have already installed the agent certificate for the master instance. See Agent Certificates for more information about getting agent certificates.

Once you have verified these aspects of the master CA, consider the following for the cloned CA.

• CA's serial number range—Each cloned Certificate Manager must be configured to issue certificates with unique serial numbers. This means that when you configure a cloned 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 cloned Certificate Manager.

When specifying the serial number range for the first cloned Certificate Manager, it's recommended that you start with 0x100, for example, as the "Starting certificate 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 when you renew its certificates in the future. Any subsequent cloned Certificate Manager does not need 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 cloned 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 way in which you have deployed the clone environment. If you are using a load balancer, regardless of whether or not the host machines are different, you do not need to generate a new SSL server certificate for the cloned Certificate Manager, since the SSL server certificate DN should contain the hostname of the load balancer as the common name (CN) attribute. If the cloned Certificate Manager uses the same hostname as that of the master Certificate Manager and you are not using a load balancer, you can use the same SSL server certificate and key copied from the master Certificate Manager. If you are not using a load balancer and your master and cloned Certificate Managers exist on separate machines (e. g. - a proprietary configuration which expects usernames [A-M] using one machine and usernames [N-Z] using the other machine), then the SSL server certificate DNs should contain the hostname of their resident machines with their own unique keys obtained by using the renewal process (this scenario requires advanced manual configuration and therefore is not recommended).

Cloning the CA

To setup cloning for a Certificate Manager (CA) subsystem:

1. From the Object menu in the Netscape Console, choose Create Instance Of, then choose Netscape Certificate Management System.Alternatively, you can right-click the Server Group node and choose Create Instance Of > Netscape Certificate Management System.

The admin console asks you to provide a name for the new instance; enter the name of the new Certificate Manager instance in the dialog provided.
 

2. The Installation Wizard displays a dialog asking you to specify whether this new instance is a clone. Answer Yes and click Next.

3. The Installation Wizard asks you to copy the key and certificates from the master CA to the clone if you have not already done so.

4. Copy the master CA's Certificate and Key Database.

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

• If the master Certificate Manager's keys and certificates are stored in the internal/software token, you need to copy the certificate and key database files from the master Certificate Manager to Certificate Manager clone. Here's how you do this:
1. On the master Certificate Manager's host machine, go to this directory: <server_root>/alias
2. Locate the certificate and key database files; the file names are as follows:
   cert-<instance_id>-<machine_name>-cert8.db
cert-<instance_id>-<machine_name>-key3.db
3. On the host machine of the cloned Certificate Manager, go to this directory: <server_root>/alias
4. Copy the certificate and key database files from the master Certificate Manager to the clone.
• If the master Certificate Manager's keys and certificates are stored in the hardware token, you must also copy the keys and certificates following the instructions provided by the hardware-token vendor.
5. Open the Server Group item, select the cloned CA, and click Open again to resume configuration where you left off in the installation wizard.

Click Next in the Clone Feature dialog once you have followed the instructions in Step 4 and copied over the key and certificate material.
 

6. Designate the password for the internal token in the Logon Token dialog.
7. In the Master Database dialog, enter the hostname, port, and password for the Master Database of the CMS system.

8. In the Local Consumer Database dialog, specify what type of database you are creating.
1. Either select Create a local consumer database to create a new clone database local to the cloned Certificate Manager:

1. Or select Connect to the existing remote LDAP server to use the existing LDAP server as the internal database for the cloned Certificate Manager instance.

If you select the remote database, make sure that you have already created an LDAP server containing a base suffix of o=netscapeCertificateServer on the host whose host name and port number you specify in the fields in the lower portion of the Installation Wizard:
 

9. Configure replication between the cloned CA database and the master CA database in the following dialog.

Follow the instructions on screen to create the password for the Replication Manager role in the Master database, the password for the Replication Manager role in the Consumer database, and the agreement names between the master and clone's databases. See Configuring the Certificate Manager for more information.
 

10. In the following dialog, enter the certificate and request number ranges for the cloned Certificate Manager.

Be aware of the following as you designate the serial number ranges for the certificate and request numbers of the cloned Certificate Manager:
 

• CA's serial number range—On this screen, specify the lowest serial number the CA should assign to certificates it creates in the "Starting certificate number" field. In the "Ending certificate 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).
• CA's request number range—On this screen, specify the lowest request number the CA should accept for requests that it receives in the "Starting request number" field. In the "Ending request number" field, specify the highest request number acceptable to be received by this CA.

11. In the Network Configuration dialog, enter the port numbers for the ports through which the cloned CA will communicate with the end entities and the other subsystems in the CMS.

Specify the master CA's agent port in the Agent Port field so that the clone can redirect "Update CRL" requests to the master CA (see About CRLs for more information about CRLs).
 

12. Choose the cloned CA's signing certificate, the OCSP's signing certificate, and the SSL server certificate from the pull-down menus provided in the Clone Key and Certificate Materials for CA Subsystem dialog.

In order for these fields to be populated properly, you have to have already copied over the appropriate certificates from the master CA. If you do not see certificates in the pull-down menus, follow the instructions in Step 4 above to copy the key and certificate database material over correctly.
 

13. Configure the master CA's CRL cache to accept changes from the new clone.

Once the Installation Wizard creates the instance, you have to take one last step to make sure that the CRL cache in the master CA reflects revocation data in the cloned CA.
 

To do this:
 

1. Go to the master CA directory at the command line:

cd <serverRoot>/cert-<masterID>
 

2. Stop the master CA server by issuing the following command in that directory:

./stop-cert
 

3. Go to the master CA's server config directory:

cd <serverRoot>/cert-<masterID>/config
 

4. Edit the CMS.cfg file by adding the following line:

ca.listenToCloneModifications=true
 

5. Close and save the CMS.cfg file.
6. Go to the master CA directory at the command line:

cd <serverRoot>/cert-<masterID>
 

7. Restart the master CA server by issuing the following command in that directory:

./start-cert
 

Once the configuration for the cloned CA instance is done, the cloned CA instance will be available. The administrator should be able to see all the requests and certificates from either this cloned CA or the master CA. Additionally, for the purpose of high availability, it is strongly encouraged that CRL publishing is enabled in this cloned CA, presuming that CRL publishing has been enabled in the master CA.

Also, it should be understood that any configurations made to a master CA will also need to be setup in each cloned CA. The only two exceptions to this rule are the Users and Groups and the Access Control Lists, both of which are provided through the CMS console.

Testing the CA Cloned-Master Connection

Follow these steps to test whether your cloned-master CA setup is complete and functional.

1. Request a certificate from the cloned CA.
2. 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 agent-approved enrollment form for requesting the certificate; the request you submitted is waiting in the agent queue for approval by an agent.
 

3. Download the certificate to the browser.
4. Revoke the certificate.
5. 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, go to the master Certificate Manager's Agent Services interface. In the left frame, click Update Certificate Revocation List. Find the CRL and display it.
 

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

Additional CRL Scheduling Information

---

By default, full and delta CRLs are generated at the same time. Usually, most CRLs contain a field that specifies the next update time for both full and delta CRLs. By default, for full CRLs, this field indicates the generation time of the next full CRL. However, full CRLs can be generated every "n" deltas. By adding the following parameter, the user is able to control the contents of the next update field. Setting this parameter will cause the next update field to be set to the time of the next delta CRL generation.

1. Go to the master CA directory at the command line:

cd <serverRoot>/cert-<masterID>
 

2. Stop the master CA server by issuing the following command in that directory:

./stop-cert
 

3. Go to the master CA configuration directory at the command line:

cd <serverRoot>/cert-<masterID>/config
 

4. Open the CMS.cfg file for editing, and add the following line to affect the next update field in the CRL:

ca.crl.extendedNextUpdate=false
 

5. Close and save the CMS.cfg file.
6. Go to the master CA directory at the command line:

cd <serverRoot>/cert-<masterID>
 

7. Restart the master CA server by issuing the following command in that directory:

./start-cert
 

Cloned-Master CA Conversion

---

In the event that the user needs to convert an existing cloned CA into a new master CA (e. g., a catastrophic failure of the existing master CA), one needs to first convert the existing offline master CA into a clone followed by converting one of the current existing online cloned CAs into the new online master CA.

The difference between a master CA and a cloned CA are the following:

• Master CAs control the database maintenance thread (this is disabled in cloned CAs)
• Master CAs monitor database replication changes
• Master CAs maintain the CRL cache
• Master CAs generate the CRL
• Cloned CAs redirect CRL generation requests

Note	Clones should never be configured to generate CRLs. Clones can revoke, display, import, and download CRLs previously generated by master CAs, but having them generate new CRLs may cause synchronization problems. The rule is that only a single CA should generate CRLs, and this task is always left to the master CA.

Converting a Master CA into a Cloned CA

---

Since only one master CA can exist for a CMS installation, the offline master must first be converted into a cloned CA since one of the cloned CAs will become the new master CA (see Converting a Cloned CA into a Master CA).

First, ensure that the existing master CA is not running:

1. Go to the existing master CA configuration directory at the command line:

cd <serverRoot>/cert-<masterID>/config
 

2. Open the CMS.cfg file for editing, and make the following changes:
1. To disable control of the database maintenance thread, modify the following line if it exists by changing the value to "0" (adding the line in if it does not already exist):

ca.certStatusUpdateInterval=0
 

2. To disable monitoring database replication changes, modify the following line if it exists by changing "true" to "false" (adding the line in if it does not already exist):

ca.listenToCloneModifications=false
 

3. To disable maintenance of the CRL cache, modify all of the "enableCRLCache" lines if they exist by changing "true" to "false" (adding each line in if it does not already exist):

ca.crl.<IssuingPointId>.enableCRLCache=false
 

4. To disable CRL generation, modify all of the "enableCRLUpdates" lines if they exist by changing "true" to "false" (adding each line in if it does not already exist):

ca.crl.<IssuingPointId>.enableCRLUpdates=false
 

5. To enable CRL generation requests redirection, add the following two lines:

master.ca.agent.host=<hostname>
 

master.ca.agent.port=<port number>
 

3. Close and save the CMS.cfg file.

Converting a Cloned CA into a Master CA

---

Having already converted the existing offline master CA into an offline cloned CA (see Converting a Master CA into a Cloned CA), and since only one master CA can (and should) exist for a CMS installation, one of the online cloned CAs must now be converted into the new online master CA.

First, ensure that the existing master CA is no longer running and has already been converted into an offline cloned CA:

1. Go to one of the cloned CA's directories at the command line:

cd <serverRoot>/cert-<cloneID>
 

2. Stop this online cloned CA server by issuing the following command in that directory:

./stop-cert
 

3. Go to this cloned CA's configuration directory at the command line:

cd <serverRoot>/cert-<cloneID>/config
 

4. Open the CMS.cfg file for editing, and make the following changes:
1. Delete each line of configuration data from this cloned CA's configuration file called <serverRoot>/cert-<cloneID>/config/CMS.cfg which begins with the ca.crl. prefix:

ca.crl.*
 

2. Copy the configuration data from the existing offline master CA to this cloned CA by opening the file called <serverRoot>/cert-<masterID>/config/CMS.cfg and copying each line beginning with the ca.crl. prefix into this selected cloned CA's <serverRoot>/cert-<cloneID>/config/CMS.cfg file:

ca.crl.*
 

3. To enable control of the database maintenance thread, modify the following line changing the value "0" to "600" (600 is the default value for the master CMS. This value can be changed to any other non-zero number):

ca.certStatusUpdateInterval=600
 

4. To enable monitoring database replication changes, modify the following line changing "false" to "true":

ca.listenToCloneModifications=true
 

5. To enable maintenance of the CRL cache, modify all of the "enableCRLCache" lines changing "false" to "true":

ca.crl.<IssuingPointId>.enableCRLCache=true
 

6. To enable CRL generation, modify all of the "enableCRLUpdates" lines changin "false" to "true":

ca.crl.<IssuingPointId>.enableCRLUpdates=true
 

7. To disable CRL generation requests redirection, remove the following two lines:

master.ca.agent.host=<hostname>
 

master.ca.agent.port=<port number>
 

5. Close and save the CMS.cfg file.
6. Go to this cloned CA's directory at the command line:

cd <serverRoot>/cert-<cloneID>
 

7. Start the new master CA server by issuing the following command in that directory:

./start-cert
 

Cloning the Online Certificate Status Manager

---

Recall that CMS systems may include both an OCSP service internal to the Certificate Manager, which responds to status requests by going to the Certificate Manager's internal database, and a separate Online Certificate Status Manager subsystem. When you create an OCSP clone, you are setting up a second instance of this Online Certificate Status Manager subsystem to handle status requests based on CRLs published to it by one or more Certificate Managers (see Publishing of CRLs for more about the CRL publishing feature). The OCSP database to which CRLs are published is replicated in the cloned OCSP database, and requests to the Online Certificate Status Manager are, or can be, sent to a load balancer that shares requests between the master Online Certificate Status Manager and its clone, as Figure 17-2 illustrates.

Figure 17-2    Cloned Online Certificate Status Manager Setup

See CMS OCSP Services for more information about OCSP services.

Preparing to Clone the Online Certificate Status Manager

Before you can create a clone of the Online Certificate Status Manager, you must make sure that the instance you are cloning has been properly installed and configured, since some of that configuration data is copied over to the new instance. In particular you must verify the following aspects of the master Online Certificate Status Manager that you want to clone:

1. Make sure that you have gone through the installation wizard and properly configured the first Online Certificate Status Manager. See "Configuring the Online Certificate Status Manager" on page 195.
2. After finishing the configuration of this master instance, make sure the instance is up and running.
3. Make sure that you have already installed the agent certificate for the master Online Certificate Status Manager. See Agent Certificates for more information about agent certificates.
4. Also consider the following:
• OCSP's signing key and certificate—You must use the master Online Certificate Status Manager's signing key and certificate. If you do not use the master Online Certificate Status Manager's key and certificate databases, the cloned Online Certificate Status Manager will need to generate a new signing key and certificate; consequently, it will not be a clone.
• OCSP's SSL server key and certificate—This depends on the way in which you have deployed the clone environment. If you are using a load balancer, regardless of whether or not the host machines are different, you do not need to generate a new SSL server certificate for the cloned Online Certificate Status Manager, since the SSL server certificate DN should contain the hostname of the load balancer as the common name (CN) attribute. If the cloned Online Certificate Status Manager uses the same hostname as that of the master Online Certificate Status Manager and you are not using a load balancer, you can use the same SSL server certificate and key copied from the master. If you are not using a load balancer and your master and cloned Online Certificate Status Managers exist on separate machines (e. g. - a proprietary configuration which expects usernames [A-M] using one machine and usernames [N-Z] using the other machine), then the SSL server certificate DN's should contain the hostname of their resident machines with their own unique keys obtained by using the renewal process (this scenario requires advanced manual configuration and therefore is not recommended).

For more detailed information about setting up the master Online Certificate Status Manager, see Configuring the Online Certificate Status Manager.

Cloning the OCSP Responder

The following are the steps to setup cloning for an Online Certificate Status Manager:

1. From the Object menu in the Netscape Console, choose Create Instance Of, then choose Netscape Certificate Management System. Alternatively, you can right-click the Server Group node and choose Create Instance Of > Netscape Certificate Management System. The admin console asks you to provide a name for the new instance; enter the name of the new Online Certificate Status Manager instance in the dialog provided.
2. The Installation Wizard displays a dialog asking you to specify whether this new instance is a clone. Answer Yes and click Next.
3. The Installation Wizard asks you to copy the key and certificates from the master OCSP Responder to the clone if you have not already done so.
4. Copy the master OCSP Responder's Certificate and Key Database.

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

• If the master Online Certificate Status Manager's keys and certificates are stored in the internal/software token, you need to copy the certificate and key database files from the master to the Online Certificate Status Manager clone. Here's how you do this:
1. In the master Online Certificate Status Manager's host machine, go to this directory: <server_root>/alias
2. Locate the certificate and key database files for the Online Certificate Status Manager; the file names are as follows:
   cert-<ocsp_instance_id>-<machine_name>-cert8.db
cert-<ocsp_instance_id>-<machine_name>-key3.db
3. On the host machine of the clone, go to this directory: <server_root>/alias
4. Copy the certificate and key database files from the master Online Certificate Status Manager to the clone.
• If the master Online Certificate Status 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.
5. Open the Server Group item, select the cloned OCSP Responder, and click Open again to resume configuration where you left off in the installation wizard.
6. Designate the password for the internal token in the Logon Token dialog.
7. In the Master Database dialog, enter the hostname, port, and password for the Master Database of the CMS system.
8. In the Local Consumer Database dialog, specify what type of database you are creating.
1. Either select Create a local consumer database to create a new clone database local to the cloned Online Certificate Status Manager.
2. Or, select Connect to the existing remote LDAP server to use the existing LDAP server as the internal database for the cloned Online Certificate Status Manager instance.

If you select the remote database, make sure that you have already created an LDAP server containing a base suffix of o=netscapeCertificateServer on the host whose host name and port number you specify in the fields in the lower portion of the Installation Wizard.
 

9. Configure replication between the cloned OCSP Responder database and the master OCSP Responder database.

Follow the instructions on screen to create the password for the Replication Manager role in the Master database, the password for the Replication Manager role in the Consumer database, and the agreement names between the master and clone's databases. See Configuring the Online Certificate Status Manager for more information.
 

10. Follow the instructions in the Installation Wizard to configure the Online Certificate Status Manager clone. In the Clone Key and Certificate Materials for the OCSP Subsystem dialog, choose the signing and SSL certificates that the clone will use.

In order for these fields to be populated properly, you have to have already copied over the appropriate certificates from the master CA. If you do not see certificates in the pull-down menus, follow the instructions in Step 2 above to copy the key and certificate database material over correctly.
 

Once the configuration for the clone is done, the cloned Online Certificate Status Manager will be available in the Netscape Console. Follow the instructions in the next section to verify that the clone and the master Online Certificate Status Managers have been properly configured to work together.

Also, it should be understood that any configurations made to a master OCSP Responder will also need to be setup in each cloned OCSP Responder. The only two exceptions to this rule are the Users and Groups and the Access Control Lists, both of which are provided through the CMS console.

Testing the OCSP Cloned-Master Connection

Follow these steps to test whether your cloned-master OCSP setup is complete and functional.

1. Setup OCSP Publishing in the master CA so that the CRL will be published to the master Online Certificate Status Manager.
2. Once the CRL is successfully published, check both the master and cloned Online Certificate Status Manager's List Certificate Authorities menu option in the agent interfaces. The output should be identical.
3. Use the OCSPClient tool to submit OCSP requests to the master and the cloned Online Certificate Status Manager. The tool should receive identical OCSP responses from both Managers.

Cloned-Master OCSP Responder Conversion

In the event that the user needs to convert an existing cloned OCSP Responder into a new master OCSP Responder (e. g. - a catastrophic failure of the existing master OCSP Responder), one needs to first convert the master existing offline master OCSP Responder into a clone followed by converting one of the current existing online cloned OCSP Responders into the new online master OCSP Responder.

The difference between a master OCSP Responder and a cloned OCSP Responder is the following:

• Cloned OCSP Responders contain a unique configuration parameter

Converting a Master OCSP Responder into a Cloned OCSP Responder

Since only one master OCSP Responder can exist for a CMS installation, the offline master must first be converted into a cloned OCSP Responder since one of the cloned OCSP Responders will become the new master OCSP Responder (see Converting a Cloned OCSP Responder into a Master OCSP Responder).

First, ensure that the existing master OCSP Responder is not running:

1. Go to the existing master OCSP Responder configuration directory at the command line:

cd <serverRoot>/cert-<masterID>/config
 

2. Open the CMS.cfg file for editing, and add the following line (21600 is the default value for a cloned OCSP Responder. This value can be changed to any other non-zero number):

ocsp.store.defStore.refreshInSec=21600
 

3. Close and save the CMS.cfg file.

Converting a Cloned OCSP Responder into a Master OCSP Responder

Having already converted the existing offline master OCSP Responder into an offline cloned OCSP Responder (see Converting a Master OCSP Responder into a Cloned OCSP Responder), and since only one master OCSP Responder can (and should) exist for a CMS installation, one of the online cloned OCSP Responders must now be converted into the new online master OCSP Responder.

First, ensure that the master master OCSP Responder is no longer running and has already been converted into an offline cloned OCSP Responder:

1. Go to one of the cloned OCSP Responders' directories at the command line:

cd <serverRoot>/cert-<cloneID>
 

2. Stop this online cloned OCSP Responder server by issuing the following command in that directory:

./stop-cert
 

3. Go to this cloned OCSP Responder's configuration directory at the command line:

cd <serverRoot>/cert-<cloneID>/config
 

4. Open the CMS.cfg file for editing, and delete the following line (21600 is the default value for a cloned OCSP Responder. This value can be equal to any other non-zero number):

ocsp.store.defStore.refreshInSec=21600
 

5. Close and save the CMS.cfg file.
6. Go to this cloned OCSP Responder's directory at the command line:

cd <serverRoot>/cert-<cloneID>
 

7. Start the new master OCSP Responder server by issuing the following command in that directory:

./start-cert
 

Cloning the Data Recovery Manager

---

The process for setting up a DRM clone is very similar to that for setting up a cloned CA. Since DRM cache information is stored in the memory for recovery operations, the whole remove recovery process needs to be performed on the same DRM.

Preparing to Clone the DRM

Before you can create a clone of the Data Recovery Manager, you must make sure that the master you are cloning has been properly installed and configured, since some of that instance's configuration data is copied over to the new instance. In particular you must verify the following aspects of the master Data Recovery Manager that you want to clone:

1. Make sure that the master Data Recovery Manager is configured and working properly. Also verify the following:
1. Check the master Data Recovery Manager's key number range. The "Ending key number" field must not be blank.

The key number range of the cloned Data Recovery Manager must be unique, and must not overlap with that of the master Data Recovery Manager.
 

2. Check the master Data Recovery Manager's request number range. The "Ending request number" field must not be blank.

The request number range of the cloned Data Recovery Manager must be unique, and must not overlap with that of the master Data Recovery Manager.
 

2. Verify that the master Data Recovery Manager instance is up and running.
3. Make sure that you have already installed the agent certificate for the master Data Recovery Manager. See Agent Certificates for more information about agent certificates.
4. Also consider the following:
• DRM transport certificate—The transport certificate for the master and cloned DRMs must be the same. See Configuring Key Archival and Recovery Process.
• DRM storage certificate—The storage certificate for the master and cloned DRMs must be the same. See Configuring Key Archival and Recovery Process.
• DRM's SSL server key and certificate—This depends on the way in which you have deployed the clone environment. If you are using a load balancer, regardless of whether or not the host machines are different, you do not need to generate a new SSL server certificate for the cloned Data Recovery Manager, since the SSL server certificate DN should contain the hostname of the load balancer as the common name (CN) attribute. If the cloned Data Recovery Manager uses the same hostname as that of the master Data Recovery Manager and you are not using a load balancer, you can use the same SSL server certificate and key copied from the master Data Recovery Manager. If you are not using a load balancer and your master and cloned Data Recovery Managers exist on separate machines (e. g. - a proprietary configuration which expects usernames [A-M] using one machine and usernames [N-Z] using the other machine), then the SSL server certificate DN's should contain the hostname of their resident machines with their own unique keys obtained by using the renewal process (this scenario requires advanced manual configuration and therefore is not recommended).

Cloning the DRM

The following are the steps to setup cloning for a DRM subsystem:

1. From the Object menu in the Netscape Console, choose Create Instance Of, then choose Netscape Certificate Management System. Alternatively, you can right-click the Server Group node and choose Create Instance Of > Netscape Certificate Management System. The admin console asks you to provide a name for the new instance; enter the name of the new Data Recovery Manager instance in the dialog provided.
2. The Installation Wizard displays a dialog asking you to specify whether this new instance is a clone. Answer Yes and click Next.
3. The Installation Wizard asks you to copy the key and certificates from the master DRM to the clone if you have not already done so.
4. Copy the master DRM's Certificate and Key Database.

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

• If the master Data Recovery Manager's keys and certificates are stored in the internal/software token, you need to copy the certificate and key database files from the master to the Data Recovery Manager clone. Here's how you do this:
1. In the master Data Recovery Manager's host machine, go to this directory: <server_root>/alias
2. Locate the certificate and key database files for the Data Recovery Manager; the file names are as follows:

cert-<kra_instance_id>-<machine_name>-cert8.db
 

cert-<kra_instance_id>-<machine_name>-key3.db
 

3. On the host machine of the clone, go to this directory:

<server_root>/alias
 

4. Copy the certificate and key database files from the master Data Recovery Manager to the clone.
• If the master Data Recovery 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.
5. Copy the master DRM's Configuration files.

Because you want the cloned Data Recovery Manager to own the same configuration files as that of the master Data Recovery Manager, you need to make the configuration files used by the master available to the Data Recovery Manager clone.
 

• If the master Data Recovery Manager's configuration files are stored in the internal/software token, you need to copy the and configuration files from the master to the Data Recovery Manager clone. Here's how you do this:
1. In the master Data Recovery Manager's host machine, go to this directory: <server_root>/cert-<masterID>/config/
2. Locate the configuration files for the Data Recovery Manager; the file names are as follows:

kra-cert.db
 

kra-key.db (if present)
 

kra-mn.conf
 

3. On the host machine of the clone, go to this directory: <server_root>/cert-<cloneID>/config/
4. Copy the configuration files from the master Data Recovery Manager to the clone.
• If the master Data Recovery Manager's storage keys and certificates are stored in the hardware token, you do not need to copy the kra-key.db files.
6. Open the Server Group item, select the cloned DRM, and click Open again to resume configuration where you left off in the installation wizard.
7. Designate the password for the internal token in the Logon Token dialog.
8. In the Master Database dialog, enter the hostname, port, and password for the Master Database of the CMS system.
9. In the Local Consumer Database dialog, specify what type of database you are creating.
1. Either select Create a local consumer database to create a new clone database local to the cloned Data Recovery Manager.
2. Or select Connect to the existing remote LDAP server to use the existing LDAP server as the internal database for the cloned Data Recovery Manager instance.

If you select the remote database, make sure that you have already created an LDAP server containing a base suffix of o=netscapeCertificateServer on the host whose host name and port number you specify in the fields in the lower portion of the Installation Wizard.
 

10. Configure replication between the cloned DRM database and the master DRM database.

Follow the instructions on screen to create the password for the Replication Manager role in the Master database, the password for the Replication Manager role in the Consumer database, and the agreement names between the master and clone's databases. See Configuring Key Archival and Recovery Process for more information.
 

11. In the following dialog, enter the key and request number ranges for the cloned Data Recovery Manager.

Be aware of the following as you designate the key number ranges and request numbers of the cloned Data Recovery Manager:
 

• DRM's key number range—On this screen, specify the lowest key number the DRM should assign for archives it creates in the "Starting key number" field. In the "Ending key number" field, specify the highest key number available for this DRM.
• DRM's request number range—On this screen, specify the lowest request number the DRM should accept for requests that it receives in the "Starting request number" field. In the "Ending request number" field, specify the highest request number acceptable to be received by this DRM.

12. Select the transport, storage, and SSL server certificates for the DRM clone in the following dialog in the wizard.

In order for these fields to be populated properly, you have to have already copied over the appropriate certificates from the master DRM. If you do not see certificates in the pull-down menus, follow the instructions in Steps 4 and 5 above to copy the key and certificate database material and configuration files over correctly.
 

13. Once the configuration for the cloned DRM instance is done, the cloned DRM instance will be available for data recovery. Follow the instructions in the next section to verify that the clone and the master Data Recovery Managers have been properly configured to work together.

Also, it should be understood that any configurations made to a master DRM will also need to be setup in each cloned DRM. The only two exceptions to this rule, are the Users and Groups, and the Access Control Lists, both of which are provided through the CMS console.
 

Testing the DRM Cloned-Master Connection

Follow these steps to test whether your cloned-master DRM setup is complete and functional.

1. Go to the DRM agent page.
2. Click List Requests.
3. Select "Show all requests" from the pull-down menu for Request type. Select "Show all requests" from the pull-down menu from Request status.
4. Click Submit.
5. Compare the results from the cloned DRM and the master DRM.

The results ought to be identical.
 

Cloned-Master DRM Responder Conversion

No configurable differences exist between a master DRM and a cloned DRM.

© 2001 Sun Microsystems, Inc. Portions copyright 1999, 2002-2004 Netscape Communications Corporation. All rights reserved.

Last Updated November 23, 2004