The Certificate System runs as web applications in Tomcat. Tomcat provides the entry point for users and client applications to access Certificate System subsystem functions through the different interfaces: administrative console, agent services, end-entities pages, and REST API.

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.

See also JSS.

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.

See also NSS.

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.

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.