Overview

This chapter provides an overview of Red Hat Certificate System (CS), a highly configurable set of software components and tools for creating, deploying, and managing certificates. Based on open standards for certificate management, Certificate System provides a complete, customizable, robust, scalable, and high-performance certificate management solution for your public-key infrastructure (PKI), extranets and intranets.

Features

Subsystems

CS has four subsystems to provide flexibility in setting up your PKI. The subsystems are highly-cofigurable. The four subsystems that comprise CS are as follows:

Certificate Manager Flexibility and Scalability

The Certificate Manager can be deployed in several ways to provide flexibility in your PKI. Features include:

Single CA Supports Multiple Registration Authorities

CS lets you separate the registration process from the certificate-signing process with the help of Registration Managers. You can run multiple Registration Managers remotely, all reporting to a single Certificate Manager, to verify user identities and process certificate issuance, renewal, and revocation requests. The remote Registration Managers forward their completed and approved requests to the Certificate Manager for it to sign and issue the certificate automatically.

The Certificate Manager's ability to support multiple Registration Managers makes it more scalable and also adds an extra layer of security for the CA. For example, you can set a policy that requires all clients to go through a remote Registration Manager, and then have the remote Registration Manager route all client requests to the Certificate Manager located inside a firewall.

Root or Subordinate CA

CS can function as a root CA; in this case, the server signs its own CA signing certificate as well as other CA signing certificates, enabling you to create your own CA hierarchy. You can also install the server to function as a subordinate CA; in this case, the server gets its CA signing key signed by another CA in an existing CA hierarchy. See "Self-Signed Root vs. Subordinate CA," on page 78 for complete details.

Linked CA

CS can function as a linked CA, chaining up to many third-party or public CAs for validation; this provides cross-company trust, so applications can verify certificate chains outside the company certificate hierarchy. You chain a Certificate Manager to a third-party CA by requesting the Certificate Manager's CA signing certificate from the third-party CA.

CA Cloning

If you don't want to create a CA hierarchy comprising root and subordinate CAs, you can create multiple clones of a Certificate Manager and configure each clone to issue certificates that fall within a distinct range of serial numbers. Because clone CAs and original CAs use the same CA signing key and certificate to sign the certificates they issue, the issuer name in all the certificates will be the same. Clone CAs and the original Certificate Managers they are based on issue certificates as if they are a single CA, and can be placed on different hosts for high availability failover support. See "Cloning a CA," on page 127 for details. Also see Appendix , "" for information on configuring clones for failover in a CS system.

Interfaces

Each of the subsystems contains interfaces allowing interaction with various portions of the subsystem. All four subsystems share a common administrative interface. All four subsystems have an agent interface specific to that subsystem allowing agents to perform the tasks assigned to them. A Certificate Manager and a Registration Manager have an end-entity services interface allowing end-entities to enroll in the PKI.

Logging

CS produces extensive logs that record system events and errors. Logs are configurable, allowing you to create logs for specific types of events, and for the logging level you desire. See "Logs," on page 255 for complete details.

Supports Signing of Logs

CS allows you to sign log files digitally before archiving them or distributing them for audit purposes. This feature enables you to check whether the log files were tampered with after being signed. See "Signing Log Files," on page 266 for complete details.

Auditing

CS can be configured to produce signed audit logs that record auditable events from the subsystem. The audit log feature is configurable, allowing you to specify the events that are logged. An auditor user is assigned who is the only user who can view the audit logs. This user's certificate is used to sign and encrypt the logs. See "Signed Audit Log," on page 268 for complete details.

Self Tests

CS provides the framework for self-tests of the system that are automatically run at startup and can be run on demand. It ships with a set of self tests that are configurable and allows you to create additional self tests using the CS SDK. See "Self Tests," on page 272 for complete details.

Authorization

CS provides a new authorization framework that allows you to create groups and assign access control to those groups. You can also change the default access control for prebuilt groups, and assign access control to individual users and IP addresses. Access points for authorization have been created for the major portions of the system allowing you to set access control rules for each of these. You can also create additional access points and additional access control lists using the CS SDK. See Chapter 9, "Authorization" for complete details.

Authentication

CS provides authentication options for certificate enrollment including agent-approved enrollment in which an agent processes the request, and several automated enrollments, in which an authentication method is used, and upon successful authentication of the end-entity, the CA automatically issues a certificate. CMC enrollment is also supported allowing a request signed by an agent to be automatically processed. A set of prebuilt authentication plug-ins are available to enable and configure. You can create additional Authentication plug-in modules using the CS SDK. See Chapter 10, "Authentication" for complete details.

Certificate Issuance

CS supports the enrollment and certificate issuance to a wide variety of end-entities. It can process certificate requests from various end entities, such as web browsers, servers, routers, and virtual private network (VPN) clients, and issue certificates that conform to X.509 version 3 standard.

The Certificate Manager can issue certificates with the following characteristics:

Certificate Profiles

CS has a new feature called certificate profiles. Certificate Profiles allow you to create a single certificate profile associated with the issuance of a particular type of certificate by configuring the content of the certificate, the constraints put on the issuance of this certificate, the enrollment method used, and the input and output forms associated with this enrollment.

A set of certificate profiles are included for the most common certificate types. You can use these certificate profiles and configure their settings to suit your needs. Certificate Profiles are configured by an administrator, and then sent to the Agent Services Interface for agent approval. Once a certificate profile is approved, it is enabled for use. A dynamically generated HTML form for the certificate profile is used in the end-entity interface for enrollment which triggers this certificate profile. The server will verify that the defaults and constraints set in the certificate profile are met before acting on the request, and will use the certificate profile to determine the content of the issued certificate. You can create additional Certificate Profile plug-in modules using the CS SDK. See Chapter 11, "Certificate Profiles" for complete details.

Policy

The policy feature of CS allows you to set policies about certificate issuance, renewal, and revocation. You set policies that either define what is possible, for example the possible values of for the expiration date, and extensions that are used in a particular type of certificate. A set of prebuilt policies is available for you to enable and configure. You can create additional Policy plug-in modules using the CS SDK. See Chapter 12, "Policies" for complete details.

CRLs

CS is capable of creating certificate revocation lists. This configurable framework allows you to define issuing points so a CRL can be created for each issuing point defined. You can issue CRLs for each type of certificate you issue, or for a specific subset of a type of certificate you issue. You can also configure the extensions used in the CRLs, and set up the frequency and intervals that CRLs are published. Delta CRLs can also be created for any issuing point that is defined.

The Certificate Manager can issue X.509 v1 or v2 CRLs. A CRL can be automatically updated whenever a certificate is revoked or at specified intervals. See Chapter 15, "Revocation and CRLs" for complete details.

Publishing

The publishing feature allows you to publish certificates to files and an LDAP directory, and CRLs to files, LDAP directory, and an OCSP responder. The publishing framework provides a robust set of tools that allow you to publish to all three methods, and enables you to create rules that allow you to define a finer granularity of which types of certificates or CRLs are published where. You can enable and configure the default publishing modules, or you can create additional publishing plug-in modules using the CS SDK. See Chapter 16, "Publishing" for complete details.

Notifications

Notifications is a feature that allows you to set up automated messages when a particular event occurs, such as when a certificate is issued or revoked. The notification framework comes with default modules that you can enable and configure. You can create additional notification plug-in modules using the CS SDK. See Chapter 13, "Automated Notifications" for complete details.

Jobs

The Jobs feature allows you to set up automated jobs that run at defined intervals.The jobs framework comes with default jobs that you can enable and configure. You can create additional jobs plug-in modules using the CS SDK. See Chapter 14, "Automated Jobs" for complete details

Dual Key Pairs

CS supports certificate generation for dual key pairs-separate key pairs for signing and encrypting mail messages and other data. To support separate key pairs for signing and encrypting data, CS supports generation of dual certificates for end-entities capable of generating dual key pairs, and supports key archival for encryption keys. If a client makes a certificate request for dual key pairs, the server issues two separate certificates. This feature is only supported for Netscape 7.0 and later browsers.

HSMs and Crypto Accelerators

CS supports Hardware Security Modules and crypto accelerators provided by various third-party vendors of PKCS #11 version 2.01-compliant products.

You can configure the server to use different PKCS #11 modules to generate and store key pairs (and certificates) for the Certificate Manager, Registration Manager, and Data Recovery Manager. Note that PKCS#11 hardware devices also provide key backup and recovery features for backup and recovery of the key material stored on the hardware token. Be sure to refer to the PKCS #11 vendor documentation on this subject.

Support for Open Standards

With its support for open standards, CS gives organizations confidence that they will be able to communicate within a heterogeneous computing environment. CS supports standards in the following ways:

Java SDK Extension Mechanism for Customization

The software development kit (SDK) provided with CS includes APIs and tutorials for customizing different aspects of the system. You can write the following custom modules:

How Certificate System Works

CS allows you to manage certificates by providing a flexible, scalable system for issuing, renewing, and publishing certificates; creating and publishing CRLs; and providing key storage and retrieval capabilities.

CS Basics

CS is installed on each host running a CS subsystem. The subsystems that will be run on that host are then installed with a default configuration. The default configuration includes basic administrative tasks like logging, and also contains configurable plug-in modules that are specific to each subsystem. You can set up more than one subsystem on each host, or multiple instances of a subsystem on the same host or on different hosts.

Subsystems

Interfaces

Logs

Each subsystem produces extensive system and error logs that record various events and system errors so that you can monitor and debug the system. All log records are stored in your local file system for quick and easy retrieval.

CS allows you to sign log files digitally before archiving them or distributing them for audit purposes. This feature enables you to check whether the log files were tampered with after being signed.

The log feature is configurable, allowing you to select logging levels as well as what is logged. You can also create custom logs so that events can be separated by the categories you choose. See "Logs," on page 255 for complete details.

Auditing

CS maintains audit trails for all events-certificate requests and issuance, revocation requests, CRL publication, and so on. These audit records enable you to detect any unauthorized access or activity.

CS allows you to set up special users called Auditors who have exclusive access to these logs, allowing independent auditing of your PKI.

You can customize audit logs to include the information you want to include in the audit log. See "Signed Audit Log," on page 268 for complete details.

Internal Database

Each subsystem has its own internal database where it stores such things as issued certificates, certificate requests, and so on. The internal database is an instance of Netscape Directory Server that is used exclusively as the internal database for this subsystem. See "The Internal Database," on page 281 for complete details.

Authorization

CS is preconfigured with four types of users who have various access to the system:

CS allows you to create users, and assign them the privileges of whichever group in which they are members. A user only has privileges for the instance of the subsystem in which the user is created and the privileges of the group in which the user is a member.

A configurable plug-in framework is provided to tailor authorization in your deployment. You can change the default privileges of the groups that are preconfigured by changing ACLs associated with those groups. You can create new groups, assigning privileges to the group by adding them to ACLs defining permissions. For example, you might create a special kind of administrator who is able to run the basic operations of the subsystem, but is not able to configure any of the features. See Chapter 9, "Authorization" for complete details.

Self Tests

CS contains a new feature called Self Tests that performs certain tests of the system that happen at startup and can also be manual started in the CS console. The tests then report results of the tests that you can view. You can configure which test you want to run, and create customized tests. See "Self Tests," on page 272 for complete details.

Notifications

Notifications is a feature that allows you to set up automated messages when a particular event occurs, such as when a certificate is issued, or revoked. See Chapter 13, "Automated Notifications" for complete details.

Jobs

The Jobs feature allows you to set up automated jobs that run at defined intervals. See Chapter 14, "Automated Jobs" for complete details.

About the Certificate Manager

The Certificate Manager subsystem provides the capability of a Certificate Authority. It can issue, renew, revoke, and publish certificates as well as compiling and publishing CRLs.

The Certificate Manager acts as a Certificate Authority (CA). It can be configured as a self-signing CA, where it is the root CA, or it can act as a subordinate CA, where it obtains its own signing certificate from a public CA.

Scalability

You can configure more than one CA either forming a vertical or horizontal chain of CAs. For example, you can create a root CA for your deployment that is either self-signing or subordinate to a public CA and then have one or more CAs below this root CA. Those CAs can have further CAs below them forming a chain of CA's. You can also clone a CA so that two CAs are set up in an identical manner and use the same CA signing Certificate, but each uses a different set of serial numbers for the certificates it issues.

Federal Bridge Certificate Authority

CS also allows you to create a trusted relationship between two separate CAs by issuing and storing cross-signed certificates between these two CAs. This feature of the PKI is called Federal Bridge Certificate Authority (FBCA). This feature allows you to trust certificates issued by a CA outside of your PKI that shares a cross-signed certificate with the CA in your PKI.

Certificate Manager Functionality

The Certificate Manager issues, renews, and revokes certificates when it receives signed requests from either its own agents (user's who are assigned privileges to approve enrollment, renewal, and revocation requests), from a trusted Registration Manager, or from a third-party application that sends a signed request using its agent certificate that is set up for CMC enroll or revoke with the Certificate Manager.

The Certificate Manager also compiles lists of revoked certificates, called Certificate Revocation Lists (CRLs) that it can publish to files, an LDAP directory, or an OCSP service.

The Certificate Manager maintains a database of issued certificates, and of processed requests, so that it can track renewal, expiration, and revocation.

Types of Certificates That are Managed

CS can issue and manage certificates for Certificate Authority signing certificates, cross-signed pair certificates (FBCA), SSL server certificates, router certificates, VPN client certificates, and end user certificates.

Revocation and CRLs

CS provides the framework for revoking certificates which can either be initiated by an agent or by the end user themselves. An administrator can also revoke the certificates of any of the subsystems or agents.

CS also support CMC Revocation. When the CMCAuth plug-in is enabled, CMC enrollment and CMC revocation are both enabled. CMC Revocation allows you to send signed revocation requests that are automatically processed.

CS is capable of producing Certificate Revocation Lists (CRLs) that it can publish either to files, an LDAP directory, or to an OCSP responder.

You can also set up CRLs by Certificate Issuing Points allowing you to create more than one CRL defined by the issuing point. For example, you can issue a CRL for just CA Signing certificates, or separate CRLs for California and Florida end user certificates.

Delta CRLs can also be produced allowing you to create CRLs that contain only the revoked certificates since the last CRL was produced.

How the Certificate Manager Works

This sections details the processes that a Certificate Manager goes through, and the various configuration settings involved in those processes.

Accepting Enrollment Requests

The Certificate Manager contains an end-entity interface with various forms associated with various types of certificates and various types of users. This interface is customizable allowing you to only show the forms that are pertinent to your users, change the look and feel of the pages, or add and delete fields for your particular needs. Certificate requests that come through the Certificate Managers end-entity interface are processed by the Certificate Manager. If it is an agent-approved enrollment, an agent of the Certificate Manager must approve the request. If it is an automated enrollment, the request is considered approved if the end-entity supplies the correct information, and authenticates against the authentication method set up. See the Red Hat Certificate System Customization Guide for information about customizing the end-entity interface.

Authentication Methods

CS provides authentication plug-ins that allow you to set up automated enrollment and configure the particular method(s) you set up; it provides agent-approved enrollment, where an agent must approve the request by default. Each end-entity form is associated with a particular authentication method, either one of the automated methods or the agent-approved method. The Certificate Manager processes the request according to the method associated with the form. See Chapter 10, "Authentication" for complete details.

Request Processing

When the Certificate Manager processes requests from its own end-entity interface, it first considers the authentication method. If it is an agent-approved authentication method, the request is queued in the agent services interface where it awaits agent approval. The agent can change some aspects of the certificate that will be issued, and can approve, deny, or change the status of the request. If it is an automated enrollment, it authenticates the user, and then continues processing the request.

The Certificate Manager next evaluates the request to ensure that it meets either the policies set for this type of certificate, or the certificate profile set for this type of enrollment.

Policies are a set of plug-ins that allow you to set constraints on the certificate and define the content and the value of that content in the certificate. You can configure the default policies and associate them with a particular authentication method. You can also create custom policy modules. See Chapter 12, "Policies" for complete details.

Certificate Profiles is a new feature that binds an authentication method and certificate type to a set of constraints and certificate content definitions (defaults). It allows you to configure a single module for a type of certificate that binds to an authentication method and sets constraints for the certificate issued as well as defines the content and values for that content in the certificate. You can configure the default certificate profiles or create custom modules. See Chapter 11, "Certificate Profiles" for complete details.

If the policies from either the Policy or the Certificate Profiles framework are not met, the request is rejected, if they are met, the certificate is issued.

Certificate Creation

The Certificate Manager issues certificates when it receives signed requests from either its own agents (user's who are assigned privileges to approve enrollment, renewal, and revocation requests), from a trusted Registration Manager, or from a third-party application that sends a signed request that is set up for CMC enroll with the Certificate Manager.

The Certificate Manager creates the certificate using the information in the request and from the policies or certificate profile that are set up that match this kind of request.

Publishing of Certificates

Certificates can be published to a file, an LDAP directory, or OCSP responder. You set up the publishing feature and set up rules that determine which certificates are published using which method, and where exactly they are published. The publishing system is flexible allowing you many options in configuring it. If publishing is set up, a certificate is published to the correct location(s) whenever a certificate is issued. See Chapter 16, "Publishing" for complete details.

Key Archival

If you install a Data Recovery Manager, the private key is requested as part of enrollment and stored in the Data Recover Manager. See Chapter 6, "Data Recovery Manager" for complete details.

Storing Certificate Requests and Certificates

When it issues a certificate, the Certificate Manager stores both the certificate and the certificate request in its internal database.

Renewing Certificates

A Certificate Manager allows end-entities to renew certificates if the policies are set up to allow for renewal. If so, the end-entity submits a renewal request in the end-entity interface, and provides the end-entities' old certificate. The Certificate Manager will then issue a new certificate according to the policies set.

Revoking Certificates

End-entities can submit certificate revocation requests in the end-entity interface. They might do this if they lose their private key, or if their certificate has been otherwise compromised. When an end-entity requests a revocation, the request is sent to the agent services interface for agent approval.

An agent can also revoke a certificate if the owner of the certificate is unwilling or unable to do so.

When the certificate is revoked, it is marked revoked in the internal database, and is marked revoked in the publishing system. The certificate is also added to the Certificate Revocation List (CRL) produced by the Certificate Manager. See Chapter 15, "Revocation and CRLs" for complete details.

CRLs

Whenever a certificate is revoked, any CRLs that are set up are edited and updated in the internal database. It is also published to a file, an LDAP directory, or an OSCP responder, if you have set up these services. You can configure the Certificate Manager to issue CRLs, and also define CRL Issuing Points that define which certificates go into each CRL, such as CA signing certificates, or for a subset of a type of certificates, such as those certificates issued to west coast employees.

The publishing framework allows you the flexibility to define which CRL is published where. It also allows you to define the extensions contained in a CRL, and the frequency and intervals when a CRL are published.

You can also provide delta CRLs allowing you to publish a list of only those certificates have been revoked since a certain date.

About the Registration Manager

The Registration Manager is an optional subsystem of CS that can act as a Registration Authority (RA). It establishes a trusted relationship with a Certificate Manager in which its signed requests are processed. The Registration Manager is able to accept enrollment, renewal, and revocation requests; process those requests either by agents or through an automated means; provide agent initiated requests for enrollment, renewal, and revocation; send signed requests to a Certificate Manager, and disburse certificates that are created by the Certificate Manager. You can set up a Registration Manager outside a firewall to protect a Certificate Manager behind a firewall, or you can use a Registration Manager to balance the incoming load for a Certificate Manager by off loading the enrollment and approval to one or more Registration Manager.

The Registration Manager cannot issue, renew, or revoke certificate, and does not compile CRLs. It can publish certificates, but it cannot publish CRLs.

It can, however, be configured for authentication, authorization, certificate profiles, policies in an almost identical manner as a Certificate Manager.

How the Registration Manager Works

This sections details the processes that a Registration Manager goes through, and the various configuration settings involved in those processes.

Accepting Enrollment Requests

Similar to the Certificate Manager, the Registration Manager contains an end-entity interface with various forms associated with various types of certificates and various types of users. This interface is fully customizable allowing you to only show the forms that are pertinent to your users, change the look and feel of the forms, or add and delete fields. Certificate requests that come through the Registration Managers end-entity interface are processed by the Registration Manager. If it is an agent-approved enrollment, an agent of the Registration Manager must approve the request. If it is an automated enrollment, the request is considered approved if the end entity supplies the correct information, and authenticates against the authentication method set up. See the Red Hat Certificate System Customization Guide for details about customizing the end-entity interface.

Authentication Methods

CS provides authentication plug-ins that allow you to set up automated enrollment and set configuration settings for that method(s); it provides agent-approved enrollment, where an agent must approve the request by default. The Registration Manager also provides an in-person registration method where an end user appears in person to request the certificate, and the agent enters and approves the request-note that the Certificate Manager does not support in person registration by agents. Each end-entity form is associated with a particular authentication method, either one of the automated methods or the agent-approved method. The Registration Manager processes the request according to the method associated with the form. See Chapter 10, "Authentication" for complete details.

The Registration Manager is in complete control of the authentication of users. No matter how the Certificate Manager is set up for authentication, the Certificate Manager will accept a request sent by the Registration Manager and not apply any authentication of its own.

Request Processing

When the Registration Manager processes requests from its own end-entity interface, it first considers the authentication method. If it is an agent-approved enrollment method, the request is queued in the agent services interface where it awaits agent approval. The agent can change some aspects of the certificate that will be issued, and can approve or deny the request. If it is an automated enrollment, the Registration Manager authenticates the user, and then continues processing the request.

The Registration Manager next evaluates the request to ensure that it meets either the policies set for this type of certificate, or the certificate profile set for this type of enrollment.

Policies are a set of plug-ins that allow you to set constraints on the certificate and define content and values for that content in the certificate. You can configure the default policies and associate them with a particular certificate type. You can also create custom policy modules. See Chapter 12, "Policies" for complete details.

Certificate Profiles are a new feature that bind an authentication method and certificate type to a set of constraints and certificate content and values for that content. It allows you to configure a single module for a type of certificate that binds to an authentication method and sets constraints for the certificate issued as well as defines the content and values for that content in the certificate. You can configure the default certificate profiles or create custom modules. See Chapter 11, "Certificate Profiles" for complete details.

If the constraints from either the Policy or the Certificate Profiles framework are not met, the request is rejected, if they are met, the certificate is issued.

Certificate Creation

Approved, signed certificate requests are sent to the Certificate Manager in which a trusted relationship has been established.

The request is next evaluated by the policies or certificate profiles of the Certificate Manager. The request must meet the constraints set by the Certificate Managers in order for a certificate to be issued. For example, the Registration Manager may allow for this type of certificate to be issued with validity period of one year. If the Certificate Manager has a policy set up the constrains this type of certificates to a validity period of six months, the certificate will not be issued.

The Certificate Manager creates the certificate and returns it to the Registration Manager.

Publishing of Certificates

Certificates can be published to a file or an LDAP directory. You set up the publishing feature and set up rules that determine which certificates are published using which method, and where exactly they are published. The publishing system is flexible allowing you many options in configuring it.

The Registration Manager publishes only those certificates that it processes. You can set up publishing in a Registration Manager in order to publish a subset of the certificates issued by a Certificate Manager. A Registration Manager does not publish CRLs. If you set up publishing in both the Certificate Manager and the Registration Manager, certificates will be published to the locations specified and according to the rules specified in both, the publishing systems of each are totally separate, they do not work in tandem. See Chapter 16, "Publishing" for complete details.

Key Archival

If you install a Data Recovery Manager, the private key is requested as part of the enrollment and stored in the Data Recover Manager. See Chapter 6, "Data Recovery Manager" for complete details.

Storing Certificate Requests and Certificates

When it issues a certificate, the Certificate Manager stores both the certificate and the certificate request in it internal database. See "The Internal Database," on page 281 for complete details.

Renewing Certificates

A Registration Manager allows end-entities to renew certificates if the policies are set up to allow for renewal. If so, the end-entity submits a renewal request in the end-entity interface, and provides their old certificate. The Certificate Manager that has a trusted relationship with this Registration Manager will then issue a new certificate according to the policies set. Note, the Certificate Manager must also be set up to allow for renewal of certificates and the policies set for renewed certificates in the Certificate Manager will also be evaluated when the request is processed.

Revoking Certificates

An end-entity can submit a certificate revocation request in the end-entity interface. They might do this if they lose their private key, or if their certificate has been otherwise compromised. When an end-entity requests a revocation, the request is sent to the agent services interface for agent approval.

An agent can also revoke a certificate. They might do this if someone leaves the company.

Data Recovery Manager

The Data Recovery Manager is an optional subsystem of CS that can act as a Key Recovery Authority. When configured in conjuncture with a Certificate Manager or Registration Manager, the Data Recover Manager stores private encryption keys as part of the certificate enrollment process. The key archival mechanism is triggered when a user enrolls in the PKI and creates the certificate request. Using the CRMF request format, the request generates a request for the users private encryption key. The key is then stored in the Data Recovery Manager. The Data Recovery Manager is configured to store keys in an encrypted format that can only be decrypted by several agents requesting the key at one time, providing for protection of the public encryption keys for the users in your deployment.

Note that the Data Recovery Manager archives encryption keys. It does not archive signing keys, since such archival would undermine nonrepudiation properties of signing keys.

Key Archival

If you have set up a Data Recovery Manager as part of your PKI, the private encryption key for an end-entity is requested and stored when the enrollment request is made.

Key Retrieval

If you have set up a Data Recovery Manager up as part of your PKI, you can retrieve the private encryption keys of your users to decrypt messages or other documents that have been encrypted with the private encryption key. CS provides a key retrieval system that can only be activated by several agents approving the key retrieval at the same time to offer maximum security of the stored keys.

Online Certificate Status Manager

The Online Certificate Status Manager is an optional subsystem of CS that can act as a stand-alone OCSP service. The Certificate Manager is configured with an internal OCSP service. An external OCSP Responder is offered as a separate subsystem in case you want the OCSP service provided outside a firewall while the Certificate Manager resides inside a firewall, or to take the load of requests off the Certificate Manager.

The Online Certificate Status Manager performs the task of an online certificate validation authority, by enabling OCSP-compliant clients to do real-time verification of certificates. Note that an online certificate-validation authority is often referred to as an OCSP responder. The Online Certificate Status Manager can receive CRLs from multiple Certificate Managers and clients can query the Online Certificate Status Manager for the revocation status of certificates issued by all these Certificate Managers.

When an OCSP Responder is set up with a Certificate Manager, and publishing is set up to the OCSP responder, CRLs are published to it when they are issued or updated.

Deployment Scenarios

Single Certificate Manager

Some deployments may require only a single Certificate Manager that handles all end-entity interactions and provides no key archival and recovery capabilities. This Certificate Manager can use a signing certificate issued by a public certificate authority or its own self-signed CA signing certificate to sign all the certificates it issues.

Figure 1-1 Single root Certificate Manager

Figure 1-1 shows the relationships among a single Certificate Manager, end entities, and a publishing directory. The Certificate Manager can publish both end-entity certificates and CRLs to a directory.

Certificate Manager and Registration Manager

Figure 1-2 shows a Registration Manager and its Certificate Manager in separate instances on separate machines. All communication between the Certificate Manager and the Registration Manager takes place over HTTPS.

Figure 1-2 Certificate Manager and Registration Manager in different instances

Many organizations need to separate the role of the Registration Manager from the role of the Certificate Manager. This separation can be useful, for example, if different groups of end entities are subject to different authentication policies or work in different geographic locations.

Each group of end entities interacts with a designated Registration Manager that processes requests from end entities and sends them to a Certificate Manager. The Certificate Manager can accept requests from both end entities and Registration Managers. For example, end entities at the home office might deal directly with the Certificate Manager, while end entities at a branch office might deal with their own Registration Manager. Alternatively, the Certificate Manager might be configured to accept requests only from Registration Managers, thus shielding the CA from end entities.

A Registration Manager can be installed in one CS instance and its related Certificate Manager in another CS instance. The separate instances can be located in the same server group, in different server groups on the same machine, or in different server groups on different machines.

In many organizations, it may be desirable to deploy multiple Registration Managers that all communicate with a single Certificate Manager. Each separate Registration Manager, for example, might handle all end-entity interactions in a particular geographic area or within an organizational group.

Decisions about the number of, locations of, and relationships among Certificate Managers and Registration Managers depend on many factors. These include firewall considerations, the physical security required for each subsystem, the physical location of the end entities that the Registration Manager is intended to serve, and the physical location of the Certificate Manager agent, Registration Manager agent, and other persons responsible for administering the Certificate Manager and Registration Manager.

Certificate Manager and Data Recovery Manager

If an organization requires key archival and recovery capabilities-for example, if encrypted mail is widely used and the organization risks data loss if it is unable to recover encryption keys-it can install a Data Recovery Manager. This can be done without regard for the presence or absence of a separate Registration Manager.

For example, to add key storage and recovery to the scenario sketched in Figure 1-2, a Data Recovery Manager can be installed in a different CS instance; this instance can be located in the same server group on the same machine, in a different server group on the same machine, or on a different machine. Figure 1-3 illustrates a Data Recovery Manager in a separate CS instance. All communication between the Certificate Manager and the Data Recovery Manager takes place over HTTPS.

Figure 1-3 Certificate Manager and Data Recovery Manager in different instances

The Data Recovery Manager is intended for archival and recovery of private encryption keys only. Therefore end entities must be using either a browser that supports dual-key generation or a browser that is using Red Hat Personal Security Manager, which supports dual keys. When determining the location of a Data Recovery Manager, be sure to look into firewall considerations, the physical security required for each subsystem, and the physical location of the Certificate Manager agent, Data Recovery Manager agent, and other persons responsible for administering the Certificate Manager and recovering keys.

Like a Certificate Manager, a Data Recovery Manager has special physical security requirements, since a compromised Data Recovery Manager would have devastating security consequences for your entire PKI. You may therefore want to keep the Data Recovery Manager in a special locked room or building, a choice that can affect your deployment strategy.

Certificate Manager, Data Recovery Manager, and Registration Manager

The three CS subsystems can be deployed in many different relationships. Figure 1-4 illustrates some of the issues involved in deploying all three subsystems by showing the relationships among a single Certificate Manager, a single Registration Manager, and a single Data Recovery Manager, each installed in a different CS instance on a different machine.

Figure 1-4 Certificate Manager, Registration Manager, and Data Recovery Manager in separate instances

The Registration Manager handles all end-entity interactions and communicates with the Certificate Manager and the Data Recovery Manager over HTTPS. The Registration Manager is configured to request the end entity's private encryption key (in encrypted form) and send it to the Data Recovery Manager during the enrollment process. Before the Registration Manager sends the certificate request to the Certificate Manager for processing, the Registration Manager must receive verification from the Data Recovery Manager that the private key has been received and stored and that it corresponds to the end entity's public key.

Only the Certificate Manager can be configured to enable or disable LDAP publishing or to publish to separate directories. The Certificate Manager also has the complete record of issued certificates, so that it can perform the publishing tasks, as shown in the figure.

Many other combinations are possible. For example, there might be multiple Registration Managers in different instances, all dealing with the same Data Recovery Manager and Certificate Manager; or the Certificate Manager might also handle some end-entity interactions. It's also possible to set up both Certificate Managers and Registration Managers such that each has a hierarchy of subordinate managers.


Note	The current design of Certificate System assumes that most deployments will rely on a single Data Recovery Manager (associated with either a Registration Manager or a Certificate Manager). However, it is also possible to write custom policies that support multiple Data Recovery Managers. This might be useful, for example, for subordinate CAs that issue certificates for completely independent organizations.

Cloned Certificate Manager

A cloned Certificate Manager is a CS server instance that uses the same CA signing key and certificate as another Certificate Manager, identified as the master Certificate Manager. Each Certificate Manager issues certificates with serial numbers in a restricted range so that all of the servers together act as a single Certificate Authority (operating in several server processes).

The advantage of cloning is the ability to distribute the Certificate Manager's load across several processes or even several physical machines. For a CA that has high enrollment demand, the distribution gained from cloning allows more certificates to be signed and issued in a given time interval.

To create a cloned Certificate Manager, you must first install and configure at least one Certificate Manager and specify a definite upper, but no lower bound for the serial numbers it will use. You then install or create a new instance of a Certificate Manager (but do not configure it). Before configuring the clone, you copy the CS certificate and key database files from the original Certificate Manager to the new Certificate Manager (<server_root>/alias directory). If these databases are present, the Configuration Wizard will recognize that you are creating a clone and confirm that you want to reuse the CA's signing key and certificate (if the clone is on the same server, you can also reuse the SSL server certificate).

If you store the CA key material on a hardware token, you will have to follow the hardware vendor's instructions for copying the key material to a hardware device accessible to the clone.

A cloned Certificate Manager will have all the same features, for example, agent gateway functions and end entity gateway functions, that a normal Certificate Manager has. You can then configure Registration Managers that point to different Certificate Manager servers but that appear to be serviced by the same CA.

System Architecture

This section describes the architecture of CS. Figure 1-5 on page 56 shows a graphical representation of that architecture.

Figure 1-5 CS Architecture

CS Component

The CS component is the main component in the CS product. CS is a set of pure Java classes. This component provides a secure application platform where subsystems (CA, RA, DRM, and OCSP) can be tightly integrated with a PKI infrastructure. Depending on the installation configuration selection, CS can be easily installed as a CA, RA, DRM, or OCSP Responder, where subsystem-specific HTTP servlets are registered at startup to provide subsystem-specific services.

Within the CS component, a set of common modules (all can be extended with customized JAVA plug-ins) are provided for all subsystems (although some may not be utilized by default setting, they are all available for further customization):

HTTP Engine

CS employs the Red Hat Enterprise Server as its HTTP engine. It provides the entry point for users/applications of all types to access CS's functions. As discussed in the System Overview, CS provides three types of entry points, each serving one or more interfaces:

Service Interfaces

Each of the subsystems contains interfaces allowing interaction with various portions of the subsystem. All four subsystems share a common administrative interface. All four subsystems have an agent interface that allows for agents to perform the tasks assigned to them. A CA Subsystem and an RA Subsystem have an end-entity services interface allowing end entities to enroll in the PKI. An OCSP responder subsystem has an end-entity services interface allowing end entities and applications to check for current certificate revocation status

While the HTTP Engine provides the connection entry points, CS completes the interfaces by providing the servlets specific to each interface.

End-Entity Services Interface

For the CA subsystem and RA subsystem, the end-entity interface provide JAVA servlets to process HTML form submissions coming from the end-entity entry point. Based on the information received from the form submissions, the end-entity servlets allow end entities to enroll, renew certificates, revoke their own certificates, and pick up issued certificates. The OCSP responder subsystem's end-entity interface provides JAVA servlets to accept and process OCSP requests. The DRM subsystem does not offer any end-entity service.

Agent Services Interface

The agent services interface provides JAVA servlets to process HTML form submissions coming from the agent entry-point. Based on the information given in each form submission, the agent servlets allow agents to perform agent tasks, such as editing and approving requests for certificate approval, certificate renewal, and certificate revocation, and approving certificate profiles. The agent services interface is almost identical for a CA Subsystem and a RA subsystem. The agent services interfaces for a DRM subsystem or an OCSP Responder are specific to the subsystems.

The agent services interface is also used for inter-CIMC_Boundary communication for RA-to-CA and CA-to-DRM trusted connection. These connections are protected by SSL client-authentication, and differentiated by separate trusted roles called Trusted Managers. Like the agent role, the Trusted Managers (pseudo-users created for inter-CIMC_Boundary connection only) are required to be SSL client-authenticated, however, unlike the agent role, they are not offered any agent capability.

Administrative Interface

The administrative interface provides JAVA servlets to process commands coming from the administrative entry-point. Based on the information given at each command, the administration servlets allow administrators to perform administrative tasks and configure plug-in modules and instances of plug-in modules. This interface is similar for all four subsystem. It contains some common configuration types, but also contains different plug-in types that can be configured depending on the kind of subsystem configured. The auditor shares the same interface with the administrator, with the restriction to view all configurations and logs (including audit logs); while administrators are restricted from viewing the audit logs. During setup, the administrator will be directed to configure this interface to accept only SSL client authentication

JSS and the Java/JNI Layer

Java Security Services (JSS) provides a Java interface for security operations performed by NSS. JSS and higher levels of the CS architecture are built with the Java Native Interface (JNI), which provides binary compatibility across different versions of the Java Virtual Machine (JVM). This design allows customized subsystem services to be compiled and built just once and run on a range of platforms. JSS supports most of the security standards and encryption technologies supported by NSS. JSS also provides a pure Java interface for ASN.1 types and BER-DER encoding. JSS documentation can be found on-line at:

NSS

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled communications applications. Applications built with the NSS libraries support the SSL protocol for authentication, tamper detection, and encryption as well as the PKCS #11 interface for cryptographic token interfaces. Red Hat uses NSS to support these features in a wide range of products, including CS. NSS documentation can be found on-line at:

PKCS #11

Public-Key Cryptography Standard (PKCS) #11 specifies an API used to communicate with devices that hold cryptographic information and perform cryptographic operations. Because it supports PKCS #11, CS works with a wide range of hardware and software devices intended for such purposes.

One or more PKCS #11 modules must be available to any CS subsystem instance. As shown in the figure, a PKCS #11 module (also called a cryptographic module or cryptographic service provider) manages cryptographic services such as encryption and decryption via the PKCS #11 interface. PKCS #11 modules can be thought of as drivers for cryptographic devices that can be implemented in either hardware or software. Red Hat provides a built-in PKCS #11 module with CS.

A PKCS #11 module always has one or more slots, which can be implemented as physical hardware slots in some form of physical reader (for example, for smart cards) or as conceptual slots in software. Each slot for a PKCS #11 module can in turn contain a token, which is the hardware or software device that actually provides cryptographic services and optionally stores certificates and keys.

Any PKCS #11 module can be used with CS. The server uses a file called secmod.db to keep track of the modules that are available. You can modify this file using the modutil tool, which is explained in the following documentation:

For example, you need to modify secmod.db if you are installing hardware accelerators for use in signing operations.

Management Tools

Command line tools are provided by CS for occasional management of the CS system:

JRE

JRE (Java Runtime Environment) provides the Java Virtual Machine (JVM) and supporting class libraries needed to run CS.

Internal LDAP Database

CS employs Red Hat Directory Server as its internal database for storing information such as certificates, requests, users, roles, ACLs, as well as other miscellaneous internal information. CS communicates with the internal LDAP database securely by means of SSL client authentication.

Administration Server

The Red Hat Administration Server comes with all Red Hat directory and certificate server products, including CS. Together with the Red Hat Console and the configuration LDAP database (another instance of Red Hat Directory Server), it is used for managing Red Hat software and users in an enterprise environment. The configuration LDAP database stores server and application configuration settings as well as user information. This data is used by other servers in the enterprise. Typically, application and server configuration information is stored in one subtree of the configuration LDAP database while user and group entries are stored in another subtree. Except for the creation of a new CS instances, functionalities provided by this component are not fully utilized by CS. Note that although this configuration LDAP database can be used to store Enterprise user records, or configured as a certificate publishing destination, or configured to provide directory-based enrollment authentication mechanism, it is separate from the CS Internal LDAP database, and unlike the CS Internal LDAP database, it is not considered as part of the core CS system.

CS SDK

The CS Software Development Kit (SDK) includes information that is useful for developing new plug-in modules and for customizing various aspects of CS.

Support for Open Standards

This section summarizes the standard message formats and protocols supported by CS.

Certificate Management Formats and Protocols

CS supports the following certificate management formats and protocols. For more details about the proposed PKIX standards listed here, see http://www.ietf.org/html.charters/pkix-charter.html (under Internet Drafts).