Planning Security Domains And Trust Relationships; Understanding Security Domains - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

Hide thumbs Also See for CERTIFICATE SYSTEM 8 - DEPLOYMENT:
Table of Contents

Advertisement

Because clone CAs and original CAs use the same CA signing key and certificate to sign the
certificates they issue, the issuer name in all the certificates is the same. Clone CAs and the original
Certificate Managers issue certificates as if they are a single CA. These servers can be placed on
different hosts for high availability failover support.
The advantage of cloning is that it distributes the Certificate Manager's load across several processes
or even several physical machines. For a CA with a high enrollment demand, the distribution gained
from cloning allows more certificates to be signed and issued in a given time interval.
A cloned Certificate Manager has the same features, such as agent and end-entity gateway functions,
of a regular Certificate Manager.
The serial numbers for clones are distributed dynamically. All of the cloned servers share a common
entry which defines the next available range; when a server needs another range of numbers, it
claims the range in the shared entry, and the entry increments so that a new range is available. Serial
number ranges do not have to be manually assigned to the cloned Certificate Managers. This makes
managing serial numbers for certificates is easy to administrate.
TIP
If there is a chance that a subsystem will be cloned, then it is easiest to export its key
pairs during the configuration process and save them to a secure location. The key
pairs for the original Certificate Manager have to be available when the clone instance
is configured, so that the clone can generate its certificates from the original Certificate
Manager's keys.
It is also possible to export the keys from the security databases at a later time, using the
pk12util or the PKCS12Export commands.

5.3. Planning Security Domains and Trust Relationships

5.3.1. Understanding Security Domains

A security domain is a registry of PKI services. PKI services, such as CAs, 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.
The registry provides a complete view of all PKI services provided by the subsystems within that
domain. Each Certificate System subsystem must be either a host or 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.
A security domain is created during CA configuration, which automatically creates an entry in the
security domain CA's LDAP directory. Each entry contains all the important information about the
domain. Every subsystem within the domain, including the CA registering the security domain, is
recorded under the security domain container entry.
The URL to the CA uniquely identifies the security domain. The security domain is also given a friendly
name, such as Example Corp Intranet PKI. All other subsystems — RA, DRM, TPS, TKS,
Planning Security Domains and Trust Relationships
63

Advertisement

Table of Contents
loading

Table of Contents