In our previous post, we discussed configuring TLS cipher suites to maximize security by preferring newer, more secure ciphers and removing older ones where possible. For this post, we will take a closer look at different types of certificates that are used in HTTPS.
The certificate is responsible for several different things when securing a TLS session. Primarily, the certificate provides a public key to the client browser. For non-ephemeral algorithms, the certificate’s private key is used to manage the session key. (We also discussed the ephemeral Diffie-Hellman key exchange, or DHE, in Part 2 of this series.)
A certificate contains two important pieces when signing information and encrypting it: The hash algorithm and the signature algorithm. The hash algorithm is used to hash the contents of the certificate itself when the certificate is created, or issued by the certificate authority.
Typically, SHA1 or MD5 is used for the hashing algorithm and RSA is used for the signing algorithm. While these algorithms are commonly used, newer ones are available and should be used once supported.
The hashing algorithm
The hashing algorithm is important because less secure algorithms can result in a collision in the hash, which is to say two different inputs produce the same hash. When this happens, the results can be used to forge an SSL certificate. The forged certificate can create the same digest as the real certificate, even though the two certificates are completely different on the algorithm level. For MD5, this has already been proven possible and therefore it is strongly recommended that any MD5 SSL certificates are removed.
SHA1 has similar concerns. However, it hasn’t been known to lead to a full forgery, at least not yet. For this reason, we recommend using certificates with SHA-256 as their hashing algorithm. This does, however, lead to compatibility problems with older clients, such as Internet Explorer on Windows XP.
The signature algorithm
A significant portion of SSL certificates today use either RSA 1024 or RSA 2048 as their signature algorithm. Although a successful factorization (i.e. cracking the code) of RSA 1024 has not been demonstrated, the computer power required to do so is available. Also, RSA 768 has been factored in, which leads to concerns that 1024 is within reach, or may already be possible for those with the right resources. For this reason, RSA 2048 is used.
While RSA 2048 should be safe for the foreseeable future, elliptic curve algorithms are already being supported. Elliptic Curve DSA (ECDSA) certificates are not common and few certificate authorities will issue them. However, they are believed to offer better security. An ECC 256-bit certificate is equivalent in strength to RSA 3072 and, since ECC uses smaller public keys, they are more efficient from a processing perspective.
ECC certificates can be issued by internal certificate authorities, such as Windows Server 2012, or a self-signed ECC certificate can be created using OpenSSL:
openssl ecparam -out private.pem -name prime256v1 -genkey
openssl req -x509 -new -sha256 -key private.pem -keyform PEM -out cert.pem -days 365
openssl pkcs12 -export -out cert.pfx -inkey private.pem -in cert.pem
This will create a 256-bit private key over the 256-bit prime field and a public certificate. The final command combines the private key and pubic certificate into a single p12 file so that it can be imported into Internet Information Services (IIS).
What’s next?
Next, we will look at configuring Secret Server to better mandate the use of HTTPS using HSTS, and certificate revocation with OSCP and OSCP Stapling.
Read All Parts:
SSL: Beyond the Basics
SSL: Beyond the Basics Part 2: Ciphers
SSL: Beyond the Basics Part 3: Certificates
SSL: Beyond the Basics Part 4: Strict Transport Security
