Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE, Руководство администратора

Страница: 44 / 512

Chapter 2. Installation and Configuration
24
• 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.
2.1.1. Security Domains
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.
2.1.2. Cloning a Subsystem
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 19,
Configuring the Certificate System for High Availability
.
2.1.3. Self-Signed Root CA or Subordinate CA
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