Chapter 2. Installation and Configuration
The Certificate System is comprised of subsystems which can be independently installed on different servers, multiple instances installed on a single server, and other flexible configurations for availability, scalability, and failover support. The procedures for downloading, installing, and configuring instances of Certificate System subsystems are described in this chapter.
The Certificate System servers include five subsystems:
Certificate Authority (CA)
Data Recovery Manager (DRM), sometimes referred to as a Key Recovery Authority (KRA)
Online Certificate Status Protocol (OCSP) Responder
Token Key Service (TKS)
Token Processing System (TPS)
The Certificate System client is the Enterprise Security Client. For information about the Enterprise Security Client, see the Certificate System Enterprise Security Client Guide.
There are two steps for installing the Certificate System: the first is installing the server packages, and the second is configuring the subsystem through the HTML-based configuration wizard.
The installation and configuration process for the Certificate System is as follows:
Install a Red Hat Directory Server. This can be an different machine than the Certificate System, which is the recommended scenario for most deployments.
Download the Certificate System packages from the Red Hat Network channel. Each subsystem has its own packages, as well as dependencies and related packages. These are listed in Section 2.2.3, “Packages Installed”.
Install the Certificate System CA subsystem. See Section 2.5, “Installing the Certificate System ” for complete instructions on installing the CA.
Configure the CA subsystem. For information on configuring the Certificate Manager (CA) subsystem, see Section 2.6, “Configuring the Default Subsystem Instances”.
Install the other Certificate System subsystems on the appropriate hosts. See Section 2.5, “Installing the Certificate System ” for complete instructions on installing the subsystems.
Configure each subsystem through its HTML administrative services page. Go through the installation screens. When completed, all necessary CA, server, and agent and user certificates are generated and installed.
See Section 2.6, “Configuring the Default Subsystem Instances” for more information on the subsystem configuration pages.
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 19, 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.