Overview of Server Architecture
Dogtag Certificate System comprises 6 major subsystems:
- Certificate Authority
- Data Recovery Manager
- OCSP Manager
- Registration Authority
- Token Key Service
- Token Processing System
The Certificate Manager is the subsystem that provides Certificate Authority functionality for issuing, renewing, revoking, and publishing certificates and creating and publishing CRLs. It is implemented in Java and it runs on tomcat.
Data Recovery Manager
The Data Recovery Manager (DRM) is an optional subsystem that provides private encryption key storage and retrieval. It is implemented in Java and it runs on top of tomcat.
In addition to archiving and recovering private keys, the DRM can also serve as a server-side key generator. If configured, TPS could direct enrollment requests to the DRM to generate a key pair and archive the private key material of the key pair. The generated private key is transmitted securely and injected back into the smartcard. This feature is referred to as Server Side Key Generation.
The Online Certificate Status Manager is an optional subsystem that provides OCSP responder services, which means it stored CRLs for CAs and can distribute the load for verifying certificate status. It is implemented in Java and it runs on top of tomcat.
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.
Token Key Service
The Token Key Service (TKS) provides secure channels for communication between smart card tokens and a TPS instance. It creates these channels by using a pre-generated master key to derive secret keys that are specific for each individual token enrolled through the TPS. These secure channels allow the commands and keys sent to the smart card to be encrypted, and the shared secrets between tokens and the TKS help the smart card validate that the privileged commands sent to it are from the appropriate TPS. During server-side key generation, the TKS also generates transport keys which wrap, or encrypt, the user's private keys to secure them during transit. It is implemented in Java and it runs on top of tomcat.
Token Processing System
The Token Processing System (TPS) provides the registration authority functionality in the token management infrastructure and establishes secure channels between the Enterprise Security Client and the back-end subsystems (CA, TKS, and DRM).
It is implemented in C++, and it runs on Apache.
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 and RA. 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.
- Tomcat - CA, OCSP, TKS, DRM
- Apache - TPS, RA
JSS and the JNI Layer
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.
Standard PKCS#11 Interface
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. ...
SSL/TLS and Supported Cipher Suites
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. The Certificate System supports RSA public-key cryptographic systems.
NOTE: Most web servers can continue to use 1024-bit RSA keys without negatively affecting security for normal operations. Switching to 2048-bit keys for most applications may hurt server performance. All CAs, however, should use 2048-bit RSA keys or higher.
Common Framework (excluding TPS and RA)
The common framework, which is written in Java, provides the management of subsystem, logging, authentication, access control, self tests, and notifications.
Internal Directory Server
The Certificate System uses Fedora 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.
The Certificate System provides a Java GUI-based administration tool called the Console that is used for administrative tasks such as managing users and maintaining the subsystem, performs daily operational and managerial duties for the subsystem, and configures the server.
Enterprise Security Client (ESC)
End users can use security tokens, which are also called 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. To use the tokens, the TPS must be able to recognize and communicate with them. The tokens have to be enrolled, the process of formatting tokens with keys and certificates and adding them to the Certificate System. Enterprise Security Client provides the user interface for end entities to enroll tokens and to communicate with the TPS. Enterprise Security Client provides the conduit through which TPS communicates with each token over a secure HTTP channel (HTTPS).
You can read more about ESC here.