Chapter 1. Overview of Red Hat Certificate System subsystems
Chapter 1. Overview of Red Hat Certificate System subsystems Note This chapter is an overview of Red Hat Certificate System and the various subsystems. For details on evaluated product features, please see the NIAP Product Compliant List at https://www.niap-ccevs.org/Product/PCL.cfm . Note Network security services (NSS) and Federal Information Processing Standard (FIPS) hardware security modules (HSM) were the only evaluated cryptographic providers. 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 they work together to establish a robust and local PKI is described in this chapter. 1.1. Uses for certificates 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. 1.2. A review of Certificate System subsystems 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) 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 in the Planning, Installation and Deployment Guide (Common Criteria Edition) . Note Red Hat Certificate System includes Technology Preview code (e.g., EST). This early access to upcoming product functionality is not evaluated and not to be used in the evaluated configuration. 1.3. A look at managing certificates (non-TMS) 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 Planning, Installation and Deployment Guide (Common Criteria Edition) : Managing Certificates Using a Single Certificate Manager Planning for Lost Keys: Key Archival and Recovery Balancing Certificate Request Processing Balancing Client OCSP Requests 1.4. A look at the token management system (TMS) Note Features in this section on TMS are not tested in the evaluation. This section is for reference only. 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 Planning, Installation and Deployment Guide (Common Criteria Edition) : Working with Smart Cards (TMS) Using Smart Cards 1.5. Red Hat Certificate System services There are various 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 Chapter 2, User interfaces .