SSL and its successor TLS are a never-ending source of surprises – even for me, and I have been using these encryption technologies since the early days of Netscape Navigator. When you think you finally understand SSL, a new mystery opens up, and you find yourself delving the depths again.

Most admins don't have time for long searches. Admins want to set up a secure HTTPS website as quickly as possible and turn to the next task. This article provides advice on using SSL for web practitioners, and I'll even include some sample files for Apache and Nginx.

1. Algorithms and Key Lengths

Currently, TLS supports three key algorithms: DSA is dead; the future belongs to elliptic curve cryptography with ECDSA, but older clients do not support it, so the standard also supports RSA for now.

The key length of 2048 bits for RSA keys, or 256 bits for ECDSA, should be sufficient for most purposes. Keys of this length offer 112 or 128 bits of encryption strength. If you want a future-proof solution, you can opt for a 3072-bit RSA key, which also gives you 128 bits of encryption.

2. KeyManagement

What is more important than the length of the key in practice, however, is the way the admin handles the keys. Much evidence suggests that the most successful attacks on SSL have not actually cracked the encryption but simply avoided it. If you can break into a server to steal the private keys, or otherwise gain access to them, you do not need to break your teeth on the cryptography.

The private keys must remain secret. Only a small group of employees should have access to these valuable files – just enough to ensure smooth operations.

Additionally, the admin should protect the keys with a password and enter a passphrase when generating them. These precautions reduce the risk if a backup of the system gets into the wrong hands.

The person in charge should keep a copy of the keys in a safe place. Losing the key for a single server is not too bad, because a new one can be easily generated. But, if you operate your own certificate authority (CA), keys are extremely complex to replace.

3. TheCertificate

The SSL certificate should come from a reputable certification authority, but you do not need to put too much thought into the choice. In the case of Domain Validated (DV) certificates, the lowest price wins. If your site has many users, certificates with extended validation (EV) leave a better impression, but they hardly increase the technical security.

The certificate needs to contain all the hostnames – including the versions with and without the WWW prefix, as in, example.com and www.example.com . The "Key and Certificate Sharing" box provides more instructions on using multiple hostnames.

The certification chain needs to be complete. Broken chains are among the most common deficiencies. Some browsers can handle a broken chain, but the problem can lead to hard-to-understand errors.

The CA should sign its certificates using SHA-256. It also needs to embed revocation information in the form of certificate revocation lists (CRLs) and an online certificate status protocol (OCSP). If you want to play CA yourself, read the box titled "Self-Signed or Private CA."

Self-Signed or Private CA

This article assumes the certificate comes from a public CA. In addition, you have the option of signing the certificate yourself or operating your own certification authority, which supplies the server with certificates.

These three practices are suitable for various usage scenarios. For a public website, only a certificate from a public certification authority is possible.

Using a self-signed certificate implies many restrictions; it can only be used securely in conjunction with the Mozilla Firefox browser. Only the Firefox allows the user to permanently save exceptions for such certificates (Figure 1). Once you save the exception, you're secure for all later visits to the same site.

Figure 1: Only the Firefox browser can remember a self-signed certificate and guarantee that it has not changed.

Other browsers require re-confirmation every time you visit. If you do not check the fingerprint of the certificate every time – and who does? – you are taking a big risk.

For these reasons, it is better to operate your own certificate authority if you do not want to buy a certificate from a public CA. A full certificate authority is initially more expensive than a self-signed scenario, but as soon as the infrastructure is available and the root key is distributed to all users, it works as reliably as the rest of the PKI world.