The Certificate System is installed on each host running a Certificate System subsystem. The subsystems on that host are then installed with a default configuration covering basic administrative tasks like logging and containing configurable, subsystem-specific plug-in modules. More than one subsystem can be installed on each host, or multiple instances of one subsystem can be installed on the same host or on different hosts.

The Certificate System has five highly-configurable subsystems, which provide flexibility in designing the PKI. The five subsystems that comprise Certificate System are as follows:

The subsystems are highly integrated with each other depending on the deployment scenario and use. OCSP and CA instances work together for CRL publishing and certificate verification. CA and DRM instances work together for key recovery and archival. Smart card tokens, which processed through a user interface called the Enterprise Security Client, are managed by the TPS. The TPS, however, is configured to work with at least two essential subsystem instances, a TKS to generate keys and a CA to process token operations. A TPS can also be configured to use a DRM for server-side key generation and key archival and recovery.

Each of the subsystems contains interfaces for interaction with various portions of the subsystem. The CA, DRM, OCSP, and TKS subsystems have an administrative console to manage and configure the subsystem itself, such as adding users and certificates and viewing logs. The CA, OCSP, DRM, and TPS subsystems have an agent interface specific to that subsystem which allows agents to perform the tasks assigned to them. A Certificate Manager has an end-entity services interface for end entities to enroll in the PKI.

The three types of interfaces are described as follows:

The Certificate System and each subsystem produce extensive system and error logs that record system events so that the systems can be monitored and debugged. All log records are stored in the local file system for quick retrieval. Logs are configurable, so logs can be created for specific types of events and at the desired logging level. Custom logs can be created See Section 3.9, “Logs” for details.

The Certificate System maintains audit logs for all events, such as requesting, issuing and revoking certificates and publishing CRLs. These logs are then signed. This allows authorized access or activity to be detected. An outside auditor can then audit the system if required. The assigned auditor user account is the only account which can view the signed audit logs. This user's certificate is used to sign and encrypt the logs. Audit logging is configured to specify the events that are logged. See Section 3.9.13, “Signed Audit Log” for details.

The Certificate System provides the framework for system self-tests that are automatically run at startup and can be run on demand. A set of configurable self-tests are already included with the Certificate System, and additional self-tests can be created through the CS SDK. See Section 3.10, “Self-Tests” for details.

Certificate System users can be assigned to groups, and they then have the privileges of whichever group 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 to which the user is a member.

The Certificate System provides an authorization framework for creating groups and assigning access control to those groups. The default access control on preexisting groups can be modified, and access control can be assigned to individual users and IP addresses. Access points for authorization have been created for the major portions of the system, and access control rules can be set for each point. Additional access points and access control lists (ACLs) can be created through the CS SDK.

The Certificate System is configured by default with four user types with different access levels to the system:

Additionally, when a security domain is created, the CA subsystem which hosts the domain is automatically granted the role of Security Domain Administrator, which gives the subsystem the ability to manage the security domain and the subsystem instances within it. Other security domain administrator roles can be created for the different subsystem instances. These roles are described in Section 4.4.2, “Security Domain Roles”.

Security-enhanced Linux, or SELinux, is a collection of mandatory access control rules which are enforced across a system to restrict unauthorized access and tampering. These mandatory access controls limit users and applications to the lowest amount of access possible for them to operate. Processes or applications, such as CGIs, may have special policies in place to enable them to run under the restricted access rules.

The Certificate System is able to run under SELinux configuration, which enhances the security of the information created and maintained by the Certificate System. All Certificate System subsystems can be installed and run with SELinux policies fully enforced. By default, the Certificate System subsystems run unconfined by SELinux policies.

Certificate System provides authentication options for certificate enrollment. These include agent-approved enrollment, in which an agent processes the request, and automated enrollment, in which an authentication method is used to authenticate the end entity and then the CA automatically issues a certificate. CMC enrollment is also supported, which automatically processes a request approved by an agent.

A Registration Authority (RA) is a subsystem that accepts enrollment requests and authenticates them in a local context (e.g., a department of an organization, or an organization within an association). Upon the successful authentication, the RA then forwards the enrollment request to the designated Certificate Authority (CA) to generate the certificate.

Depending on the type of enrollment, an RA can be set up with the appropriate authentication plugin to authenticate the request in an automated fashion. Alternatively, the RA has a local request queue where requests can be stored and reviewed by local RA agents for manual authentication.

SCEP (Simple Certificate Enrollment Protocol) is a protocol designed by Cisco. It is designed to specify a way for a router to communicate with an RA/CA for enrollment.

Normally, a router installer enters the RA's URL and a Challenge password (sometimes referred as a one-time PIN) into the router and issues a command to initiate the enrollment. The router then communicates with the RA using the SCEP protocol to:

SCEP suggests two modes of operation: RA mode; and CA mode. In the RA mode, the enrollment request is encrypted with the RA signing certificate. In the CA mode, the request is encrypted with the CA signing certificate.

The current implementation of RA and CA only supports the CA mode.

The Certificate System supports enrolling and issuing certificates and processing certificate requests from a variety of end entities, such as web browsers, servers, and virtual private network (VPN) clients. Issued certificates conform to X.509 version 3 standards.

The Certificate Manager can issue certificates with the following characteristics:

Additionally, smart cards can have certificates enrolled and maintained through the Enterprise Security Client. The Enterprise Security Client communicates directly with the TPS system, which, in turn, processes requests through the CA and DRM subsystems. Certificates are generated automatically when the token is first formatted, and all additional certificates belonging to the user can be imported onto the token. For more information about certificates being issued through the Enterprise Security Client, see the Certificate System Enterprise Security Client Guide, which is available at http://redhat.com/docs/manuals/cert-system/. For information about configuring subsystems to manage smart cards, see Chapter 7, Token Processing System.

The Certificate System uses certificate profiles to configure the content of the certificate, the constraints for issuing the certificate, the enrollment method used, and the input and output forms for that enrollment. A single certificate profile is associated with issuing a particular type of certificate.

A set of certificate profiles is included for the most common certificate types; the profile settings can be modified. Certificate profiles are configured by an administrator, and then sent to the agent services page 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-entities page for certificate enrollment, which calls on the certificate profile. The server verifies that the defaults and constraints set in the certificate profile are met before acting on the request and uses the certificate profile to determine the content of the issued certificate.

Additional certificate profile plug-in modules can be created using the CS SDK. See Chapter 12, Certificate Profiles for details.

The Certificate System can create certificate revocation lists (CRLs) from a configurable framework which allows user-defined issuing points so a CRL can be created for each issuing point. Delta CRLs can also be created for any issuing point that is defined. CRLs can be issued for each type of certificate or for a specific subset of a type of certificate. The extensions used and the frequency and intervals when CRLs are published can all be configured.

The Certificate Manager issues X.509-standard CRLs. A CRL can be automatically updated whenever a certificate is revoked or at specified intervals. See Chapter 13, Revocation and CRLs for details.

Certificates can be published to files and an LDAP directory, and CRLs to files, an LDAP directory, and an OCSP responder. The publishing framework provides a robust set of tools to publish to all three places and to set rules to define with more detail which types of certificates or CRLs are published where. The default publishing modules can be enabled and configured, or additional publishing plug-in modules can be created using the CS SDK. See Chapter 14, Publishing for details.

The notification feature sets 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 can be enabled and configured, or additional notification plug-in modules can be created using the CS SDK. See Chapter 18, Automated Notifications for details.

The jobs feature sets up automated jobs that run at defined intervals. The default jobs can be enabled and configured, or additional jobs plug-in modules can be created using the CS SDK. See Chapter 19, Automated Jobs for details.

The Certificate System supports generating dual key pairs, separate key pairs for signing and encrypting email messages and other data. To support separate key pairs for signing and encrypting data, dual certificates are generated for end entities, and the encryption keys are archived. If a client makes a certificate request for dual key pairs, the server issues two separate certificates.

The Certificate System supports hardware security modules (HSMs) and crypto accelerators provided by third-party vendors of PKCS #11-compliant tokens.

The server can be configured to use different PKCS #11 modules to generate and store key pairs (and certificates) for all Certificate System subsystems ‐ CA, DRM, OCSP, TKS, and TPS. PKCS #11 hardware devices also provide key backup and recovery features for the information stored on the hardware token. Refer to the PKCS #11 vendor documentation for information on retrieving keys from the tokens.

The Certificate System supports open standards and protocols so that its subsystems can communicate across a heterogeneous computing environment. Some of the standards and areas which the Certificate System supports include the following:

The Java™ software development kit (SDK) provided with the Certificate System includes APIs and tutorials for customizing different aspects of the system. The following modules can be customized and created: