This chapter describes the role of the privileged users, agents, in managing Certificate System subsystems. It also introduces the tools that agents use to administer service requests.
Certificate System is a highly configurable set of software components and tools for creating, deploying, and managing certificates. The standards and services that facilitate the use of public-key cryptography and X.509 version 3 certificates in a networked environment are collectively called the public-key infrastructure (PKI) for that environment. In any PKI, a certificate authority (CA) is a trusted entity that issues, renews, and revokes certificates. An end entity is a person, server, or other entity that uses a certificate to identify itself.
To participate in a PKI, an end entity must enroll, or register, in the system. The end entity typically initiates enrollment by giving the CA some form of identification and a newly generated public key. The CA uses the information provided to authenticate, or confirm, the identity, then issues the end entity a certificate that associates that identity with the public key and signs the certificate with the CA's own private signing key.
End entities and CAs may be in different geographic or organizational areas or in completely different organizations. CAs may include third parties that provide services through the Internet as well as the root CAs and subordinate CAs for individual organizations. Policies and certificate content may vary from one organization to another. End-entity enrollment for some certificates may require physical verification, such as an interview or notarized documents, while enrollment for others may be fully automated.
To meet the widest possible range of configuration requirements, the Certificate System permits independent installation of five separate subsystems, or managers, that play distinct roles:
-
Certificate Manager. A Certificate Manager functions as a root or subordinate CA. This subsystem issues, renews, and revokes certificates and generates certificate revocation lists (CRLs). It can publish certificates, files, and CRLs to an LDAP directory, to files, and to an Online Certificate Status Protocol (OCSP) responder. The Certificate Manager can process requests manually (with agent action) or automatically (based on customizable profiles). Publishing tasks can be performed by the Certificate Manager only. The Certificate Manager also has a built-in OCSP service, enabling OCSP-compliant clients to query the Certificate Manager directly about the revocation status of a certificate that it has issued. In certain PKI deployments, it might be convenient to use the Certificate Manager's built-in OCSP service, instead of an Online Certificate Status Manager.
Since CAs can delegate some responsibilities to subordinate CAs, a Certificate Manager might share its load among one or more levels of subordinate Certificate Managers. Additionally, subsystems can be cloned; the clone uses the same keys and certificates as the master, so, essentially, the master and clones all function as a single CA. Many complex deployment scenarios are possible.
-
Data Recovery Manager. A Data Recovery Manager (DRM) oversees the long-term archival and recovery of private encryption keys for end entities. A Certificate Manager or a Token Processing System (TPS) can be configured to archive end entities' private encryption keys with a DRM as part of the process of issuing new certificates.
The DRM is useful only if end entities are encrypting data, using applications such as S/MIME email, that the organization may need to recover someday. It can be used only with client software that supports dual key pairs - two separate key pairs, one for encryption and one for digital signatures. Also, it is possible to do server-side key generation using the TPS server when enrolling smart cards.
NOTE
The DRM archives encryption keys. It does not archive signing keys, since archiving signing keys would undermine the non-repudiation properties of dual-key certificates.
-
Online Certificate Status Manager. An Online Certificate Status Manager works as an online certificate validation authority and allows OCSP-compliant clients to verify certificates' current status. The Online Certificate Status Manager can receive CRLs from multiple Certificate Managers; clients then query the Online Certificate Status Manager for the revocation status of certificates issued by all the Certificate Managers. For example, in a PKI comprising multiple CAs (a root CA and many subordinate CAs), each CA can be configured to publish its CRL to the Online Certificate Status Manager, allowing all clients in the PKI deployment to verify the revocation status of a certificate by querying a single Online Certificate Status Manager.
NOTE
An online certificate-validation authority is often referred to as an OCSP responder.
-
Token Key Service. The Token Key Service (TKS) manages the master and transport keys required to generate and distribute keys for smart cards. The TKS provides security between tokens and the TPS because it protects the integrity of the master key and token keys.
-
Token Processing System. The Token Processing System (TPS) acts as a registration authority for authenticating and processing smart card enrollment requests, PIN reset requests, and formatting requests from the Enterprise Security Client.
Three kinds of users can access Certificate System subsystems: administrators, agents, and end entities. Administrators are responsible for the initial setup and ongoing maintenance of the subsystems. Administrators can designate users with special privileges, agents, for each subsystem. Agents manage day-to-day interactions with end entities, which can be users or servers and clients, and other aspects of the PKI. End entities must access a Certificate Manager subsystem to enroll for certificates in a PKI deployment and for certificate maintenance, such as renewal or revocation.
Figure 1.1, “The Certificate System and Users” shows the ports used by administrators, agents, and end entities. All agent and administrator interactions with Certificate System subsystems occur over HTTPS. End-entity interactions can take place over HTTP or HTTPS.
