Agent Services; Overview Of Certificate System; Certificate System Sub-Systems - Red Hat CERTIFICATE SYSTEM 7.3 - AGENT GUIDE Manual

Chapter 2.

Agent Services

This chapter describes the role of the privileged users, agents, in managing Certificate System sub-
systems. It also introduces the tools that agents use to administer service requests.

2.1. Overview of Certificate System

The Red Hat Certificate System is a highly configurable set of software components and tools for cre-
ating, deploying, and managing certificates. The standards and services that facilitate the use of pub-
lic-key cryptography and X.509 version 3 certificates in a networked environment are collectively
called the public-key infrastructure (PKI) for that environment. In any PKI, a certificate authority (CA) is
a trusted entity that issues, renews, and revokes certificates. An end entity is a person, server, or other
entity that uses a certificate to identify itself.
To participate in a PKI, an end entity must enroll, or register, in the system. The end entity typically ini-
tiates enrollment by giving the CA some form of identification and a newly generated public key. The
CA uses the information provided to authenticate, or confirm, the identity, then issues the end entity a
certificate that associates that identity with the public key and signs the certificate with the CA's own
private signing key.
End entities and CAs can exist in different geographic or organizational areas or in completely different
organizations. CAs may include third parties that provide services through the Internet as well as the
root CAs and subordinate CAs for individual organizations. Policies and certificate content may vary
from one organization to another. End-entity enrollment for some certificates may require physical veri-
fication, such as an interview or notarized documents, while enrollment for others may be fully auto-
mated.

2.1.1. Certificate System Sub-systems

To meet the widest possible range of configuration requirements, the Certificate System permits inde-
pendent installation of five separate subsystems, or managers, that play distinct roles:
Certificate Manager
A Certificate Manager (CM) functions as a root or subordinate CA. This subsystem issues, renews,
and revokes certificates and generates certificate revocation lists (CRLs). It can also publish certific-
ates, files, and CRLs to an LDAP directory, to files, and to an Online Certificate Status Protocol
(OCSP) responder.
The CM can process requests manually (with agent action) or automatically (based on customizable
profiles). Publishing tasks can only be performed by the CM.
The CM also has a built-in OCSP service, enabling OCSP-compliant clients to query the CM directly
about the revocation status of a certificate that it has issued. In certain PKI deployments, it might be
convenient to use the CM's built-in OCSP service, instead of an OCSM.
Because CAs can delegate some responsibilities to subordinate CAs, a CM might share its load
among one or more levels of subordinate CMs.
Subsystems can also be cloned. All clones use the same keys and certificates as the master, which
means that the master and clones essentially all function as a single CA. Many complex deployment
7