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.

2.1.1. About the Certificate Manager (CA)

As stated, the Certificate Manager is the heart of the Certificate System. It manages certificates at every stage, from requests through enrollment (issuing), renewal, and revocation. The CA also publishes certificates and lists of revoked certificates for use by clients like the OCSP or web servers. Issuing Certificates (Enrollment)

An end entity enrolls in the PKI by submitting an enrollment request through the end-entity interface. There can be many kinds of enrollment that use different enrollment methods or require different authentication methods. For each enrollment, there is a separate enrollment page created that is specific to the type of enrollment, type of authentication, and the certificate profiles associated with the type of certificate. The forms associated with enrollment can be customized for both appearance and content. Alternatively, the enrollment process can be customized by creating certificate profiles for each enrollment type. Certificate profiles dynamically-generate forms which are customized by configuring the inputs associated with the certificate profile.
When an end entity enrolls in a PKI by requesting a certificate, the following events can occur, depending on the configuration of the PKI and the subsystems installed:
  1. The end entity provides the information in one of the enrollment forms and submits a request.
    The information gathered from the end entity is customizable in the form depending on the information collected to store in the certificate or to authenticate against the authentication method associated with the form. The form creates a request that is then submitted to the Certificate Manager.
  2. The enrollment form triggers the creation of the public and private keys or for dual-key pairs for the request.
  3. The end entity provides authentication credentials before submitting the request, depending on the authentication type. This can be LDAP authentication, PIN-based authentication, or certificate-based authentication.
  4. The request is submitted either to an agent-approved enrollment process or an automated process.
    • The agent-approved process, which involves no end-entity authentication, sends the request to the request queue in the agent services interface, where an agent must processes the request. An agent can then modify parts of the request, change the status of the request, reject the request, or approve the request.
      Automatic notification can be set up so an email is sent to an agent any time a request appears in the queue. Also, an automated job can be set to send a list of the contents of the queue to agents on a pre configured schedule.
    • The automated process, which involves end-entity authentication, processes the certificate request as soon as the end entity successfully authenticates.
  5. The form collects information about the end entity from an LDAP directory when the form is submitted. For certificate profile-based enrollment, the defaults for the form can be used to collect the user LDAP ID and password.
  6. The certificate profile associated with the form determine aspects of the certificate that is issued. Depending on the certificate profile, the request is evaluated to determine if the request meets the constraints set, if the required information is provided, and the contents of the new certificate.
  7. The form can also request that the user export the private encryption key. If the DRM subsystem is set up with this CA, the end entity's key is requested, and an archival request is sent to the DRM. This process generally requires no interaction from the end entity.
  8. The certificate request is either rejected because it did not meet the certificate profile or authentication requirements, or a certificate is issued.
  9. The certificate is delivered to the end entity.
    • In automated enrollment, the certificate is delivered to the user immediately. Since the enrollment is normally through an HTML page, the certificate is returned as a response on another HTML page.
    • In agent-approved enrollment, the certificate can be retrieved by serial number or request Id in the end-entity interface.
    • If the notification feature is set up, the link where the certificate can be obtained is sent to the end user.
  10. An automatic notice can be sent to the end entity when the certificate is issued or rejected.
  11. The new certificate is stored in the Certificate Manager's internal database.
  12. If publishing is set up for the Certificate Manager, the certificate is published to a file or an LDAP directory.
  13. The internal OCSP service checks the status of certificates in the internal database when a certificate status request is received.
The end-entity interface has a search form for certificates that have been issued and for the CA certificate chain. Renewal

When certificates reach their expiration date, they can either be allowed to lapse, or they can be renewed.
Renewal regenerates a certificate request using the existing key pairs for that certificate, and then resubmits the request to Certificate Manager. The renewed certificate is identical to the original (since it was created from the same profile using the same key material) with one exception — it has a different, later expiration date.
Renewal can make managing certificates and relationships between users and servers much smoother, because the renewed certificate functions precisely as the old one. For user certificates, renewal allows encrypted data to be accessed without any loss. Revocation

End entities can request that their own certificates be revoked. When an end entity makes the request, the certificate has to be presented to the CA. If the certificate and the keys are available, the request is processed and sent to the Certificate Manager, and the certificate is revoked. The Certificate Manager marks the certificate as revoked in its database and adds it to any applicable CRLs.
An agent can revoke any certificate issued by the Certificate Manager by searching for the certificate in the agent services interface and then marking it revoked. Once a certificate is revoked, it is marked revoked in the database and in the publishing directory, if the Certificate is set up for publishing.
If the internal OCSP service has been configured, the service determines the status of certificates by looking them up in the internal database.
Automated notifications can be set to send email messages to end entities when their certificates are revoked by enabling and configuring the certificate revoked notification message.

2.1.2. About the Registration Manager (RA)

A registration authority (RA) is an intermediary between a user and a CA. It accepts enrollment requests and then authenticates them locally. If the request is approved, the RA sends the request to the CA to issue the certificate and, once the certificate is issued, sends the certificate back to the user.
RAs remove some of the load from CAs by handling the validation part of a certificate request. For example, offices or organizations can validate requests locally, according to their predefined standards, using RA agents. This requires fewer CAs and allows the organization to group all of the CAs in a separate, secure location.
The kinds of certificates that can generated in the Certificate System RA are limited to the most common types of certificates: user certificates, SSL client certificates, RA agent certificates, and SCEP certificates for local routers. Users can check the RA services pages to view their certificate request status, retrieve their issued certificates, and renew their certificates.
Certificate System RAs can perform either automatic approval and manual approval, depending on the configuration in the enrollment profiles. Like the CA, the RA can also be configured to send a notification when the certificate request is processed.
The RA is normally set up outside of the firewall, and the CA is set up behind the firewall. This enables requests to be made from outside the protected environment (for example, the Internet), while the CA remains under the protection of the site's security measures.

2.1.3. About OCSP Services

The Certificate System CA supports the Online Certificate Status Protocol (OCSP) as defined in PKIX standard RFC 2560. The OCSP protocol enables OCSP-compliant applications to determine the state of a certificate, including the revocation status, without having to directly check a CRL published by a CA to the validation authority. The validation authority, which is also called an OCSP responder, checks for the application.
  1. A CA is set up to issue certificates that include the Authority Information Access extension, which identifies an OCSP responder that can be queried for the status of the certificate.
  2. The CA periodically publishes CRLs to an OCSP responder.
  3. The OCSP responder maintains the CRL it receives from the CA.
  4. An OCSP-compliant client sends requests containing all the information required to identify the certificate to the OCSP responder for verification. The applications determine the location of the OCSP responder from the value of the Authority Information Access extension in the certificate being validated.
  5. The OCSP responder determines if the request contains all the information required to process it. If it does not or if it is not enabled for the requested service, a rejection notice is sent. If it does have enough information, it processes the request and sends back a report stating the status of the certificate. OCSP Response Signing

Every response that the client receives, including a rejection notification, is digitally signed by the responder; the client is expected to verify the signature to ensure that the response came from the responder to which it submitted the request. The key the responder uses to sign the message depends on how the OCSP responder is deployed in a PKI setup. RFC 2560 recommends that the key used to sign the response belong to one of the following:
  • The CA that issued the certificate that's status is being checked.
  • A responder with a public key trusted by the client. Such a responder is called a trusted responder.
  • A responder that holds a specially marked certificate issued to it directly by the CA that revokes the certificates and publishes the CRL. Possession of this certificate by a responder indicates that the CA has authorized the responder to issue OCSP responses for certificates revoked by the CA. Such a responder is called a CA-designated responder or a CA-authorized responder.
The end-entities page of a Certificate Manager includes a form for manually requesting a certificate for the OCSP responder. The default enrollment form includes all the attributes that identify the certificate as an OCSP responder certificate. The required certificate extensions, such as OCSPNoCheck and Extended Key Usage, can be added to the certificate when the certificate request is submitted. OCSP Responses

The OCSP response that the client receives indicates the current status of the certificate as determined by the OCSP responder. The response could be any of the following:
  • Good or Verified . Specifies a positive response to the status inquiry, meaning the certificate has not been revoked. It does not necessarily mean that the certificate was issued or that it is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate.
  • Revoked . Specifies that the certificate has been revoked, either permanently or temporarily.
Based on the status, the client decides whether to validate the certificate.


The OCSP responder will never return a response of Unknown. The response will always be either Good or Revoked. OCSP Services

There are two ways to set up OCSP services:
  • The OCSP built into the Certificate Manager
  • The Online Certificate Status Manager subsystem
In addition to the built-in OCSP service, the Certificate Manager can publish CRLs to an OCSP-compliant validation authority. CAs can be configured to publish CRLs to the Certificate System Online Certificate Status Manager. The Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses the appropriate CRL to verify the revocation status of a certificate when queried by an OCSP-compliant client.
The Certificate Manager can generate and publish CRLs whenever a certificate is revoked and at specified intervals. Because the purpose of an OCSP responder is to facilitate immediate verification of certificates, the Certificate Manager should publish the CRL to the Online Certificate Status Manager every time a certificate is revoked. Publishing only at intervals means that the OCSP service is checking an outdated CRL.


If the CRL is large, the Certificate Manager can take a considerable amount of time to publish the CRL.
The Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses it as the CRL to verify certificates. The Online Certificate Status Manager can also use the CRL published to an LDAP directory, meaning the Certificate Manager does not have to update the CRLs directly to the Online Certificate Status Manager.

2.1.4. About the Data Recovery Manager (DRM)

To archive private encryption keys and recover them later, the PKI configuration must include the following elements:
  • Clients that can generate dual keys and that support the key archival option (using the CRMF/CMMF protocol).
  • An installed and configured DRM.
  • HTML forms with which end entities can request dual certificates (based on dual keys) and key recovery agents can request key recovery.
Only keys that are used exclusively for encrypting data should be archived; signing keys in particular should never be archived. Having two copies of a signing key makes it impossible to identify with certainty who used the key; a second archived copy could be used to impersonate the digital identity of the original key owner.
Clients that generate single key pairs use the same private key for both signing and encrypting data, so a private key derived from a single key pair cannot be archived and recovered. Clients that can generate dual key pairs use one private key for encrypting data and the other for signing data. Since the private encryption key is separate, it can be archived.
In addition to generating dual key pairs, the clients must also support archiving the encryption key in certificate requests. This option archives keys at the time the private encryption keys are generated as a part of issuing the certificate. Archiving Keys

The DRM automatically archives private encryption keys if archiving is configured.
If an end entity loses a private encryption key or is unavailable to use the private key, the key must be recovered before any data that was encrypted with the corresponding public key can be read. Recovery is possible if the private key was archived when the key was generated.
There are some common situations when it is necessary to recover encryption keys:
  • An employee loses the private encryption key and cannot read encrypted mail messages.
  • An employee is on an extended leave, and someone needs to access an encrypted document.
  • An employee leaves the company, and company officials need to perform an audit that requires gaining access to the employee's encrypted mail.
The DRM stores private encryption keys in a secure key repository in its internal database; each key is encrypted and stored as a key record and is given a unique key identifier.
The archived copy of the key remains wrapped with the DRM's storage key. It can be decrypted, or unwrapped, only by using the corresponding private key pair of the storage certificate. A combination of one or more key recovery (or DRM) agents' certificates authorizes the DRM to complete the key recovery to retrieve its private storage key and use it to decrypt/recover an archived private key.
The DRM indexes stored keys by key number, owner name, and a hash of the public key, allowing for highly efficient searching. The key recovery agents have the privilege to insert, delete, and search for key records.
  • When the key recovery agents search by the key ID, only the key that corresponds to that ID is returned.
  • When the agents search by user name, all stored keys belonging to that owner are returned.
  • When the agents search by the public key in a certificate, only the corresponding private key is returned.
When a Certificate Manager receives a certificate request that contains the key archival option, it automatically forwards the request to the DRM to archive the encryption key. The private key is encrypted by the transport key, and the DRM receives the encrypted copy and stores the key in its key repository. To archive the key, the DRM uses two special key pairs:
  • A transport key pair and corresponding certificate.
  • A storage key pair.
Figure 2.1, “How the Key Archival Process Works” illustrates how the key archival process occurs when an end entity requests a certificate.
How the Key Archival Process Works

Figure 2.1. How the Key Archival Process Works

  1. The client requests and generates a dual key pair.
    1. The end entity, using a client which can generate dual key pairs, submits a request through the Certificate Manager enrollment form.
    2. The client detects the JavaScript in the enrollment form and exports only the private encryption key, not the private signing key.
    3. The Certificate Manager detects the key archival option in the request and asks the client for the private encryption key.
    4. The client encrypts the private encryption key with the public key from the DRM's transport certificate embedded in the enrollment form.
  2. After approving the certificate request and issuing the certificate, the Certificate Manager sends it to the DRM for storage, along with the public key. The Certificate Manager waits for verification from the DRM that the private key has been received and stored and that it corresponds to the public encryption key.
  3. The DRM decrypts it with the private key. After confirming that the private encryption key corresponds to the public encryption key, the DRM encrypts it again with its public key pair of the storage key before storing it in its internal database.
  4. Once the private encryption key has been successfully stored, the DRM uses the private key of its transport key pair to sign a token confirming that the key has been successfully stored; the DRM then sends the token to the Certificate Manager.
  5. The Certificate Manager issues two certificates for the signing and encryption key pairs and returns them to the end entity.
Both subsystems subject the request to configured certificate profile constraints at appropriate stages. If the request fails to meet any of the profile constraints, the subsystem rejects the request. Key Recovery

The DRM supports agent-initiated key recovery. Agent-initiated recovery is when designated recovery agents use the key recovery form on the DRM agent services page to process and approve key recovery requests. With the approval of a specified number of agents, an organization can recover keys when the key's owner is unavailable or when keys have been lost.
Through the DRM agent services page, key recovery agents can collectively authorize and retrieve private encryption keys and associated certificates in a PKCS #12 package, which can then be imported into the client. (This is explained in more detail in the Certificate System Agent's Guide.) To authorize key recovery, the required number of recovery agents access the DRM agent services page and use the Authorize Recovery button to enter each authorization separately.
In key recovery authorization, one of the key recovery agents informs all required recovery agents about an impending key recovery. All recovery agents access the DRM key recovery page. One of the agents initiates the key recovery process. The DRM returns a notification to the agent includes a recovery authorization reference number identifying the particular key recovery request that the agent is required to authorize. Each agent uses the reference number and authorizes key recovery separately.
The DRM informs the agent who initiated the key recovery process of the status of the authorizations.


The page that the first agent used to initiate the key recovery request keeps refreshing until all agents required to authorize have performed the authorization. It is important that the first agent does not close this browser session until the authorization is complete. Otherwise, the key recovery request needs to be started again.
When all of the authorizations are entered, the DRM checks the information. If the information presented is correct, it retrieves the requested key and returns it along with the corresponding certificate in the form of a PKCS #12 package to the agent who initiated the key recovery process.


The PKCS #12 package contains the private key. To minimize the risk of key compromise, the recovery agent must use a secure method to deliver the PKCS #12 package and password to the key recipient. The agent should use a good password to encrypt the PKCS #12 package and set up an appropriate delivery mechanism.
The key recovery agent scheme configures the DRM to recognize to which group the key recovery agents belong and specifies how many of these agents are required to authorize a key recovery request before the archived key is restored.

2.1.5. About the Token Processing System (TPS)

The Token Processing System (TPS) serves as the conduit between the Enterprise Security Client and the other subsystems (CA, TKS, DRM) in the Certificate System and is the only means for the client to communicate with the other subsystems. It provides the following functionalities for users managing their smart cards through the Enterprise Security Client:
  • Working with multiple instances of a subsystem
  • Formatting smart cards
  • Resetting the PIN on smart card tokens
  • Upgrading the applet for smart card tokens
  • Enrolling smart cards through the Enterprise Security Client
  • Performing LDAP authentication
  • Managing the token database
  • Logging token events
The TPS must be configured to work with two Certificate System subsystems: the CA, which will process all of the certificate enrollment and revocation requests initiated through the Enterprise Security Client, and the Token Key Service, which generates a master key which is used to derive secret keys specific to each smart card, which are used to wrap (encrypt) the certificates and commands transmitted between the TPS and the client. The TPS can be optionally configured to work with a DRM instance, which will perform server-side key generation and key archival and recovery for the keys and certificates stored on the smart cards.

2.1.6. About the Token Key Service (TKS)

The Certificate System Token Management System consists of three components, the Token Processing System (TPS), the Token Key Service (TKS), and the Enterprise Security Client. This section explains the TKS, which manages the master keys required set up a secure communication channel between the TPS and the client.
A TKS manages the master and transport keys required to generate and distribute keys for smart cards or tokens. A master key is a Triple DES symmetric key stored either in software or hardware token. When supplied with the token CUID, a TKS can derive the corresponding three symmetric keys ‐ authentication key, Mac key, and key encryption key (KEK) ‐ on each token. This effectively shares secrets between the Certificate System and the token without having to store these symmetric keys on the server.
The Certificate System TPS subsystem uses the TKS subsystem to generate the token keys the TPS uses to communicate with the Enterprise Security Client. The TPS communicates with the TKS over SSL. The TKS provides the security between tokens and the TPS since the security relies on the relationship between the master key and the token keys.
The functions provided by the TKS include the following:
  • Helps establish a secure channel (signed and encrypted) between the token and TPS.
  • Provides proof of presence for the security token during enrollment.
  • Supports key changeover when the master key changes on the TKS. Tokens with older keys get new token keys.
  • Helps generate a symmetric session key for the DRM to wrap (encrypt) the entity's private key for (optional) server-side key generation, where the entity's encryption keys are generated on the DRM


Because of the sensitivity of the data that the TKS manages, the TKS should be set behind the firewall with restricted access.