3.2. SSL/TLS, ECC, and RSA

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 like RSA and Elliptic Curve Cryptography (ECC) 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, while TLS supports ECC cipher suites as well as RSA. The Certificate System[1] supports both RSA and ECC public-key cryptographic 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.
As PKIs using RSA keys and certificates transition to other cryptographic systems like ECC, servers should continue to support RSA. Certificate System supports using both RSA- and ECC-based certificates in the same subsystem.

3.2.1. Supported Cipher Suites for RSA

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.

3.2.2. Using ECC

Elliptic Curve Cryptography (ECC) is a cryptographic system that uses elliptic curves to create keys for encrypting data. ECC creates cryptographically-stronger keys with shorter key lengths than RSA, which makes it faster and more efficient to implement.
ECC has several advantages over RSA, since it is faster and requires shorter key lengths for stronger keys. The drawback to using ECC is that it is not as widely supported as RSA.

Table 3.1. Comparison of RSA and ECC Cipher Strength

Bits of Security[a] RSA Key Length ECC Key Length
80 1024 160-223
112 2048 224-255
128 3072 256-383
192 7860 384-511
256 15360 512+
[a] The information in this table is from the National Institute of Standards and Technology (NIST). For more information, see http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf.

Certificate System supports using ECC with all of its subsystems, so ECC certificate requests can be submitted to CAs through any of the enrollment profiles and ECC keys can be archived and restored in the DRM. However, Certificate System does not include ECC support natively, so using ECC is slightly different than using RSA:
  • An external PKCS#11 module must be loaded before any subsystems are installed so that they can be configured with ECC subsystem certificates.
  • The CA profile pages can process ECC certificate requests, but they cannot generate ECC keys. Some of the profile forms, like manual user certificates, then cannot be used for ECC certificates. In those cases, a different or custom profile needs to be used, and certificate requests have to be generated using certutil.
For a CA to issue ECC certificates, the CA must be configured with an ECC CA signing certificate. This is best done by loading an ECC PKCS#11 module before the CA is installed, and then configuring the CA using ECC keys.


A CA with an ECC CA signing certificate can issue both ECC and RSA certificates. A CA with an RSA CA signing certificate can only issue RSA certificates.
Only the CA signing certificate is required; if for support purposes it is better to use RSA client certificates with the CA, simply delete the ECC subsystem certificates (except for the signing certificate) and replace them with RSA certificates.
For more information on ECC, see RFC 4492, Section 5.6.1, Table 2.

[1] Only RSA is supported natively. External PKCS#11 modules with ECC support must be loaded for subsystems to use ECC.