Chapter 1. Overview of Red Hat Certificate System subsystems
Every common PKI operation - issuing, renewing and revoking certificates; archiving and recovering keys; publishing CRLs and verifying certificate status - is carried out by interoperating subsystems within Red Hat Certificate System. The functions of each individual subsystem and the way that they work together to establish a robust and local PKI is described in this chapter.
1.1. Uses for certificates Copy linkLink copied to clipboard!
The purpose of certificates is to establish trust. Their usage varies depending on the kind of trust they are used to ensure. Some kinds of certificates are used to verify the identity of the presenter; others are used to verify that an object or item has not been tampered with.
For information on how certificates are used, the types of certificates, or how certificates establish identities and relationships, see the Certificates and Authentication section in the Red Hat Certificate System Planning, Installation, and Deployment Guide.
1.2. A review of Certificate System subsystems Copy linkLink copied to clipboard!
Red Hat Certificate System provides five different subsystems, each focusing on different aspects of a PKI deployment:
- A Certificate Authority (CA)
- A Key Recovery Authority (KRA)
- An online certificate status protocol (OCSP) responder
- A token key service (TKS)
- A token processing system (TPS)
- An Automated Certificate Management Environment system (ACME)
These subsystems work together to create a public key infrastructure (PKI). Depending on what subsystems are installed, a PKI can function as a token management system (TMS) or a non token management system. For detailed descriptions of the subsystems and TMS and non-TMS environments, see the A Review of Certificate System Subsystems section in the Red Hat Certificate System Planning, Installation, and Deployment Guide.
Enterprise Security Client
The Enterprise Security Client (ESC) is not a subsystem since it does not perform any operations with certificates, keys, or tokens. The Enterprise Security Client is a user interface which allows people to manage certificates on smart cards very easily. The Enterprise Security Client sends all token operations, such as certificate requests, to the token processing system (TPS), which then sends them to the certificate authority (CA). For more information, see Managing Smart Cards with the Enterprise Security Client.
1.3. A look at managing certificates (non-TMS) Copy linkLink copied to clipboard!
A conventional PKI environment provides the basic framework to manage certificates stored in software databases. This is a non-TMS environment, since it does not manage certificates on smart cards. At a minimum, a non-TMS requires only a CA, but a non-TMS environment can use OCSP responders and KRA instances as well.
For information on this topic, see the following sections in the Red Hat Certificate System Planning, Installation, and Deployment Guide:
1.4. A look at the token management system (TMS) Copy linkLink copied to clipboard!
Certificate System creates, manages, renews, and revokes certificates, and it also archives and recovers keys. For organizations that use smart cards, the Certificate System has a token management system - a collection of subsystems with established relationships - to generate keys and requests and receive certificates to be used for smart cards.
For information on this topic, see the following sections in the Red Hat Certificate System Planning, Installation, and Deployment Guide:
1.5. Red Hat Certificate System services Copy linkLink copied to clipboard!
There are various different interfaces for managing certificates and subsystems, depending on the type of user: administrators, agents, auditors, and end users. For an overview of the different functions that are performed through each interface, see the User Interfaces section.