Jre; Internal Database; Ssl/Tls And Supported Cipher Suites - Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION Administration Manual

Chapter 1. Overview
• 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/.

1.4.8. JRE

The Java™ Runtime Environment (JRE) provides the Java™ Virtual Machine (JVM) and supporting
class libraries needed to run the Certificate System.

1.4.9. Internal Database

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.

1.4.10. 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, 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. Though many web servers continue to use 1024-bit keys,
web servers should migrate to at least 2048 bits. For 64-bit machines, consider using stronger keys.
All CAs should use at least 2048-bit keys, and stronger keys (such as 3072 or 4096 bits) if possible.
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 10^38
possible 128-bit keys and 1.1 x 10^77 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
20