Table of Contents
Advertisement
Certificate Manager
7. Revoking the certificate (CA)
8. Checking whether the certificate is revoked or active when an entity tries to use the certificate for
authentication (OCSP)
All of the subsystems (CA, RA, DRM, and OCSP, as well as the token subsystems) are organized
together in security domains. Security domains define communication between subsystems, and this
makes the Certificate System very efficient. For example, if a user needs to archive keys, the request
can be processed by the first available DRM in the domain, automatically. The available DRMs in the
domain are automatically updated every time a new DRM is configured.
1.1.1. Certificate Manager
The Certificate Manager subsystem is a certificate authority. It issues, renews, revokes, and publishes
a wide variety of certificates: for servers, for users, for routers, for other subsystems, and for file or
object signing. The Certificate Manager also compiles and publishes CRLs.
Certificate Managers can be structured in series (hierarchy), so that one Certificate Manager sets
policies and issues signing certificates to a subordinate CA. The highest Certificate Manager in the
chain is a root CA.
A special kind of certificate is used by CAs to sign certificates they issue, sort of like a stamp or seal.
This is called a CA signing certificate. A subordinate CA is issued a CA signing certificate by a CA
higher in the hierarchy, and the parameters of the CA signing certificate are set by the superior CA. A
CA which issues its own signing certificate has a self-signed certificate. There are benefits to having a
self-signed CA certificate for your root CA, as well as some benefits to having the certificate signed by
a third-party CA.
Additionally, a Certificate Manager is always the subsystem which works as the registry for the security
domain. The very first Certificate Manager configured must create a security domain, but every
Certificate Manager configured after has the option of joining an existing security domain rather than
creating a new one. The configuration of your PKI deployment determines whether you need multiple
security domains; for more information, see the Red Hat Certificate System Deployment Guide.
1.1.2. Registration Authority
The Registration Authority subsystem handles certain certificate issuing tasks locally, such as
generating and submitting certificate requests. This effectively makes the RA a load-balancer for the
CA; a local RA can receive and verify the legitimacy of a certificate request (authenticate it) and then
forward valid requests to the CA to issue the certificate. Certificates can also be retrieved through the
RA and the status of the request can be checked through the RA, both of which lower demand on the
CA.
The RA is normally set up outside of the firewall, and the CA is set up behind the firewall so that
requests can be submitted to Certificate System externally, while the CA is protected.
The RA accepts requests for a smaller number of certificate types than the CA, including user, server,
and router certificates.
1.1.3. Data Recovery Manager
The Data Recovery Manager (DRM) is a key recovery authority, which means it works with the
Certificate Manager when a certificate is issued and stores private encryption keys. Those private keys
can be restored (in a PKCS #12 file) if a certificate is lost.
3
Advertisement
Table of Contents
