SSL/TLS Best Practices for 2019

In 2019, securing your website with an SSL/TLS certificate is no longer optional, even for businesses that don’t deal directly with sensitive customer information on the web. Search engines like Google use site security as an SEO ranking signal, and web browsers such as Chrome alert users to websites that do not use HTTPS:

Browser working for insecure website

However, the prospect of setting up your web servers and applications to use the SSL/TLS protocol correctly can feel daunting, as there are many arcane configuration and design choices to make. This guide provides a quick overview of the main points to keep in mind when setting up SSL/TLS for your website, while focusing on both security and performance. There’s still a lot to cover with just the basics, so we’ve broken it down into a series of steps:

 

Choose a Reliable Certificate Authority (CA)

Your certificates are only as trustworthy as the CA that issues them. All publicly-trusted CAs are subject to rigorous third-party audits to maintain their position in major operating system and browser root certificate programs, but some are better at maintaining that status than others. Look for a CA that (like SSL.com):

  • Does most of its business in the field of publicly-trusted PKI. These businesses have the most to lose if poor security practices come to light, and everything to gain by keeping up with evolving industry standards.
  • Has responded efficiently and effectively to recent security and compliance problems, such as the industry-wide serial number entropy issue of early 2019. Searching industry forums like mozilla.dev.security.policy can give you a good idea about how a particular CA reacts to adversity.
  • Offers the products and services you may require, such as Extended Validation (EV) certificates and bulk certificate issuance and management.
  • Has a reputation for great customer service and technical support. Keeping your company’s website secure 100% of the time is important, and you need to be able to get a real expert on the phone when things go wrong.
 

Generate and Secure Your Private Keys

The SSL/TLS protocol uses a pair of keys to authenticate identities and encrypt information sent over the Internet. One of these (the public key) is intended for wide distribution, and the other (the private key) should be kept as securely as possible. These keys are created together when you generate a certificate signing request (CSR). Here are a few pointers to keep in mind regarding your private keys:

  • Use Strong Private Keys: Larger keys are harder to crack, but require more computing overhead. Currently, at least a 2048-bit RSA key or 256-bit ECDSA key is recommended, and most websites can achieve good security while optimizing performance and user experience with these values.
    Note: for an overview of these two algorithms, please see SSL.com’s article, Comparing ECDSA vs RSA.
  • Protect Your Private Keys:
    • Generate your own private keys on a secure and trusted computer (preferably on the server where they will be deployed). Never allow a CA (or anyone else) to generate private keys on your behalf. A reputable public CA, such as SSL.com, will never offer to generate or handle your private keys.
    • Only give access to private keys as needed. Generate new keys when employees with private-key access leave the company.
    • Renew certificates as often as practically possible (at least yearly would be good), preferably using a freshly-generated private key each time.
 

Configure Your Server

On the surface, installing an SSL/TLS certificate may seem like a straightforward operation; however, there are still many many configuration decisions that must be made to ensure that your web server is fast and secure, and that end users have a smooth experience that is free of browser errors and warnings. Here are some configuration pointers to help get you on track when setting up SSL/TLS on your servers:

  • Install Complete Certificate Chains: End-entity SSL/TLS certificates are generally signed by intermediate certificates rather than a CA’s root key. Make sure that any intermediate certificates are installed on your web server to provide browsers with a complete certification path and avoid trust warnings and errors for end users. Your CA will be able to provide you with any necessary intermediates; SSL.com’s customers can use our Intermediate Certificate Download page to retrieve intermediate bundles for many server platforms.
  • Use Current SSL/TLS Protocols (TLS 1.2 or 1.3): In late 2018, all major browser vendors announced plans to deprecate TLS 1.0 and 1.1 by the first half of 2020. As of Chrome 72 (released January 30, 2919), Google has deprecated TLS v1.0 and v1.1, and plans to end support for these protocols in Chrome 81. Widespread browser support of earlier SSL/TLS versions, such as SSL v3, is long gone. While TLS 1.2 is currently the most widely-used version of the SSL/TLS protocol, TLS 1.3 (the latest version) is already supported in the current versions of most major web browsers.
  • Use a Short List of Secure Cipher Suites: Choose only cipher suites that offer at least 128-bit encryption, or stronger when possible. The National Institute of Standards and Technology (NIST) also recommends that that all TLS implementations move away from cipher suites containing the DES cipher (or its variants) to ones using AES. Finally, using only a small subset of potentially acceptable cipher suites minimizes the attack surface for as-yet-undiscovered vulnerabilities. The appendix of SSL.com’s Guide to TLS Standards Compliance provides example configurations for the most popular web server platforms, using TLS 1.2.
  •  Use Forward Secrecy (FS): Also known as perfect forward secrecy (PFS), FS assures that a compromised private key will not also compromise past session keys. To enable FS:
    • Configure TLS 1.2 to use the Elliptic Curve Diffie-Hellman (EDCHE) key exchange algorithm (with DHE as a fallback), and avoid RSA key exchange completely if possible.
    • Use TLS 1.3 – TLS 1.3 provides forward secrecy for all TLS sessions via the the Ephemeral Diffie-Hellman (EDH or DHE) key exchange protocol.
  • Enable TLS Session Resumption:  Similarly to using keepalives to maintain persistent TCP connections, TLS session resumption allows your web server to keep track of recently-negotiated SSL/TLS sessions and resume them, bypassing the computational overhead of session key negotiation.
 

Use Best Practices for Web Application Design

Designing your web applications with security in mind is just as important as configuring your server correctly. These are the most important points for making sure that your users aren’t exposed to man in the middle attacks, and that your application gets the SEO benefits that come with good security practices:

  • Eliminate Mixed Content: JavaScript files, images, and CSS files should all be accessed with SSL/TLS. As outlined in SSL.com’s article, HTTPS Everywhere, serving mixed content is no longer an acceptable way to boost website performance, and can result in browser security warnings and SEO problems.
  • Use Secure Cookies: Setting the Secure flag in cookies will enforce transmission over secure channels (e.g. HTTPS). You can also keep client-side JavaScript from accessing cookies via the HttpOnly flag, and restrict cross-site use of cookies with the SameSite flag.
  • Evaluate Third-Party Code: Make sure you understand the potential risks of using third-party JavaScript code, such as Google Analytics. While Google (probably) doesn’t have malicious designs on your website, such widely-used code presents a tempting attack target for intruders. Always vet third-party trustworthiness to the best of your ability and link to all third-party code with HTTPS. Finally, make sure that your benefit from any third-party elements on your website is worth the risk.
 

Check Your Work with Diagnostic Tools

After setting up SSL/TLS on your server and website or making any configuration changes, it is important to make sure that everything is set up correctly and your system is secure. Numerous diagnostic tools are available for checking your site’s SSL/TLS. For example, SSL.com’s SSL Scanner will let you know:

  • If your certificate correctly covers your website’s domain name.
  • How many days are left until your certificate expires.
  • If your certificate was issued by a trusted CA.
  • If your certificate chain is complete.
  • If your certificate has been revoked.

Other online tools and applications are available that will crawl your site checking for security problems like mixed content. You can also check for mixed content with a web browser by using its built-in developer tools:

mixed content warning
Mixed Content warning in Chrome console

Whatever tools you choose, it is also important to set a schedule for checking your SSL/TLS installation and configuration. Your CA may also be able to help you with this; for example, as a convenience for our customers, SSL.com provides automated notices of impending certificate expiry.

 

Stay Alert for New Vulnerabilities

Web security is a constantly-moving target, and you should always be on the lookout for the next attack and promptly applying security patches on your server. This means reading and staying in touch with what’s on the horizon when it comes to information security as well as keeping on top of software updates – especially the critical ones. SSL.com’s website (where you are reading this right now) is a great source for staying up to date on SSL/TLS and information security.

 

But What About…?

If you’d like to know more about any of the topics covered in this guide and learn about new issues and technologies as they arise, you can start by browsing and searching SSL.com’s Knowledgebase, which we keep updated weekly with new developments in the field of SSL/TLS and PKI. You can also feel free to contact our support staff at any time via email at Support@SSL.com, on the phone at 1-877-SSL-Secure, or by clicking the chat link at the bottom right of this page.