Multiple CAs can be configured to form a vertical or horizontal chain of CAs. A vertical hierarchy has a root CA (that is either self-signing or subordinate to a public CA) and then one or more CAs subordinate to this root CA. The subordinate CAs can have more CAs below them, forming a chain of CAs. A horizontal arrangement has a CA which is duplicated, or cloned, so that two CAs are set up in an identical manner and use the same CA signing certificate but issue certificates from a different set of serial numbers.

The different possible Certificate Manager deployments provide flexibility to the PKI through the following features:

It is possible to create a trusted relationship between two separate CAs by issuing and storing cross-signed certificates between these two CAs. By using cross-signed certificate pairs, certificates issued outside the organization's PKI can be trusted within the system.

The Certificate Manager issues, renews, and revokes certificates when it receives signed requests. These requests can come from its own agents (users who are assigned privileges to approve enrollment, renewal, and revocation requests) or from a third-party application that uses its agent certificate (this agent certificate must be set up for CMC enroll or revoke with the Certificate Manager).

The Certificate Manager also compiles lists of revoked certificates, called certificate revocation lists (CRLs), that it can publish to files, an LDAP directory, or an OCSP service.

The Certificate Manager maintains a database of issued certificates and processed requests, so that it can track renewal, expiration, and revocation.

Certificate System can issue and manage the following certificates:

This list is not comprehensive; many other types of certificates can be issued by the Certificate System.

Revoking certificates can be initiated either by an agent or by the end user. An administrator can also revoke the certificates of any of the subsystems or agents.

The Certificate System also supports CMC revocation. When the CMCAuth plug-in is enabled, CMC enrollment and CMC revocation are both enabled. CMC revocation sends signed revocation requests that are automatically processed.

The Certificate System can create certificate revocation lists (CRLs) that it can publish to files, an LDAP directory, or to an OCSP responder. It is also possible to create CRLs through certificate issuing points, which allows more than one CRL to be defined by the issuing point. Lastly, creating delta CRLs creates a list which contains only the certificates that were revoked since the last CRL was produced.

See Chapter 14, Revocation and CRLs for details.

The Certificate Manager server has an end-entities page with the forms for different types of certificates and users. This interface can be customized to limit the forms that are available, change the appearance of the pages, or add or delete fields. Certificate requests that come through the Certificate Managers end-entities page are processed by the Certificate Manager. If it is an agent-approved enrollment, an agent of the Certificate Manager must approve the request. If it is an automated enrollment, the request is approved if the end entity supplies the correct information and authenticates successfully.

Authentication plug-ins set up automated enrollment and configure the methods for the end entity to authenticate itself. For agent-approved enrollment, the agent approves the request by default. Each end-entity form is associated with a particular authentication method which is configured in the certificate profile, either one of the automated methods or the agent-approved method. The Certificate Manager processes the request according to the method associated with the form.

When the Certificate Manager processes requests from its end-entities page, it first considers the authentication method. If it is an agent-approved authentication method, the request is queued in the agent services interface where it awaits agent approval. The agent can change some aspects of the certificate that will be issued and can approve, deny, or change the status of the request. For an automated enrollment, the CA authenticates the user and continues processing the request.

The Certificate Manager next evaluates the request to ensure that it meets the certificate profile set for this type of enrollment.

Certificate profiles connect an authentication method and certificate type to a set of constraints and certificate content definitions (defaults). A single module can be configured for a type of certificate to use a specific authentication method and set constraints for the certificate, as well as defining the certificate content. The default certificate profiles can be modified and new custom modules created. See Chapter 13, Certificate Profiles for details.

If the policies in the certificate profile are not met, the request is rejected. If they are met, the certificate is issued.

The Certificate Manager issues certificates when it receives signed requests either from agents (users who are assigned privileges to approve enrollment, renewal, and revocation requests) or from a third-party application that is set up for CMC enroll with the Certificate Manager.

The Certificate Manager creates the certificate using the information in the request and from the certificate profile that are set.

Certificates can be published to a file, an LDAP directory, or OCSP responder. Configuring publishing sets rules to determine which certificates are published using which method and where they are published. See Chapter 15, Publishing for details.

If a CA is configured with a DRM, then the private keys are archived in the DRM during certificate enrollment. See Chapter 7, Data Recovery Manager for details.

When it issues a certificate, the Certificate Manager stores both the certificate and the certificate request in its internal database.

Certain types of certificates can be renewed if the profile policies allow renewal. Subsystem certificates such as server certificates, CA and OCSP signing certificates, and DRM transport and storage certificates can be renewed through the appropriate subsystem administrative console and through the issuing CA's end-entities page. The existing key pairs are used to sign the request again, generating a new certificate from the existing information.

End entities can submit certificate revocation requests in the end-entities page if they lose their private key or if their certificate has been compromised. When an end entity requests a revocation, the request is sent to the agent services interface for agent approval.

An agent can revoke a certificate if the owner of the certificate is unwilling or unable to do so.

When the certificate is revoked, it is marked revoked in the internal database and in the publishing system. The certificate is added to the certificate revocation list (CRL) produced by the Certificate Manager. See Chapter 14, Revocation and CRLs for details.

Whenever a certificate is revoked, any CRLs that are set up are edited and updated in the internal database. It is published to a file, an LDAP directory, or an OCSP responder, if these services have been set up. The CA can be configured to issue CRLs and define CRL issuing points that define which certificates go into each CRL.

CRL configuration grants flexibility to define which CRL is published where, the extensions contained in a CRL, and the frequency and intervals when a CRL are published. Publishing delta CRLs publishes a list of only those certificates that have been revoked since a certain date. See Chapter 14, Revocation and CRLs for details.

If a DRM is set up as part of the PKI, the private encryption key for an end entity is requested and stored when the enrollment request is made.

If a DRM is set up as part of the PKI, the users' private encryption keys can be retrieved to decrypt messages or other documents that have been encrypted with the private encryption key.

Version 7.1 of Red Hat Certificate System introduced a new m-of-n, ACL-based recovery scheme to replace the old m-of-n, secret-splitting-based recovery scheme.

In the old scheme, the password for the storage token was split and protected by individual recovery agent passwords. This made it hard to access the storage private, but it did not allow CS to fully leverage the key protection facility provided by the underlying hardware token.

In the new scheme, CS uses its existing access control scheme to ensure recovery agents are appropiately authenticated via SSL, and ensures that the agent belongs to the specific recovery agent group. The recovery request is executed only when m-of-n recovery agents have granted authorization to the request.

By default, the DRM sets up a 1-of-1 ACL-based recovery scheme, and the agent must belong to the group "Data Recovery Manager Agents". You can change the scheme by modifying the appropriate parameters in the CS.cfg file. Refer to Chapter 7, Data Recovery Manager for more information on this topic.