SSL Best Practices

Use SSL/TLS to your full advantage.

In 2020, 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:

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.

• 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.

Certificate Authority Authorization (CAA)

Certificate Authority Authorization (CAA) is a standard to protect websites by designating specific CAs that are permitted to issue certificates for a domain name. Once you’ve chosen a CA, you should consider configuring CAA records to authorize it. 

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 environment (preferably on the server where they will be deployed or a FIPS or Common Criteria compliant device). 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  unless they are generated in a secure hardware token or HSM and are non-exportable.
  • Only give access to private keys as needed. Generate new keys and revoke the old ones 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.
  • If a private key has been (or might have been) compromised, revoke it and generate a new key pair.

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:

• Make sure all hostnames are covered: Does your certificate cover your site’s domain name both with and without the 
  www
   prefix? Is there a Subject Alternative Name (SAN) for every domain name the certificate is  intended to protect?
• 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. Google deprecated TLS v1.0 and v1.1 in Chrome 72 (released January 30, 2919), and plans to end support for these protocols in Chrome 84 (expected to be released in July 2020). 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.
  
  Note: Using insecure, deprecated ciphers (such as RC4) can cause browser security errors, such as 

  ERR_SSL_VERSION_OR_CIPHER_MISMATCH

   in Google Chrome.
•  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.
• Consider OCSP Stapling: OCSP stapling allows web servers to deliver cached revocation information directly to the client, meaning that a browser will not have to contact an OCSP server to check if a website’s certificate has been revoked. By eliminating this request, OCSP stapling offers a real performance boost. For more information, please read our article, Page Load Optimization: OCSP Stapling.

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 Shopper’s SSL Checker will let you know if your certificate is correctly installed, when it will expire, and will display the certificate’s chain of trust.

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 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.