Figure 1.4, “Certificate System Architecture” shows the structure of the Certificate System; this structure is explained in more detail in the following sections.
Within the Certificate System component, a set of common modules, which can all be extended with custom Java™ plug-ins, are provided for all subsystems. Although some may not be used in the default setting, they are available for further customization.
-
Authentication.
-
Authorization. The default is access control from the internal LDAP database.
-
ACL evaluators. The default is to use user/group evaluators.
-
Certificate profiles, which have customizable extensions and constraints.
-
The job scheduler, which can be edited to control routinely-scheduled events.
-
Email notification.
-
Event listeners.
-
Publishing. Both the publisher and mapper can be modified.
-
Logging, including signed audit logs. The logging mechanism can be extended.
-
Self-tests. Both the start-up and manually-initiated self-tests can be extended.
-
Servlets, depending on subsystem installation.
-
Password quality checker.
The Certificate System employs Red Hat Fortitude as its HTTP engine; this runs secure Tomcat for the CA, OCSP, TKS, and DRM subsystems and secure Apache for TPS. Fortitude supports the subsystem instance HTTP interfaces and provides the entry point for all users and applications to access Certificate System subsystem functions through the different user interfaces: administrative console, agent services, and end-entities pages. The subsystem pages are accessed over HTTP, but they are created by subsystem-specific servlets contained in the Certificate System. While the HTTP engine provides the connection entry points, Certificate System completes the interfaces by providing the servlets specific to each interface. These servlets can return data in HTML or XML formats, making it easier for system administrators to write scripts which interact with these servlets. For more information, see Section 3.8, “Using Java Servlets”.
Each of the subsystems contains interfaces for interacting with other parts of the subsystem. Four subsystems (CA, DRM, OCSP, and TPS) have an agent interface for agents to perform the tasks assigned to them; four subsystems (CA, DRM, OCSP, and TKS) also have an administrative console for managing that instance, such as adding users and viewing logs. A CA subsystem also has an end-entity services interface for users to enroll in the PKI.
-
End-Entities Interface . The CA java servlets in the end-entities page process the HTML forms submitted through the HTTP entry point. From the information in these forms, the servlets enroll and revoke certificates for users and allow users to retrieve issued certificates.
NOTE
The OCSP, DRM, TKS, and TPS subsystems do not have end-entity pages.
-
Agent Services Interface . The agent services page java servlets process HTML form submitted through the agent services HTTP pages. From the information in each submitted form, the agent servlets allow agents to perform agent tasks, such as editing and approving requests for issuing, renewing, or revoking certificates and approving certificate profiles.
NOTE
The TPS interface is different than the agent services pages for the other three subsystems. This HTML interface also functions as the administrative interface in place of a Java™ console.
-
Administrative Interface (Subsystem Console) . The administrative java servlets process commands from the administrative entry-point. From the information supplied in the commands, the administration servlets allow administrators to perform administrative tasks and configure plug-in modules. This interface is similar for the CA, DRM, OCSP, and TKS subsystems. While there are some common configuration types, there are different plug-ins available, depending on the kind of subsystem. The auditor shares the same interface with the administrator, except with the ability to view all configurations and logs, including audit logs; administrators cannot view audit logs.
NOTE
The TPS subsystem does not have an administrative console; administrator tasks are performed through an HTML interface accessed through the agent services URL.
These servlets can return data in HTML or XML formats, making it easier for system administrators to write scripts which interact with these servlets. For more information, see Section 3.8, “Using Java Servlets”.
JSS provides a Java™ interface for security operations performed by NSS. JSS and higher levels of the Certificate System 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 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 is available on-line at http://www.mozilla.org/projects/security/pki/jss/index.html.
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 PKCS #11 for cryptographic token interfaces. Red Hat uses NSS to support these features in a wide range of products, including Certificate System. NSS documentation is available on-line at http://www.mozilla.org/projects/security/pki/nss/overview.html.
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, Certificate System is compatible with a wide range of hardware and software devices.
At least one PKCS #11 module must be available to any Certificate System subsystem instance. As shown in Figure 1.4, “Certificate System Architecture”, a PKCS #11 module (also called a cryptographic module or cryptographic service provider) manages cryptographic services such as encryption and decryption. PKCS #11 modules are analogous to drivers for cryptographic devices that can be implemented in either hardware or software. Red Hat provides a built-in PKCS #11 module with the Certificate System.
A PKCS #11 module always has one or more slots which can be implemented as physical hardware slots in a physical reader such as 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.
Two cryptographics modules are included in the Certificate System:
-
The default internal PKCS #11 module, which comes with two tokens:
-
The internal crypto services token, which performs all cryptographic operations such as encryption, decryption, and hashing.
-
The internal key storage token ("Certificate DB token" in Figure 1.4, “Certificate System Architecture”), which handles all communication with the certificate and key database files that store certificates and keys.
-
-
The FIPS 140-1 module. This module complies with the FIPS 140-1 government standard for cryptographic module implementations. The FIPS 140-1 module includes a single, built-in FIPS 140-1 certificate database token (as shown in Figure 1.4, “Certificate System Architecture”), which handles both cryptographic operations and communication with the certificate and key database files.
Any PKCS #11 module can be used with the Certificate System. The server uses a file called secmod.db to track modules that are available. This file can be modified using the modutil tool. This file needs to be modified when there are changes to the system like installing hardware accelerators to use for signing operations. For more information on modutil, see http://www.mozilla.org/projects/security/pki/nss/tools/.
The following command-line tools are provided with the Certificate System to help manage the system:
-
Audit log signature verification tool (
AuditVerify) -
Enrollment PIN generation tool (
setpin) -
Mass revocation tool (
revoker) -
(Signed) Certificate System request tool
-
Bulk certificate issuance tool (
bulkissuance)
For more information about Certificate System command-line tools, see the Certificate System Command-Line Tools Guide, which is available at http://redhat.com/docs/manuals/cert-system/.
The Java™ Runtime Environment (JRE) provides the Java™ Virtual Machine (JVM) and supporting class libraries needed to run the Certificate System.
The Certificate System uses Red Hat Directory Server as its database for storing information such as certificates, requests, users, roles, ACLs, and other internal information. The Certificate System communicates with the internal LDAP database securely through SSL client authentication.
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are universally accepted standards for authenticated and encrypted communication between clients and servers. Both client and server authentication occur over SSL/TLS. SSL/TLS uses a combination of public key and symmetric-key encryption. Symmetric-key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An SSL/TLS session always begins with an exchange of messages called the SSL handshake, initial communication between the server and client. The handshake allows the server to authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows.
Both of these protocols support using a variety of different cryptographic algorithms, or ciphers, for operations such as authenticating the server and client, transmitting certificates, and establishing session keys. Clients and servers may support different cipher suites, or sets of ciphers. Among other functions, the SSL handshake determines how the server and client negotiate which cipher suite they will use to authenticate each other, to transmit certificates, and to establish session keys.
Key-exchange algorithms such as RSA govern the way the server and client determine the symmetric keys to use during an SSL session. The most common SSL cipher suites use RSA key exchange, and Certificate System supports RSA public-key systems.
Longer RSA keys are required to provide security as computing capabilities increase. The recommended RSA key-length is 2048 bits. However, though a 2048-bit RSA key length is more secure than the common 1024-bit length, it is also slower and can affect server performance. Most web servers can continue to use 1024-bit RSA keys without negatively affecting security for normal operations. All CA servers, however, should use 2048-bit RSA keys.
Certificate System supports several different cipher suites with the RSA key exchange:
-
AES and SHA-1 Message Authentication. Advanced Encryption Standard (AES) ciphers have a fixed block size of 128-bits, and the keys can be either 128-bit or 256-bit. There are 3.4 x 1038 possible 128-bit keys and 1.1 x 1077 possible 256-bit keys. There are more possible keys than any other cipher, making AES the strongest cipher supported by SSL. These cipher suites are FIPS-compliant.
-
Triple DES and SHA-1 Message Authentication. Triple DES (Data Encryption Standard) is the second-strongest cipher supported by SSL, but it is not as fast as RC4. Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are approximately 3.7 * 1050 possible keys. This cipher suite is FIPS-compliant.
-
RC4 and RC2 and MD5 Message Authentication. The RC4 and RC2 ciphers have 128-bit encryption, which permits approximately 3.4 * 1038 possible keys. This makes RC4 or RC2 keys very difficult to crack. RC4 ciphers are faster than RC2 ciphers.
RC4 can use SHA-1 message authentication as well as MD5 message authentication.
-
DES and SHA-1 Message Authentication. DES 56-bit encryption permits approximately 7.2 * 1016 possible keys. This cipher suite is no longer FIPS-compliant because it is too weak cryptographically.