Overview Of Red Hat Certificate System Subsystems; A Review Of Certificate System Subsystems - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

Chapter 2.
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 — are 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.

2.1. A Review of Certificate System Subsystems

Red Hat Certificate System provides six different subsystems, each focusing on different aspects of a
PKI deployment:
• A certificate authority called a Certificate Manager. The CA is the core of the PKI; it issues and
revokes all certificates. The Certificate Manager is also the core of the Certificate System. By
establishing a security domain of trusted subsystems, it establishes and manages relationships
between the other subsystems.
• A key recovery authority called a data recovery manager (DRM). Certificates are created based on
a specific and unique key pair. If a private key is ever lost, then the data which that key was used
to access (such as encrypted emails) is also lost because it is inaccessible. The DRM stores key
pairs, so that a new, identical certificate can be generated based on recovered keys, and all of the
encrypted data can be accessed even after a private key is lost or damaged.
• An online certificate status responder (OCSP). The OCSP verifies whether a certificate is valid and
not expired. This function can also be done by the CA, which has an internal OCSP service, but
using an external OCSP eases the load off of the issuing CA.
• A registration authority (RA). An RA accepts certificate requests and verifies, independently,
whether that request should be approved. It then forwards approved requests to the CA to issue the
certificate. Like the OCSP, this is a function that can be performed by the CA, but using a separate
subsystem reduces the load on the CA.
• A token key service (TKS). The TKS derives keys based on the token CCID, private information,
and a defined algorithm. These derived keys are used by the TPS to format tokens and enroll, or
process, certificates on the token.
• A token processing system (TPS). The TPS interacts directly with external tokens, like smart
cards, and manages the keys and certificates on those tokens through a local client, the Enterprise
Security Client. The Enterprise Security Client contacts the TPS when there is a token operation,
and the TPS interacts with the CA, DRM, or TKS, as required, then send the information back to the
token by way of the Enterprise Security Client.
Even with all possible subsystems installed, the core of the Certificate System is still the CA (or CAs),
since they ultimately process all certificate-related requests. The other subsystems connect to the CA
or CAs likes spokes in a wheel.
23