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



Chapter 4   Planning Your Deployment


Before installing iPlanet Certificate Management Server (CMS) in any real-life deployment, you first need to plan all aspects of the proposed installation. It's important to consider all potential issues carefully before installation. Omissions or faulty assumptions in the planning process can cause severe problems later.

This chapter provides an overview of the most important decisions you need to make. Many of these decisions are interdependent; for example, the question of whether a Certificate Manager is subordinate affects its distinguished name (DN) as well as its validity period, extensions, and place in the CA hierarchy.

As you begin to make decisions about your deployment strategy, you can use Chapter 5 "Installation Worksheet" to collect the detailed information you must supply during the installation and configuration of individual subsystems.

This chapter has the following sections:



Topology Decisions

Certificate Management System allows you to install the Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager in many different configurations.

Since CAs can delegate some responsibilities to subordinate CAs, a Certificate Manager might delegate responsibilities to one or more levels of subordinate Certificate Managers. Therefore many complex variations are possible. You should carefully consider the appropriate topology for your deployment before you make any other deployment plans.

The sections that follow describe the simplest arrangements:


Server Groups and CMS Instances

As described in Managing Servers with iPlanet Console, iPlanet servers installed in a single server root directory are called a server group and are managed by a single instance of iPlanet Administration Server. As shown in Figure 4-1, a CMS instance in a server group can contain a single subsystem of any kind, or either of the following combinations:

  • One Certificate Manager and one Data Recovery Manager

  • One Registration Manager and one Data Recovery Manager

Other combinations are not permitted.

A Certificate Manager and a Registration Manager or Online Certificate Status Manager are always permitted in separate instances, whether the instances are in the same server group, in separate server groups on the same machine, or in separate server groups on separate machines.


Single Certificate Manager

Some deployments may require only a single Certificate Manager that handles all end-entity interactions and provides no key archival and recovery capabilities. This Certificate Manager can use a signing certificate issued by a public certificate authority or its own self-signed CA signing certificate to sign all the certificates it issues.

Figure 4-1 shows the relationships among a single Certificate Manager, end entities, and a publishing directory. The Certificate Manager can publish both end-entity certificates and CRLs to a directory.

Figure 4-1    Single root Certificate Manager

The arrangement shown in Figure 4-1 is equivalent to the capabilities provided by Netscape Certificate Server 1.x—with the addition of new Certificate Management System features such as Digital Signature Algorithm (DSA) signing, support for PKCS #11, and support for a wider variety of end-entity protocols.


Certificate Manager and Registration Manager

Many organizations need to separate the role of the Registration Manager from the role of the Certificate Manager. This separation can be useful, for example, if different groups of end entities are subject to different authentication policies or work in different geographic locations.

Each group of end entities interacts with a designated Registration Manager that processes requests from end entities and sends them to a Certificate Manager. The Certificate Manager can accept requests from both end entities and Registration Managers. For example, end entities at the home office might deal directly with the Certificate Manager, while end entities at a branch office might deal with their own Registration Manager. Alternatively, the Certificate Manager might be configured to accept requests only from Registration Managers, thus shielding the CA from end entities.

As stated earlier, a single CMS instance cannot contain both a Certificate Manager and a Registration Manager. A Certificate Manager that needs to interact with end entities other than Registration Managers provides all Registration Manager capabilities itself.

A Registration Manager can be installed in one CMS instance and its related Certificate Manager in another CMS instance. The separate instances can be located in the same server group, in different server groups on the same machine, or on different machines.

Figure 4-2 shows a Registration Manager and its Certificate Manager in separate instances on separate machines. All communication between the Certificate Manager and the Registration Manager takes place over HTTPS.

Figure 4-2    Certificate Manager and Registration Manager in different instances


In many organizations, it may be desirable to deploy multiple Registration Managers that all communicate with a single Certificate Manager. Each separate Registration Manager, for example, might handle all end-entity interactions in a particular geographic area or within an organizational group.

Decisions about the number of, locations of, and relationships among Certificate Managers and Registration Managers depend on many factors. These include firewall considerations, the physical security required for each subsystem, the physical location of the end entities that the Registration Manager is intended to serve, and the physical location of the Certificate Manager agent, Registration Manager agent, and other persons responsible for administering the Certificate Manager and Registration Manager.


Certificate Manager and Data Recovery Manager

If an organization requires key archival and recovery capabilities—for example, if encrypted mail is widely used and the organization risks data loss if it is unable to recover encryption keys—it can install a Data Recovery Manager. This can be done without regard for the presence or absence of a separate Registration Manager.

For example, to add key storage and recovery to the scenario sketched in Figure 4-2, a Data Recovery Manager can be installed either in the same CMS instance in which the Certificate Manager is installed or in a different CMS instance (which can be located in the same server group on the same machine, in a different server group on the same machine, or on a different machine.)

Figure 4-3 shows a Data Recovery Manager in a separate CMS instance. In this case all communication between the Certificate Manager and the Data Recovery Manager takes place over HTTPS. If the Data Recovery Manager and the Certificate Manager are part of the same CMS instance, all communication takes place internally and the two subsystems do not require separate host names or additional configurations.

Figure 4-3    Certificate Manager and Data Recovery Manager in different instances


The Data Recovery Manager is intended for archival and recovery of private encryption keys only. Therefore end entities must be using either a browser that supports dual-key generation or a browser that is using Netscape Personal Security Manager, which supports dual keys.

The decision to keep the Data Recovery Manager in the same instance as the Certificate Manager or in a different instance (most likely on a different machine) depends on many factors. These include firewall considerations, the physical security required for each subsystem, and the physical location of the Certificate Manager agent, Data Recovery Manager agent, and other persons responsible for administering the Certificate Manager and recovering keys.

Like a Certificate Manager, a Data Recovery Manager has special physical security requirements, since a compromised Data Recovery Manager would have devastating security consequences for your entire PKI. You may therefore want to keep the Data Recovery Manager in a special locked room or building, a choice that can affect your deployment strategy.


Certificate Manager, Data Recovery Manager, and Registration Manager

The three CMS subsystems can be deployed in many different relationships. Figure 4-4 illustrates some of the issues involved in deploying all three subsystems by showing the relationships among a single Certificate Manager, a single Registration Manager, and a single Data Recovery Manager, each installed in a different CMS instance on a different machine.

The Registration Manager handles all end-entity interactions and communicates with the Certificate Manager and the Data Recovery Manager over HTTPS. The Registration Manager is configured to request the end entity's private encryption key (in encrypted form) and send it to the Data Recovery Manager during the enrollment process. Before the Registration Manager sends the certificate request to the Certificate Manager for processing, the Registration Manager must receive verification from the Data Recovery Manager that the private key has been received and stored and that it corresponds to the end entity's public key.

Only the Certificate Manager can be configured to enable or disable LDAP publishing or to publish to separate directories. The Certificate Manager also has the complete record of issued certificates, so that it can perform the publishing tasks, as shown in the figure.

Many other combinations are possible. For example, the Data Recovery Manager and the Certificate Manager might be in the same instance; there might be multiple Registration Managers in different instances, all dealing with the same Data Recovery Manager and Certificate Manager; or the Certificate Manager might also handle some end-entity interactions. It's also possible to set up both Certificate Managers and Registration Managers such that each has a hierarchy of subordinate managers.

Figure 4-4    Certificate Manager, Registration Manager, and Data Recovery Manager in separate instances


Note The current design of Certificate Management System assumes that most deployments will rely on a single Data Recovery Manager (associated with either a Registration Manager or a Certificate Manager). However, it is also possible to write custom policies that support multiple Data Recovery Managers. This might be useful, for example, for subordinate CAs that issue certificates for completely independent organizations.


You can choose to install either a Certificate Manager and Data Recovery Manager or a Registration Manager and Data Recovery Manager in a single instance. There is not need to install a Certificate Manager and Registration Manager in the same instance; instead, a single Certificate Manager can be configured to perform all Registration Manager functions.

When subsystems are installed in the same instance, the connections between them are internal. Both subsystems must share the same host name, and the overall number of SSL server certificates can be reduced (see Subsystem Certificate Decisions).


Cloned Certificate Manager

A cloned Certificate Manager is a CMS server instance that uses the same CA signing key and certificate as another Certificate Manager, identified as the master Certificate Manager. Each Certificate Manager issues certificates with serial numbers in a restricted range so that all of the servers together act as a single Certificate Authority (operating in several server processes).

Cloning requires somewhat more management and administrative effort and it creates more potential areas where the CA could become compromised, so it should only be used when absolutely necessary.

The advantage of cloning is the ability to distribute the Certificate Manager's load across several processes or even several physical machines. For a CA that has high enrollment demand, the distribution gained from cloning allows more certificates to be signed and issued in a given time interval.

To create a cloned Certificate Manager, you must first install and configure at least one Certificate Manager and specify a definite upper, but no lower bound for the serial numbers it will use. You then install or create a new instance of a Certificate Manager (but do not configure it). Before configuring the clone, you copy the certificate and key database files from the original Certificate Manager to the new Certificate Manager's configuration (<server_root>cert-<instance_id>/config) directory. If these databases are present, the Configuration Wizard will recognize that you are creating a clone and confirm that you want to reuse the CA's signing key and certificate (if the clone is on the same server, you can also reuse the SSL server certificate).

If you store the CA key material on a hardware token, you will have to follow the hardware vendor's instructions for copying the key material to a hardware device accessible to the clone.

A cloned Certificate Manager will have all the same features, agent gateway functions, and end entity gateway functions that a normal Certificate Manager has. You can then configure Registration Managers that point to different Certificate Manager servers but that appear to be serviced by the same CA.



Certificate Authority Decisions


This section covers some of the critical decisions you need to make about your certificate authority:


CA's Distinguished Name

The core elements of a CA consist of a signing unit and the Certificate Manager's own identity. The signing unit digitally signs certificates requested by end entities that use a specified enrollment process to establish their identities. Regardless of how related Registration Managers or Data Recovery Managers are configured, any Certificate Manager must have its own distinguished name (DN), which is listed in every certificate it issues.

Like any other X.509 version 3 certificate, a CA certificate binds a DN to a public key. A DN is a series of name-value pairs that in combination uniquely identify an entity. For example, the following DN might be used to identify a hypothetical Certificate Manager for the Engineering department of a corporation named Siroe Corp: cn=demoCA, o=Siroe Corp., ou=Engineering, c=US

Many combinations of name-value pairs are possible for the Certificate Manager's DN. The DN must be unique and readily identifiable, since any end entity can examine it. For more information about DNs, see Managing Servers with iPlanet Console.


CA Signing Key Type and Length

If you wish, you can import the signing key and certificate used in a previous version of CMS installation rather than generating a new signing key pair.

If you decide to generate a new signing key, one of the first decisions you need to make is whether to use the RSA or DSA algorithm. If you use DSA, the software can generate and verify the PQG value. PQG values are used to create the DSA signing key pair. For more information about the way they are used, check this document: http://www.itl.nist.gov/div897/pubs/fip186.htm.

In general, longer keys are considered to be cryptographically stronger than shorter keys. However, longer keys also require more time for signing operations. (Certificate Manager CA signing keys up to 4096 bits in length are not subject to export restrictions.)

Many people no longer consider an RSA key length of 512 bits to be cryptographically strong. Export and other regulations permitting, it may be a good rule of thumb to start with 1024 bits and consider increasing the length to 2048 bits for certificates that provide access to highly sensitive data or services. However, the question of key length has no simple answers. Every organization must make its own decision based on its own security requirements. For more information on key length and encryption strength, see Appendix D of Managing Servers with iPlanet Console.


CA Signing Certificate's Validity Period

Every certificate, including a Certificate Manager signing certificate, must have a validity period. Certificate Management System does not restrict the validity period you can specify. In general it's a good idea to specify as long a validity period as possible, depending on your plans for certificate renewal, the place of the CA in the certificate hierarchy, and the requirements of any public CAs that you may want to include in your PKI.


Self-Signed Root Versus Subordinate CA

For the purposes of an initial pilot, it is easiest to make the CA a self-signed root, so that you won't need to apply to a third party and wait for the certificate to be issued. Before deploying a full-blown PKI, however, you will need to consider this question carefully.

If you want your CA to chain up to a third-party public CA, you must carefully consider the restrictions that public CAs place on the kinds of certificates your CA can issue and the nature of the certificate chain. For example, a CA that chains up to a third-party CA might be restricted to issuing only Secure Multipurpose Internet Mail Extensions (S/MIME) and SSL client authentication certificates—not SSL server certificates. In addition, a CA that chains up to a third-party CA might not be allowed to have any subordinate CAs and might have to obey certain restrictions on its use of certificate extensions. These and other restrictions may be acceptable for some PKI deployments but not for others.

One benefit of chaining up to a public CA is that the third party is responsible for getting the root CA certificate into the browser or other end-entity software. This can be a major advantage if you are deploying an extranet that involves certificates used by different companies whose browsers you cannot control. Alternatively, if you create your own CA hierarchy from scratch, you are responsible for getting your root certificate into all the browsers used with the certificates you issue. If you are using Netscape Communicator as your client, you can accomplish this task within an intranet by using tools such as Mission Control Desktop or with the aid of Personal Security Manager, but extranet deployments can be more complicated.


CAs and Certificate Extensions

An X.509 v3 certificate contains an extensions field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names, policy information, and usage restrictions to certificates. The X.509 v3 standard defines a number of extensions for various purposes. Certificate Management System provides policy modules that you can use to set many of the standard extensions in the certificates the server issues.

Before the X.509 v3 standard was finalized, Netscape and other companies had to address certain issues, such as usage restrictions, with their own extension definitions. Therefore, to maintain compatibility with older versions of browsers that were released before the X.509 v3 specification was finalized, certain kinds of certificates should include some of the Netscape extensions. Certificate Management System provides policy modules that you can use to implement essential Netscape extensions.

The Internet Engineering Task Force (IETF), which controls many of the standards that underlie the Internet, is currently developing public-key infrastructure X.509 (PKIX) standards. These proposed standards further refine the X.509 v3 approach to extensions for use on the Internet. PKIX working group recommendations should also be taken into account when planning extensions for CA certificates, subordinate CA certificates, and end-entity certificates.

For more detailed information about extensions and recommendations for specific types of certificates, see Appendix C, "Certificate and CRL Extensions" of CMS Plug-Ins Guide.


CA Certificate Renewal or Reissuance

When a CA signing certificate expires, all certificates signed with the CA's corresponding signing key become invalid. End entities use information in the CA certificate to verify the certificate's authenticity. If the CA certificate itself has expired, applications cannot chain the certificate to a trusted CA.

There are two ways of dealing with CA certificate expiration:

  • Renewing a CA certificate involves issuing a new CA certificate with the same subject name and public and private key material as the old CA certificate, but with an extended validity period. As long as the new CA certificate is distributed to all users well before the old CA certificate expires, this approach allows certificates issued under the old CA certificate to continue working for the full duration of their validity periods. However, because of potential conflicts between the old CA certificate and the new CA certificate, this approach requires special care with early versions of Communicator 4.x.

  • Reissuing a CA certificate involves issuing a new CA certificate with a new name, public and private key material, and validity period. This approach avoids some of the problems associated with renewing a CA certificate, but it requires more work for both administrators and users to implement. All certificates issued by the old CA, including those that have not yet expired, must be renewed by the new CA.

There are advantages and disadvantages to each approach. Correct use of extensions, for example the authorityKeyIdentifier extension, can also affect the transition from an old CA certificate to a new one. You should begin planning for CA renewal or reissuance before you install any CMS managers; consider any ramifications your planned procedures may have for extensions, policies, and other aspects of your initial PKI deployment.

For a discussion of CA certificate expiration issues in the context of Certificate Server 1.x, see http://help.netscape.com/products/server/certificate/cacertdoc/. Many of the same issues apply to Certificate Management System.  

For detailed information on certificate extensions, see Appendix C, "Certificate and CRL Extensions" of CMS Plug-Ins Guide.



Cryptographic Token Decisions


As explained in PKCS #11, one or more PKCS #11 modules must be available to any CMS instance. A PKCS #11 module, which can be implemented in either software or hardware, manages cryptographic services such as encryption and decryption. Netscape provides a built-in PKCS #11 module with Certificate Management System; see Installing Level 2 External Tokens.

A PKCS #11 module always has one or more slots, which can be implemented as physical hardware slots in some form of physical reader (for example, for smart cards) or as conceptual slots in software. Each slot for a PKCS #11 module can in turn contain a token, which is the hardware or software device that actually provides cryptographic services and optionally stores certificates and keys.

As shown in Figure 1-10 on, the built-in PKCS #11 module for Certificate Management System includes two tokens, one for cryptographic operations and one for manipulating the key and certificate databases. You can accelerate cryptographic operations such as the signing of new certificates by using third-party hardware tokens and accelerator boards. Certificate Management System support for PKCS #11 also allows you to store critical keys, such as the root CA signing key, on smart cards or other hardware tokens to facilitate strong physical security measures.

Hardware products compatible with Certificate Management System are available from nCipherTM (http://www.ncipher.com) and Chrysalis-ITSTM (http://www.chrysalis-its.com).

If you decide to test or deploy hardware acceleration and storage devices, consult the vendor's installation instructions.



Publishing Decisions


A Certificate Manager can publish certificates to an LDAP directory and to files, and CRLs to an LDAP directory, files, and the Online Certificate Status Manager.


Publishing to Certificates and CRLs to Files

Any Certificate Manager that publishes certificates or CRLs to files need to specify the location for storing these files. There will be a file for each certificate and CRL, so the specified location must have sufficient disk space for storing these files. For detailed information on publishing certificates and CRLs to files, see Chapter 20 "Publishing Certificates and CRLs to a File."


Publishing to Certificates and CRLs to a Directory

Any Certificate Manager that publishes certificates or CRLs to a directory must specify the host name and port number for the directory and indicate whether communication should take place over SSL. The Certificate Manager must also specify how it should identify itself to the directory—by using password-based authentication or SSL client authentication. Finally, the directory itself must be configured (typically by the directory administrator) to authenticate the Certificate Manager in the specified manner.

Note that it's not possible to configure the Registration Manager to publish certificates or CRLs. The Certificate Manager has the complete record of issued certificates and that the publishing tasks be performed by the Certificate Manager only. If it's necessary for some entries in a directory to be available outside the firewall, iPlanet recommends using the partial replication feature of Directory Server to replicate the relevant portion of the directory to which the Certificate Manager publishes.

This guide assumes that you have already deployed an LDAP-compliant directory server (LDAP 2.0 or higher) for your enterprise; it does not cover directory planning and configuration. For information on Directory Server deployment, see the documentation that comes with that product.

Configuration of the publishing or corporate directory should take place before you install any Certificate Management System subsystems. Configuration details that the directory administrator may need to take care of include the following:

  • If the authentication mechanism uses a DN (identifying the directory subtree in which the subsystem can publish certificates) and password, the directory administrator needs to set up a corresponding access control list (ACL).

  • If authentication is based on SSL client authentication, the directory administrator needs to create an entry in the directory's certmap.conf file. The certmap.conf entry maps the DN in the subsystem's client certificate to a directory entry that specifies write permission to the appropriate portion of the directory tree.

  • If you intend to publish certificates to the directory, the directory administrator needs to have an entry for each user to whom you intend to issue a certificate, and the directory schema must include a location to which the certificate should be published. If you want to publish the CA certificate or CRL, you will also need an entry for the CA.

If you intend to use SSL authentication, both the directory and the Certificate Manager must be configured appropriately for SSL. For detailed information on LDAP publishing, see Chapter 19 "Setting Up LDAP Publishing."


Publishing CRLs to the Online Certificate Status Manager

Certificate Management System supports the Online Certificate Status Protocol (OCSP) as defined in the PKIX standard RFC 2560 (see http://www.ietf.org/rfc/rfc2560.txt). The OCSP protocol enables OCSP-compliant applications to determine the state of a certificate, including the revocation status, without having to directly check a CRL published by a CA to the validation authority. The validation authority, which is also called an OCSP responder, does the checking for the application. For more information, see What's an OCSP-Compliant PKI Setup?.

To aid you in the process of setting up a OCSP-compliant PKI setup, Certificate Management System provides two options:

  • Use the OCSP-service feature built into the Certificate Manager

  • Use the CMS OCSP responder, named Online Certificate Status Manager

Read section How to Get an OCSP Responder? to decide which method is suitable for your PKI setup.



Subsystem Certificate Decisions


Using a self-signed signing certificate for the Certificate Manager simplifies the deployment of an initial pilot. You can install the Certificate Manager without having to apply to a public certificate authority and waiting for it to issue, sign, and return your CA signing certificate. Your own Certificate Manager can then issue all the other certificates required for your pilot. However, taking this approach means that end entities outside your organization will not recognize your Certificate Manager unless you distribute the root Certificate Manager certificate to them.

The certificates and keys you need for each subsystem depend in part on whether the subsystems are in the same or different CMS instances. Subsystems installed together in the same instance use internal connectors to communicate and therefore don't need separate SSL certificates to authenticate each other.

When two CMS subsystems are installed in a single instance, they normally share a single SSL server certificate. If one or more subsystems are installed in a separate instance from the other subsystems, each instance requires a separate SSL server certificate.

In addition to any SSL server certificates, the Certificate Manager, Registration Manager, and Online Certificate Status Manager each requires its own signing certificate, and the Data Recovery Manager needs its own transport certificate and storage key.

For more information about the key pairs and certificates used by the CMS managers, see Keys and Certificates for the Main Subsystems.


SSL Server Certificates

Each CMS instance requires a single SSL server certificate. If you install two managers in the same instance—that is, a Certificate Manager or Registration Manager and a Data Recovery Manager—both managers share the same SSL server certificate.


Certificate Manager Certificates

Every Certificate Manager must have a CA signing certificate whose public key corresponds to the private key the Certificate Manager uses to sign the certificates it issues. This certificate is also used for SSL client authentication to the publishing directory (LDAP over SSL) if the Certificate Manager is set up to publish certificates or CRLs.

If the Certificate Manager is acting as a root CA, the CA certificate must be installed and trusted by each client that needs to validate certificates issued by the root Certificate Manager. In the context of a PKI, trust refers to the relationship between the user of a certificate and the CA that issued the certificate. If you trust a CA, you can generally trust valid certificates issued by that CA. It's possible to control which CAs the client or server software trusts and which it doesn't, and for what kinds of certificates, by means of settings within the software.

The Certificate Manager also requires an SSL server certificate. The Certificate Manager's SSL server certificate (or certificates) can be unique to the Certificate Manager or, if a Data Recovery Manager is installed in the same instance, shared with it.

In addition to these certificates, the Certificate Manager also generates a few other certificates transparently during installation. For details, see Certificate Manager's Key Pairs and Certificates.


Registration Manager Certificates

Every Registration Manager subsystem must have a signing certificate whose public key corresponds to the private key the Registration Manager uses to sign end-entity certificate requests before sending them to the Certificate Manager. Signed requests give the Certificate Manager persistent proof that a particular Registration Manager processed the request. If the Registration Manager is set up to publish certificates or CRLs, its signing certificate is also used for SSL client authentication to the publishing directory (LDAP over SSL).

The Registration Manager also requires at least one SSL server certificate. The Registration Manager's SSL server certificate (or certificates) can be unique to the Registration Manager or, if a Data Recovery Manager is installed in the same instance, shared with it.

For more information about the key pairs and certificates used by a Registration Manager, see Registration Manager's Key Pairs and Certificates.


Data Recovery Manager Certificate and Storage Key

The Data Recovery Manager needs a transport certificate and a storage key:

  • The Data Recovery Manager transport certificate has a public key used by end-entity software to encrypt the private encryption key belonging to an end entity so that it can be sent (via the Registration Manager) to the Data Recovery Manager. The public key also corresponds to the private key used by the Data Recovery Manager to sign the proof-of-archival token it sends to the Registration Manager after storing an end entity's encryption key.

  • The Data Recovery Manager storage key is used by the Data Recovery Manager to encrypt the end entity's encryption key (after it has been decrypted with the Data Recovery Manager's private transport key) before the Data Recovery Manager stores the encryption key in the local directory. Data encrypted with the storage key can be retrieved only if m of n "split keys" are provided at the same time by m of n authorized agents.

The Data Recovery Manager also requires at least one SSL server certificate. The Data Recovery Manager's SSL server certificate (or certificates) can be unique to the Data Recovery Manager or, if another subsystem are located in the same instance, shared with that subsystem.


Note If you want to use hardware tokens for generating and storing Data Recovery Manager's key pairs, you'll need at least two tokens: one exclusively for the storage key pair and the other for the remaining key pairs. Be sure to install (and initialize, if required) these tokens before you start the Data Recovery Manager installation.


For more information about the key pairs and certificates used by a Data Recovery Manager, see Data Recovery Manager's Key Pairs and Certificates.


Online Certificate Status Manager Certificates

Every Online Certificate Status Manager must have a signing certificate whose public key corresponds to the private key the Online Certificate Status Manager uses to sign OCSP responses before sending them to OCSP-compliant clients. The Online Certificate Status Manager's signature provides persistent proof to an OCSP-compliant client that the Online Certificate Status Manager has processed the request.

The Online Certificate Status Manager also requires at least one SSL server certificate. For more information about the key pairs and certificates used by a Online Certificate Status Manager, see Online Certificate Status Manager's Key Pairs and Certificates.



Authentication Decisions


CMS managers use authentication modules to verify the identity of a user requesting a service, such as certificate enrollment. For example, a user can be prompted to provide a name and password, and the authentication module can check a directory entry to confirm that they are correct.

Authentication is one of the essential functions of Certificate Management System. The main purpose of a certificate is to provide a trustworthy association between the public key of the subject and the subject's name and other attributes. Therefore the manner in which administrators, agents, and end entities are authenticated, especially for operations related to certificate enrollment, requires careful planning and control throughout the lifetime of a PKI deployment.

For examples of some different approaches to authentication during certificate enrollment, see Chapter 2 "Certificate Enrollment and Life-Cycle Management."

For a detailed overview of authentication management using Certificate Management System, see Chapter 15 "Setting Up End-User Authentication."



Policy Decisions


CMS managers use policies to evaluate or verify incoming certificate enrollment or management requests from end entities and to determine the outcome. For example, in the case of certificate enrollment request, the outcome is the issued certificate.

Decisions regarding policies depend on both the subsystem involved and your overall topology. Whether your CA signing certificate is self-signed or not, it represents part of a certificate hierarchy. For example, a CA may be a root CA for subordinate CAs that issue certificates to different parts of a large organization, or it may be one of the subordinate CAs that chain up to an internal root CA, or it may be a linked CA that chains up to a third party.

Policies configured for a Certificate Manager apply to all certificates issued by that Certificate Manager or its subordinates. Policies configured for a Registration Manager subsystem are local to the Registration Manager. This distinction can be used to model the levels of authority within an organization. Enrollment can be fully automated by means of custom policy and authentication subsystems at the Registration Manager level.

Thus, a policy for a Certificate Manager might be that all subject names have to end with o=Siroe Corp. Registration Managers for individual departments can enforce this policy and can also define their own, local naming policies, such as ou=Engineering.

Another variation is to have the Certificate Manager enforce the companywide policies and have subordinate Certificate Managers, instead of Registration Managers, enforce the names for individual departments. Each subordinate Certificate Manager, in turn, can delegate enrollment responsibilities to multiple Registration Managers, which can be configured to apply the policies uniformly in different geographic locations.

For a detailed discussion of policy management, see Chapter 18 "Setting Up Policies."



Deployment Strategy and Port Assignments


Before you install any CMS instance, you should review the decisions described in this chapter and work out the relationships between the Certificate Managers, Data Recovery Managers, Registration Managers, and Online Certificate Status Managers you want to deploy for your organization. Once you have decided which subsystems to install and where, fill out a copy of the worksheet provided in Chapter 5 "Installation Worksheet" for each separate installation.  

You can create multiple instances of Certificate Management System in a single server root directory, each containing either one or two CMS managers. If you want to install CMS managers on different hosts, you must run the entire installation on each host, specifying the services for each instance of Certificate Management System. You can also perform additional complete installations on the same host in a different server root directory.

Figure 4-5 shows an example of how several CMS instances can be installed on a single host machine. (Note that on Windows NT, you can install a single server root only; multiple server roots are not permitted.)

Figure 4-5    Deploying servers on a single host

Each server root directory shown in Figure 4-5 has its own Administration Server and iPlanet Console and access to a configuration directory. Each CMS instance has a corresponding instance of Directory Server that functions as the internal database for that CMS instance. Each server root directory can have one or more instances of Certificate Management System, each with its own set of one or two subsystems and its own corresponding internal database.

Figure 3-1 in Chapter 2 illustrates the ports used by a single CMS instance. You can also install multiple instances on a single machine, either in the same server root or as completely separate installations in separate server roots.

When you install additional CMS instances on a machine with a single IP address, you are required to specify a different set of ports for each CMS instance to listen on. That is, each CMS instance will require at least four unique ports:

  • Internal database port for communication with internal database

  • SSL administration port for communication with iPlanet Console

  • SSL agent port for communication with designated agents

  • At least one of these ports:

    • SSL user port for communication with end entities

    • Non-SSL user port for communication with end entities

The ports shown above are required for each CMS instance. Each server root needs two additional unique ports: one for the Directory Server being used as the configuration directory and one for the Administration Server.

When you install additional CMS instances on a machine that has been set up with more than one IP address, you can configure each instance to listen to a specific IP address. If each instance has a different IP address, you can use the same port numbers for additional CMS instances installed on the same machine—that is, you can use one set of four or five ports for all the instances.

For more information about installing multiple CMS instances, see Chapter 7 "Installing and Uninstalling CMS Instances."


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

Last Updated October 07, 2002