Some deployments require a single Certificate Manager to handle all end-entity interactions. No DRM is necessary to provide key archival or recovery capabilities, and no OCSP is required for certificate verification. This Certificate Manager can use a signing certificate issued by a public certificate authority or its self-signed CA signing certificate to sign all the certificates it issues.

Figure 1.1, “Single-Root Certificate Manager” shows the relationships between a single Certificate Manager, end entities, and a publishing directory. The Certificate Manager can publish both end-entity certificates and CRLs to a directory.

In a more complex scenario, the organization requires key archival and recovery capabilities along with the CA; for example, when encrypted mail is widely used, the organization risks data loss if it is unable to recover encryption keys. In this case, the Certificate System deployment has both the Certificate Manager and a DRM.

To add key storage and recovery, a DRM can be installed on the same machine or on a different machine. Figure 1.2, “Certificate Manager and DRM in Different Instances” illustrates the relationship between a DRM and a Certificate Manager. All communication between the Certificate Manager and the DRM takes place over HTTPS.

When determining the location of a DRM, consider possible firewall interactions, the physical security required for each subsystem, and the physical location of the Certificate Manager agent, DRM agent, and other people responsible for administering the Certificate Manager and recovering keys.

Like a Certificate Manager, a DRM has special physical security requirements, since a compromised DRM has devastating security consequences for the entire PKI. Consider keeping the DRM in a special locked room or building; this consideration can affect the deployment strategy.

A cloned Certificate Manager uses the same CA signing key and certificate as another Certificate Manager, the master Certificate Manager. Since each Certificate Manager issues certificates with serial numbers in a restricted range, all of the servers together act as a single CA operating in several server processes.

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.

Most certificates are enrolled through the CA. This is useful for certificates enrolled through an application such as a web browser or web server. For managing smart cards, or tokens, there is an additional Certificate System client, Enterprise Security Client, which manages all maintenance operations for certificates and keys stored on smart cards.

The Enterprise Security Client communicates directly with a TPS instance. The TPS subsystem handles token-based certificate functions, and the TKS manages keys which protect the secure communication between the TPS subsystem and the Enterprise Security Client. The TKS and TPS subsystems work together to support all token operations, such as enrollment, through the Enterprise Security Client. Additionally, the TPS subsystem can be configured to use the DRM subsystem to handle server-side key generation and key archival and recovery. The interactions between the TPS, TKS, DRM, and CA subsystems to process token operations through the Enterprise Security Client are shown in Figure 1.3, “Token Management Configuration”.

For more information on managing subsystems for smart card tokens, see Chapter 8, Token Processing System. For more information on performing token operations for users, see the Certificate System Enterprise Security Client Guide, which is available at http://redhat.com/docs/manuals/cert-system/.