Chapter 12   Setting Up Internal Database


Subsystems installed in an instance of iPlanet Certificate Management System (CMS) share certain configuration information. For example, they use the same administration, agent, and end-entity ports; internal database for data storage; mail server for automated notifications; internal token and trust database for PKI operations; SSL ciphers during SSL negotiation; privileged users; and log files to log messages to. This chapter explains how to configure the internal database for a CMS instance.

The chapter has the following sections:

• Internal Database

• Configuring the Internal Database

Internal Database

---

Certificate Management System performs various certificate and key-management functions in response to the requests it receives. These functions include the following:

• Storing and retrieving of certificate issuance requests

• Storing and retrieving of certificate records

• Storing of CRLs

• Storing and retrieving of end users' encryption private key records

To fulfill these functions, Certificate Management System maintains a persistent store—a preconfigured Netscape Directory Server—referred to as the internal database or local database. The internal database is installed automatically as a part of the CMS installation. It is used as an embedded database exclusively by Certificate Management System and can be managed using Directory management tools that come with Netscape Directory Server.

The Directory Server instance used for the internal database is different from the LDAP-compliant directory that you use to manage your corporatewide data (users and groups, their certificates, CRLs, and so on).

• In Netscape Console, you can distinguish an internal database instance from other Directory Server instances. It is in this form:

  <cms_instance_id>-db

  <cms_instance_id> is the ID of the CMS instance that is using the database. You first specified this when you installed this server.

• If you check the files installed under <server_root>, the internal database instance appears like this: slapd-<cms_instance_id>-db

Keep in mind that the subsystems use the database for storing different objects. A Certificate Manager stores all the data, certificate issuance requests, certificates, CRLs, and related information; a Registration Manager only stores the certificate issuance requests it receives; and a Data Recovery Manager only stores key records and related data.

Configuring the Internal Database

---

Each instance of Certificate Management System uses a Netscape Directory Server instance as its internal database. All the subsystems that were installed in a CMS instance use the same Directory Server instance to store their data. For example, if you installed a Certificate Manager and Data Recovery Manager together, they use the same internal database for data storage.

---

Caution

The internal database schema is preconfigured for storing CMS data only. Do not make any changes to it or configure Certificate Management System to use any other LDAP directory. Doing so can result in loss of data. Also, do not attempt to use this database for any other purpose.

---

Step 1. Identify the Directory Server Instance

To identify the Directory Server instance that a CMS instance should use as its internal database:

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

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

3. Identify a Directory Server instance by providing the following details:

   Host name. Type the full host name of the machine on which Netscape Directory Server is installed. Certificate Management System uses this name to access the directory. The format for the host name is as follows:

   <machine_name>.<your_domain>.<domain>

   By default, the host name of the Directory Server instance being used as the internal database is shown as localhost instead of the actual host name (for example, certificates.netscape.com). This is done on purpose to insulate the internal database from being visible outside the system—that is, a server on localhost can only be accessed from the local machine. Thus, the default configuration minimizes the risk of someone connecting to this Directory Server instance from outside the local machine.

   You can configure the host name to something other than localhost if you know what you are doing and you think you can limit the visibility of the internal database to a local subnet. For example, if you installed Certificate Management System and Directory Server on separate machines for load balancing, you will have to specify the host name of the machine in which Directory Server is installed.

   Port number. Type a TCP/IP port number; Certificate Management System uses this port for non-SSL communications with the Directory Server instance that is functioning as the internal database. Make sure that the port you specify is unique on the host system.

   Directory manager DN. Type the distinguished name (DN) of an entry in your LDAP directory that has read and write permission to the entire directory tree. Certificate Management System will use this DN when it accesses the directory tree to communicate with the directory. Keep in mind that the access control set up for this DN determines whether Certificate Management System can communicate with the directory. Typically, you would want to enter the directory manager's DN (the root DN) because this DN will have read/write permission to the entire directory tree.

4. To save your changes, click Save.

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

Step 2. Restrict Access to the Internal Database

This step is optional.

Netscape Console displays an entry or icon for the Directory Server instance that Certificate Management System uses as its internal database. You can distinguish an internal database instance from other Directory Server instances. It is in this form: slapd-<cms_instance_id>-db

Unlike the CMS window, access to which is restricted to users with CMS administrator privileges, the Directory Server window can be accessed by the person who has privileges to access Netscape Console. That is, this person can open the Directory Server window for the internal database and make changes to the data stored there. For example, this person can make changes to the CMS administrators group, such as deleting existing users and adding entries for self.

If you are concerned about this, you can restrict access to the internal database to only those users who know its Directory Manager DN and corresponding password. You can change this password by modifying the single sign-on password cache. For instructions, check the section that explains how to change the password of an entry in the password cache in Chapter 2, "Password Cache Utility" of CMS Command-Line Tools Guide.

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

2. In the Console tab, select the server group that contains the CMS instance you want.

3. Select the entry that corresponds to the internal database to which you want to restrict access, and click Open.

   The Directory Server window appears.

4. Select the Configuration tab.

5. In the navigation tree, expand Plugins, and then select Pass Through Authentication.

6. In the right pane, uncheck or disable the "Enable plugin" option.
   
   

7. Click Save to save your changes.

   You are prompted to restart the server.

8. Click the Tasks tab and click "Restart the Directory Server."

9. Close the Directory Server window.

10. When the server is restarted, from Netscape Console, open the Directory Server window.

    The "Login to Directory" dialog box appears; the Distinguished Name field displays the Directory Manager DN and you're required to enter the password that corresponds to this entry.
    
    

    The Directory Server window (for the internal database) opens only if you enter the correct password.