SSL/TLS Best Practices for 2023

In 2023, 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.
  
  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 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 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). Chrome versions 84 (released July 14, 2020) and above present an interstitial warning for these protocols, and support was scheduled to 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.
  
  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.

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

Implement HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. This policy is communicated by the server to the user agent via an HTTP response header field named “Strict-Transport-Security”.

To implement HTTP Strict Transport Security (HSTS), you need to add a special response header to your web server’s configuration.

Here’s a step-by-step guide:

1. Ensure your site supports HTTPS: Before enabling HSTS, your site must have a valid SSL certificate and be able to serve content over HTTPS. If your site isn’t yet configured for HTTPS, you’ll need to obtain an SSL certificate and configure your server to use it.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{This line tells the browser to always use HTTPS for your site for the next year (31,536,000 seconds), including all subdomains.}

2. Test your configuration: After adding the HSTS header, you should test your site to ensure it’s working correctly. You can do this by visiting your site and using your browser’s developer tools to check the response headers. You should see the Strict-Transport-Security header with the value you set.
3. Consider adding your site to the HSTS preload list: The HSTS preload list is a list of sites that are hardcoded into browsers as HSTS-enabled. This provides an extra level of protection, as it ensures that the first connection to your site is secure, even before the HSTS header is received. You can submit your site to the HSTS preload list at hstspreload.org.

Use Case: A news website wants to ensure that its users always connect to it securely, even if they accidentally type “http” instead of “https” in the URL. The website uses HSTS by adding the Strict-Transport-Security header to its server configuration, setting a long max-age and including all subdomains. This tells user agents to always connect to it using HTTPS, protecting users from attacks that try to downgrade the connection to HTTP and steal their cookies. The website also submits itself to the HSTS preload list for extra protection.

Implement HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) was a security feature that allowed a web server to associate a specific cryptographic public key with itself to prevent man-in-the-middle (MITM) attacks with forged certificates.

Here’s a brief overview of how it was used:

1. Generate Pinning Information: The first step in implementing HPKP was to generate the pinning information. This involved creating a cryptographic hash of the public key of the certificate or the public key of the intermediate or root certificate.
2. Configure the Web Server: The next step was to configure the web server to include the Public-Key-Pins HTTP header in responses. This header included the hashes of the public keys (the “pins”), a time to live (how long the browser should remember the information), and optionally a report URI (where the browser would send reports of pin validation failures).
3. Handle Pin Validation Failures: If a browser that supported HPKP received a certificate chain that didn’t include at least one of the pinned public keys, it would consider the connection untrusted. If a report URI was specified, the browser would also send a report of the failure to that URI.

However, due to the risk of misuse and the potential for causing denial of service, HPKP has been deprecated by most browsers and is no longer a recommended practice. Misconfiguration of HPKP could lead to a situation where a website becomes inaccessible.

Use Case: In the past, a tech company used HPKP to pin their public keys to their servers. This ensured that if a Certificate Authority (CA) was compromised and a certificate was mistakenly issued for their domain, browsers would not trust it unless it also had a public key that matched one of the pinned keys. However, they had to be very careful to avoid losing access to the pinned keys, which would make their website inaccessible. They also had to ensure that they had a process in place to rotate the pins before they expired, to avoid making their site inaccessible to users with cached pinning information.

Use TLS Fallback SCSV to Prevent Protocol Downgrade Attacks

TLS Fallback SCSV (Signaling Cipher Suite Value) is a mechanism that was introduced to prevent protocol downgrade attacks. These attacks occur when an attacker interferes with the connection setup process and tricks the client and server into using a less secure version of the protocol than they both actually support.

Here’s how you can implement TLS Fallback SCSV:

1. Update Your Server’s SSL/TLS Library: The first step is to ensure that your server’s SSL/TLS library supports TLS Fallback SCSV. This feature was introduced in OpenSSL 1.0.1j, 1.0.0o and 0.9.8zc. If you’re using a different SSL/TLS library, check its documentation or contact its developers.
2. Configure Your Server: Once your server’s SSL/TLS library supports TLS Fallback SCSV, you may need to configure your server to use it. The exact steps will depend on your server software. For example, in Apache, you might need to add or modify a line in your configuration file like this:

SSLProtocol All -SSLv2 -SSLv3

This line tells the server to use all protocol versions except SSLv2 and SSLv3. If the client and server both support TLS 1.2, but the client attempts to use TLS 1.1 (perhaps because of an attacker’s interference), the server will recognize this as a fallback attempt and reject the connection.

3. Test Your Server: After configuring your server, you should test it to ensure that it’s correctly implementing TLS Fallback SCSV. There are various online tools that can help you with this, such as the SSL Labs Server Test.

Use Case: A global corporation uses TLS Fallback SCSV to protect its internal communications. This ensures that if an attacker tries to force a protocol downgrade, the server will recognize this and reject the connection, protecting the corporation’s sensitive data. The corporation’s IT team regularly updates their servers’ SSL/TLS libraries and configurations to ensure they’re using the latest security features, and they use online tools to test their servers and confirm that they’re correctly implementing TLS Fallback SCSV.

Avoid Mixed Content Issues

Mixed content is a security risk that occurs when a webpage loaded over a secure HTTPS connection includes resources, such as images, videos, stylesheets, or scripts, that are loaded over an insecure HTTP connection. Browsers may block this mixed content or display a warning to the user, which can harm the user’s perception of the site’s security.

Here’s how you can avoid mixed content issues:

1. Use HTTPS for All Resources: The most straightforward way to avoid mixed content is to ensure that all resources on your site are loaded over HTTPS. This includes images, scripts, stylesheets, iframes, AJAX requests, and any other resources that your site uses.
2. Update Your Site’s Code: If your site’s code includes hard-coded HTTP URLs for resources, you’ll need to update these to use HTTPS instead. If the resource is hosted on a server that doesn’t support HTTPS, you may need to host the resource on your own server or find an alternative resource that can be loaded over HTTPS.
3. Configure Your Server to Send a Content-Security-Policy Header: The Content-Security-Policy (CSP) HTTP header allows you to control what resources your site is allowed to load. By setting a CSP header that only allows HTTPS resources, you can ensure that your site doesn’t accidentally include mixed content.

Use Case: An online magazine ensures that all content, including images and scripts, are loaded over HTTPS. This prevents attackers from tampering with these resources and potentially injecting malicious content. The magazine’s web developers regularly review the site’s code to ensure that all resources are loaded over HTTPS, and they configure their server to send a strict Content-Security-Policy header. They also use online tools to scan their site for mixed content issues and fix any that they find.

Utilize Server Name Indication (SNI) for Hosting Multiple Sites

Server Name Indication (SNI) is an extension to the TLS protocol that allows a server to present multiple certificates on the same IP address and port number. This is particularly useful for web hosting providers that need to host multiple secure websites, each with their own SSL certificate, on the same server.

Here’s how you can use SNI:

1. Ensure Your Server Software Supports SNI: The first step is to ensure that your server software supports SNI. Most modern web servers, including Apache, Nginx, and IIS, support SNI.
2. Configure Your Server: The next step is to configure your server to use SNI. This typically involves adding a separate configuration block for each site that you want to host on the server, and specifying the SSL certificate to use for each site. The exact steps will depend on your server software.
3. Test Your Configuration: After configuring your server, you should test it to ensure that it’s correctly using SNI. You can do this by visiting each site that you’re hosting on the server and checking that the correct SSL certificate is being used.

Use Case: A hosting provider uses SNI to serve multiple websites from the same IP address. This allows them to efficiently use their IP address space and simplify their network configuration. They configure their server to use a different SSL certificate for each site, and they regularly test their configuration to ensure that the correct certificate is being used for each site. This ensures that each site has a secure, trusted connection, even though they’re all being served from the same IP address.

Optimize Performance with Session Resumption

Session resumption is a feature of the TLS protocol that allows a client and server to use the same encryption keys across multiple sessions, reducing the overhead of establishing a new secure connection each time. This can significantly improve performance, especially for applications where the client frequently disconnects and reconnects.

 Here’s how you can use session resumption:

1. Ensure Your Server Software Supports Session Resumption: The first step is to ensure that your server software supports session resumption. Most modern web servers, including Apache, Nginx, and IIS, support this feature.
2. Configure Your Server: The next step is to configure your server to use session resumption. This typically involves enabling the session cache and setting a timeout value for the cache. The exact steps will depend on your server software.
3. Test Your Configuration: After configuring your server, you should test it to ensure that it’s correctly using session resumption. You can do this by establishing a TLS connection to your server, disconnecting, and then reconnecting. If session resumption is working correctly, the second connection should be faster to establish than the first.

Use Case: A mobile app uses session resumption to maintain fast and secure connections. This is particularly useful when the app is used in areas with spotty network coverage, as it allows the app to quickly re-establish a secure connection after a dropout. The app’s developers configure their server to use session resumption, and they regularly test the feature to ensure it’s working correctly. This ensures that the app can provide a fast, seamless experience for users, even in challenging network conditions.

Ensure Certificate Validity with OCSP Stapling

Online Certificate Status Protocol (OCSP) stapling is a method for improving the performance of SSL/TLS while maintaining the security of the connection. It allows the server to fetch the current status of its own certificates from the Certificate Authority (CA) and then deliver that status to clients during the TLS handshake.

Here’s how you can implement OCSP stapling:

1. Ensure Your Server Software Supports OCSP Stapling: The first step is to ensure that your server software supports OCSP stapling. Most modern web servers, including Apache, Nginx, and IIS, support this feature.
2. Configure Your Server: The next step is to configure your server to use OCSP stapling. This typically involves enabling the feature in your server’s SSL/TLS configuration and specifying a location for the server to store the OCSP responses. The exact steps will depend on your server software.
3. Test Your Configuration: After configuring your server, you should test it to ensure that it’s correctly using OCSP stapling. You can do this by establishing a TLS connection to your server and checking that the server includes an OCSP response in the TLS handshake.

Use Case: An online retailer uses OCSP stapling to quickly verify the status of its SSL certificate. This ensures that customers always have a secure connection and can trust that their data is safe. The retailer’s IT team configures their server to use OCSP stapling, and they regularly test the feature to ensure it’s working correctly. This helps to maintain the trust of their customers and protect their sensitive data.

Disable TLS Compression to Mitigate CRIME Attack

TLS compression is a feature that can improve the performance of SSL/TLS by reducing the amount of data that needs to be sent over the network. However, it can also make the connection vulnerable to the CRIME (Compression Ratio Info-leak Made Easy) attack, which can allow an attacker to infer the contents of encrypted traffic.

Here’s how you can disable TLS compression: 

1. Ensure Your Server Software Supports Disabling TLS Compression: The first step is to ensure that your server software supports disabling TLS compression. Most modern web servers, including Apache, Nginx, and IIS, support this feature.
2. Configure Your Server: The next step is to configure your server to disable TLS compression. The exact steps will depend on your server software. For example, in Apache, you might add a line like this to your configuration file:

SSLCompression off

This line tells the server not to use compression for SSL/TLS connections.

3. Test Your Configuration: After configuring your server, you should test it to ensure that it’s correctly disabling TLS compression. You can do this by establishing a TLS connection to your server and checking that the connection is not using compression.

Use Case: A financial institution disables TLS compression on its servers to protect against the CRIME attack. This helps to ensure the confidentiality of sensitive financial data, such as account numbers and transaction details. The institution’s IT team configures their servers to disable TLS compression, and they regularly test the servers to ensure they’re correctly implementing this security measure. This helps to protect the institution’s customers and maintain their trust.

Implement TLS Session Tickets Correctly

TLS session tickets are a feature of the TLS protocol that can improve performance by allowing a client and server to resume a previous session without needing to perform a full handshake. However, they need to be implemented correctly to avoid potential security issues.

Here’s how you can correctly implement TLS session tickets:

1. Ensure Your Server Software Supports TLS Session Tickets: The first step is to ensure that your server software supports TLS session tickets. Most modern web servers, including Apache, Nginx, and IIS, support this feature.
2. Configure Your Server: The next step is to configure your server to use TLS session tickets. This typically involves enabling the feature in your server’s SSL/TLS configuration. The exact steps will depend on your server software.
3. Use Unique Session Ticket Keys: To prevent potential security issues, each server should use a unique session ticket key. If you’re using a load balancer, you should configure it to distribute clients based on their session ticket, rather than allowing clients to use a session ticket issued by one server to establish a session with another server.
4. Rotate Session Ticket Keys Regularly: To further enhance security, you should regularly rotate your session ticket keys. This can often be automated using your server software or a separate key management system.

Use Case: A large tech company with multiple servers ensures that each server uses a unique session ticket key. This prevents an attacker from being able to use a session ticket from one server to impersonate a user on another server. The company’s IT team configures their servers to use TLS session tickets, and they set up a system to regularly rotate the session ticket keys. They also configure their load balancer to distribute clients based on their session ticket, further enhancing the security of their system.

Enable Secure Renegotiation

Secure renegotiation is a feature of the SSL/TLS protocols that allows the client or server to request a new TLS handshake in the middle of a session. This can be useful for a variety of reasons, such as refreshing encryption keys or changing the level of encryption. However, if not handled securely, it can be exploited by an attacker to inject plaintext into the encrypted communication.

Here’s how you can enable secure renegotiation:

2. Ensure Your Server Software Supports Secure Renegotiation: The first step is to ensure that your server software supports secure renegotiation. Most modern web servers, including Apache, Nginx, and IIS, support this feature.
3. Configure Your Server: The next step is to configure your server to use secure renegotiation. This typically involves enabling the feature in your server’s SSL/TLS configuration. The exact steps will depend on your server software.
4. Test Your Configuration: After configuring your server, you should test it to ensure that it’s correctly using secure renegotiation. You can do this by establishing a TLS connection to your server and then attempting to renegotiate the connection.

Use Case: A social media platform enables secure renegotiation to protect user data. This prevents an attacker from being able to inject malicious content into the encrypted communication between the user and the server. The platform’s IT team configures their servers to use secure renegotiation, and they regularly test the servers to ensure they’re correctly implementing this security measure. This helps to protect the platform’s users and maintain their trust.

Disable Client-initiated Renegotiation to Prevent DoS Attacks

Client-initiated renegotiation is a feature of the SSL/TLS protocols that allows the client to request a new TLS handshake in the middle of a session. However, if an attacker can force a server to continuously renegotiate sessions, it can consume excessive resources and potentially lead to a denial-of-service (DoS) attack.

Here’s how you can disable client-initiated renegotiation:

1. Ensure Your Server Software Supports Disabling Client-Initiated Renegotiation: The first step is to ensure that your server software supports disabling client-initiated renegotiation. Most modern web servers, including Apache, Nginx, and IIS, support this feature.
2. Configure Your Server: The next step is to configure your server to disable client-initiated renegotiation. This typically involves adding a directive to your server’s SSL/TLS configuration. The exact steps will depend on your server software.
3. Test Your Configuration: After configuring your server, you should test it to ensure that it’s correctly disabling client-initiated renegotiation. You can do this by establishing a TLS connection to your server and then attempting to renegotiate the connection. If the server correctly refuses the renegotiation request, then it’s correctly configured.

Use Case: An online gaming platform disables client-initiated renegotiation to protect against potential DoS attacks. This helps to ensure that the platform remains available for users to enjoy, even in the face of potential attacks. The platform’s IT team configures their servers to disable client-initiated renegotiation, and they regularly test the servers to ensure they’re correctly implementing this security measure. This helps to protect the platform’s users and maintain their trust.

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.

Get expert advice on SSL certificates.
Complete the form for a consultation.