There are three different interfaces for managing certificates and subsystems, depending on the user type: administrators, agents, and end users.
2.7.1. Administrative Consoles
The administrative interface is used to manage the subsystem itself. This includes adding users, configuring logs, managing profiles and plug-ins, and the internal database, among many other functions. This interface is also the only interface that does not directly deal with certificates, tokens, or keys, meaning it is not used for managing the PKI, only the servers.
There are two types of administrative consoles, Java-based and HTML-based. Although the interface is different, both are accessed using a server URL and the administrative port number.
184.108.40.206. The Java Administrative Console for CA, OCSP, KRA, and TKS Subsystems
The Java console is used by four subsystems: the CA, OCSP, KRA, and TKS. The console is accessed using a locally-installed
pkiconsole utility. It can access any subsystem because the command requires the host name, the subsystem's administrative SSL/TLS port, and the specific subsystem type.
Figure 2.5. Certificate System Console
The Configuration tab controls all of the setup for the subsystem, as the name implies. The choices available in this tab are different depending on which subsystem type the instance is; the CA has the most options since it has additional configuration for jobs, notifications, and certificate enrollment authentication.
All subsystems have four basic options:
tab shows the logs maintained by the subsystem.
220.127.116.11. The Administrative Interface for TPS
The TPS subsystems use HTML-based administrative interface. It is accessed by entering the host name and secure port as the URL, authenticating with the administrator's certificate, and clicking the appropriate Administrators link.
There is a single SSL/TLS port for TPS subsystems which is used for both administrator and agent services. Access to those services is restricted by certificate-based authentication.
The HTML admin interface is much more limited than the Java console; the primary administrative function is managing the subsystem users; all other administrative tasks are done by manually editing the
The TPS only allows operations to manage users for the TPS subsystem. However, the TPS admin page can also list tokens and display all activities (including normally-hidden administrative actions) performed on the TPS.
Figure 2.6. TPS Admin Page
The agent services pages are where almost all of the certificate and token management tasks are performed. These services are HTML-based, and agents authenticate to the site using a special agent certificate.
Figure 2.7. Certificate Manager's Agent Services Page
The operations vary depending on the subsystem:
The Certificate Manager agent services include approving certificate requests (which issues the certificates), revoking certificates, and publishing certificates and CRLs. All certificates issued by the CA can be managed through its agent services page.
The TPS agent services, like the CA agent services, manages all of the tokens which have been formatted and have had certificates issued to them through the TPS. Tokens can be enrolled, suspended, and deleted by agents. Two other roles (operator and admin) can view tokens in web services pages, but cannot perform any actions on the tokens.
KRA agent services pages process key recovery requests, which set whether to allow a certificate to be issued reusing an existing key pair if the certificate is lost.
The OCSP agent services page allows agents to configure CAs which publish CRLs to the OCSP, to load CRLs to the OCSP manually, and to view the state of client OCSP requests.
The TKS is the only subsystem without an agent services page.
The CA and TPS both process direct user requests in some way. That means that end users have to have a way to connect with those subsystems. The CA has end-user, or end-entities, HTML services. The TPS uses the Enterprise Security Client.
The end-user services are accessed over standard HTTP using the server's host name and the standard port number; they can also be accessed over HTTPS using the server's host name and the specific end-entities SSL/TLS port.
For CAs, each type of SSL/TLS certificate is processed through a specific online submission form, called a profile. There are about two dozen certificate profiles for the CA, covering all sorts of certificates — user SSL/TLS certificates, server SSL/TLS certificates, log and file signing certificates, email certificates, and every kind of subsystem certificate. There can also be custom profiles.
Figure 2.8. Certificate Manager's End-Entities Page
End users retrieve their certificates through the CA pages when the certificates are issued. They can also download CA chains and CRLs and can revoke or renew their certificates through those pages.
2.7.4. Enterprise Security Client
The Enterprise Security Client is a tool for Red Hat Certificate System which simplifies managing smart cards. End users can use security tokens (smart cards) to store user certificates used for applications such as single sign-on access and client authentication. End users are issued the tokens containing certificates and keys required for signing, encryption, and other cryptographic functions.
The Enterprise Security Client is the third part of Certificate System's complete token management system. Two subsystems — the Token Key Service (TKS) and Token Processing System (TPS) — are used to process token-related operations. The Enterprise Security Client is the interface which allows the smart card and user to access the token management system.
After a token is enrolled, applications such as Mozilla Firefox and Thunderbird can be configured to recognize the token and use it for security operations, like client authentication and S/MIME mail. Enterprise Security Client provides the following capabilities:
Supports JavaCard 2.1 or higher cards and Global Platform 2.01-compliant smart cards like Safenet's 330J smart card.
Supports Gemalto TOP IM FIPS CY2 tokens, both the smart card and GemPCKey USB form factor key.
Supports SafeNet Smart Card 650 (SC650).
Enrolls security tokens so they are recognized by TPS.
Maintains the security token, such as re-enrolling a token with TPS.
Provides information about the current status of the token or tokens being managed.
Supports server-side key generation so that keys can be archived and recovered on a separate token if a token is lost.
The Enterprise Security Client is a client for end users to register and manage keys and certificates on smart cards or tokens. This is the final component in the Certificate System token management system, with the Token Processing System (TPS) and Token Key Service (TKS).
The Enterprise Security Client provides the user interface of the token management system. The end user can be issued security tokens containing certificates and keys required for signing, encryption, and other cryptographic functions. To use the tokens, the TPS must be able to recognize and communicate with them. Enterprise Security Client is the method for the tokens to be enrolled.
Enterprise Security Client communicates over an SSL/TLS HTTP channel to the back end of the TPS. It is based on an extensible Mozilla XULRunner framework for the user interface, while retaining a legacy web browser container for a simple HTML-based UI.
After a token is properly enrolled, web browsers can be configured to recognize the token and use it for security operations. Enterprise Security Client provides the following capabilities:
Allows the user to enroll security tokens so they are recognized by the TPS.
Allows the user to maintain the security token. For example, Enterprise Security Client makes it possible to re-enroll a token with the TPS.
Provides support for several different kinds of tokens through default and custom token profiles. By default, the TPS can automatically enroll user keys, device keys, and security officer keys; additional profiles can be added so that tokens for different uses (recognized by attributes such as the token CUID) can automatically be enrolled according to the appropriate profile.
Provides information about the current status of the tokens being managed.
2.7.5. Command Line Interface (CLI)
Red Hat Certificate System provides a client command-line interface (CLI) to access various services on the server. The client CLI can be invoked as follows:
pki [CLI options] <command> [command parameters]
Note that the command line options must be placed before the command, and the command parameters after the command.
To use the command line interface for the first time, specify a new password and use the following command:
pki -c <password> client-init
This will create a new client NSS database in the
~/.dogtag/nssdb directory. The password must be specified in all CLI operations that uses the client NSS database.
Some commands may require client certificate authentication. To import an existing client certificate and its key into the client NSS database, specify the PKCS #12 file and the password, and execute the following command:
pki -c <password> pkcs12-import --pkcs12-file <file> --pkcs12-password <password>
To execute a command using the client certificate, specify the certificate nickname and the client NSS database password:
pki -n <nickname> -c ≶password> <command> [command parameters]
The command line interface supports a number of commands organized in a hierarchical structure. To list the top-level commands, execute the
pki command without any additional commands or parameters:
Some commands have subcommands. To list them, execute
pki with the command name and no additional options. For example:
To view command usage information, use the
pki ca-cert-find --help
To view manual pages, specify the command line
pki help ca-cert-find