2.1. Deployment Considerations
Before beginning installation, the following issues must be decided:
What types of subsystems to install.
How many subsystems to install.
On which hosts to install the subsystems.
How and where to install an available Red Hat Directory Server. Only one Directory Server is required, although there can be more than one. It is recommended that the Directory Server only be used for certificate management.
To what security domain the subsystem should be added or, for CAs, whether to create a new security domain.
Whether the subsystem should be a clone of an existing subsystem.
Whether the Certificate Manager should be a self-signed root CA or a subordinate CA.
A security domain is a registry of PKI services. Certificate System subsystems register information about themselves in these domains so users of PKI services can find other services by inspecting the registry. The security domain service in Certificate System manages both the registration of PKI services for Certificate System subsystems and a set of shared trust policies. Security domains streamline information between subsystems. Each Certificate System subsystem instance must be a member of a security domain; a CA subsystem is the only subsystem which can host a security domain.
The security domain shares the CA internal database for privileged user and group information to determine which users can update the security domain, register new PKI services, and issue certificates. There must be at least one security domain for a PKI, but there can also be multiple domains.
More than one subsystem can be configured in an installation of Certificate System. There can be multiple instances of a type of subsystem on a host or across different hosts. For failover support, one configuration option is to duplicate, or clone, an instance so that more than one instance has the same configuration information. Clones and masters share the same set of keys and certificates. Cloned CAs issue certificates with the same issuer name and keys, but use different sets of serial numbers. A master and clone function essentially as a single server with failover support. This can also be used for load balancing for high-traffic subsystems. For details about cloning a subsystem, see Chapter 20, Configuring the Certificate System for High Availability.
A Certificate Manager can be configured either a root CA or a subordinate CA. A self-signing root CA issues and signs its own CA signing certificate. A subordinate CA can be subordinate to a public CA or to a Certificate System root CA; either way, the other CA signs the subordinate CA's certificates. A subordinate CA is restricted in the types and contents of the certificates it can issue by the contents and settings of the CA signing certificate issued to it, such as the kinds of certificates that it can issue, the extensions that it is allowed to include in certificates, the levels of subordinate CAs the subordinate CA can create, the validity period of certificates it can issue, and the validity period of the subordinate CA's signing certificate.
Subordination to a Public CA . Chaining the Certificate System CA to a third-party public CA introduces the restrictions that public CAs place on the kinds of certificates the subordinate CA can issue and the nature of the certificate chain. This may not be acceptable for some PKI deployments. One benefit of chaining to a public CA is that the third party is responsible for submitting the root CA certificate to a web browser or other client software, which is a major advantage for certificates that are accessed by different companies with browsers that cannot be controlled by the administrator.
Subordination to a Certificate System CA . Setting up a Certificate System CA as the root CA means that the Certificate System administrator has control over all subordinate CAs by setting policies that control the contents of the CA signing certificates issued. A subordinate CA issues certificates by evaluating its own authentication and certificate profile configuration, without regard for the root CA's configuration.
It is easiest to make the first CA installed a self-signed root, so that it is not necessary to apply to a third party and wait for the certificate to be issued. Before deploying the full PKI, however, consider whether to have a root CA, how many to have, and where both root and subordinate CAs will be located.