In 2021, 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 popular web browsers like 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.
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.
- Responds efficiently and effectively to vulnerability discoveries affecting user security and privacy, 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 useful products and services, such as Extended Validation (EV) certificates, bulk/automated certificate issuance via an intuitive API or the ACME protocol, easy certificate life-cycle management and monitoring services, and support for integration with an extensive list of 3rd party solutions.
- 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.
- 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 all certificates for the old 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. Automation tools like the ACME protocol are helpful for scheduling frequent certificate renewals.
- If a private key has been (or might have been) compromised, revoke all certificates for this key, generate a new key pair, and issue a new certificate for the new key pair.
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:
- Make sure all hostnames are covered: Does your certificate cover your site’s domain name both with and without the
wwwprefix? 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). Chrome versions 84 (released July 14, 2020) and above present an interstitial warning for these protocols, and support will be fully removed in May 2021. 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.
- 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.
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:
- Use Secure Cookies: Setting the
- Evaluate Third-Party Code: Make sure you understand the potential risks of using third-party libraries in your website, such as the possibility of inadvertently introducing vulnerabilities or malicious code. 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:
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.