|
Chapter 3
Planning Your Deployment
Before installing Netscape Certificate Management System 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 4, "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, and Data Recovery 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 Netscape Console, Netscape servers installed in a single server root directory are called a server group and are managed by a single instance of Netscape Administration Server. A single CMS instance in a server group can contain a single subsystem instance of any kind, or either of the following combinations:
The only combination that is not permitted in a single CMS instance is a Certificate Manager with a Registration Manager. A Certificate Manager in a single instance can be configured to provide Registration Manager capabilities as well; a separate subsystem isn't needed.
A Certificate Manager and a Registration 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 3.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 3.1 Single root Certificate Manager 
The arrangement shown in Figure 3.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.
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 3.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 3.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 3.1, 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 3.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.
Figure 3.3 Certificate Manager and Data Recovery Manager in different instances 
The Data Recovery Manager is intended for use with private encryption keys only. Therefore end entities must be using either a browser that supports dual keys or a browser that is using 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 subsystem, 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 3.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.
Both the Registration Manager and the Certificate Manager can be configured to enable or disable LDAP publishing or to publish to separate directories. However, the Certificate Manager has the complete record of issued certificates, so it is recommended that publishing tasks be performed by the Certificate Manager only, 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 3.4 Certificate Manager, Registration Manager, and Data Recovery Manager in separate
instances 
Note
The current design of Netscape 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. 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 and 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 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 MyCorp:
cn=MyCA, o=MyCorp., 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 Netscape Console.
CA Signing Key Type and Length
If you wish, you can import the signing key and certificate used in a Certificate Server 1.x installation rather than generating a new signing key pair. For information on how to do this, see Appendix A, "Migrating from Certificate Server 1.x."
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, see 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 Netscape 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. 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 implement many of the standard extensions.
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 B, "Certificate Extensions."
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:
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 B, "Certificate Extensions."
|
| Cryptographic Token Decisions |
As explained in "PKCS #11" in Chapter 1, one or more PKCS #11 modules must be available to any CMS subsystem 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.
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.12, 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. CMS 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 nCipher (http://www.ncipher.com) and Chrysalis-ITS (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 |
Any Certificate Manager or Registration Manager that publishes certificates to a directory must specify the host name and port for the directory and indicate whether communication should take place over SSL. It must also specify how the subsystem 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 subsystem in the specified manner.
Although it's possible to configure the Registration Manager to publish certificates, the Certificate Manager has the complete record of issued certificates, so it is recommended that 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, Netscape 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 Netscape 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:
Certificate Managers can also publish CRLs to the directory; this also requires an entry for the CA.
If you intend to use SSL authentication, both the directory and the Certificate Manager or Registration Manager must be configured appropriately for SSL.
For detailed information on LDAP publishing, see Part 7, "LDAP Publishing," in Netscape Certificate Management System Administrator's Guide.
|
| 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 and the Registration Manager each requires its own signing certificate, and the Data Recovery Manager needs its own transport certificate and storage key.
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.
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.
Data Recovery Manager Certificate and Storage Key
The Data Recovery Manager needs a transport certificate and a storage key:
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.
|
| Authentication Decisions |
The role of authentication modules in certificate enrollment is discussed in Authentication and Policy Modules. 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 Some Enrollment Scenarios.
For a detailed overview of authentication management using Certificate Management System, see Chapter 9, "Introduction to Authentication," in Netscape Certificate Management System Administrator's Guide.
|
| Policy Decisions |
The role of policies in certificate enrollment is discussed in Authentication and Policy Modules. 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=Netscape. 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 16, "Introduction to Policy," in Netscape Certificate Management System Administrator's Guide.
|
| 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, and Registration 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 4, "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 3.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 3.5 Deploying servers on a single host 
Each server root directory shown in Figure 3.5 has its own Administration Server and Netscape 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 2.1 in Chapter 2 illustrates the ports used by a single Certificate Management System 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 at least four unique ports:
The ports shown above are required for each CMS instance. Each server root needs two additional unique ports: one for 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 4, Installing and Uninstalling CMS Instances," in Netscape Certificate Management System Administrator's Guide.
|
|
|
|
|
Previous
