Fixes for the SSL/TLS handshake failed error for both internet users and site owners
It’s time for another technical article. Today, we’re going to discuss the SSL/TLS handshake failed error and the ways to fix it. Like many SSL error messages, the SSL handshake error can be triggered from both the client-side and the server-side, so sometimes it can be fixed by regular internet users and other times it’s indicative of a configuration issue on the website’s part.
Regardless of its origins, this can be a frustrating SSL error because it prevents you from making a secure connection with the website you’re attempting to access. This is bad for users and site owners alike — for the site owners because it drives away business (potentially straight into the arms of your competitors).
We’ll get into what the SSL/TLS handshake is, then we’ll cover the reasons for the SSL/TLS handshake failed error and what you can do to fix it.
Let’s hash it out.
What Is the SSL/TLS Handshake?
At the beginning of every HTTPS connection, the client (the internet user’s web browser) and the server (hosting the website) must go through a series of checks — for lack of a better term — to authenticate one another and determine the parameters of the encrypted connection. This is known as the TLS handshake, although some within the industry still refer to it as an SSL handshake.
(SSL is no longer technically accurate since it’s a deprecated protocol. However, we’ll still refer to it as such throughout the article because people still commonly use the term. So, you’ll see “SSL handshake” and “TLS handshake” used interchangeably throughout the content, but just know that we’re still talking about the TLS handshake.)
The TLS handshake process accomplishes three things:
- Authenticates the server as the rightful owner of the asymmetric public/private key pair.
- Determines the TLS version and cipher suite that will be used for the connection.
- Exchanges the symmetric session key that will be used for communication.
If you simplify public key infrastructure (PKI) —which serves as the infrastructure for the entire SSL/TLS ecosystem — it’s really about secure key exchange. During an HTTPS connection, the communication is actually done with symmetric session keys — generally 256-bit advanced encryption standard (AES) keys — that are generated on the client side of things. When a symmetric key is generated, both parties get a copy. They can use it to encrypt and decrypt the data that transmits between them.
While 256-bit encryption is still sufficiently robust, the real security is at the gate where a much larger, much stronger private key (generally a 2048-bit RSA key) helps handle the authentication portion of the connection. Authentication is important because the client wants to make sure it’s connecting with the correct party. That’s essentially what the SSL/TLS handshake is for — it’s a set of checks where:
- The client and server authenticate one another,
- They determine the parameters of the HTTPS connections (what cipher suite will be used), and then
- The client encrypts a copy of the session key and sends it to the server for use during the connection.
Historically, the SSL/TLS handshake has added a small bit of latency to a connection, which is what led to the claim that HTTPS slows down your website. That latency has been addressed in more recent versions of the TLS protocol though, so that’s almost entirely untrue today — especially with HTTP/2 and HTTP/3.
Currently, there are two different versions of the TLS handshake in use: TLS 1.2 and TLS 1.3.
The SSL/TLS Handshake Process in TLS 1.2 vs TLS 1.3
TLS 1.2 uses a handshake that makes multiple roundtrips between the client and the server.
Wondering how the TLS handshake process works? We’re not going to go step-by-step, but essentially:
- The client and server ping one another.
- The server presents its SSL/TLS certificate.
- The client authenticates the certificate authority (CA)-signed certificate.
- They exchange a list of supported cipher suites and agree on one, then key exchange occurs.
This process involves a lot of steps — all of which occur in a short amount of time.
TLS 1.3, on the other hand, has refined the TLS handshake to a single round-trip.
Obviously, this cuts down on the time that it takes for a connection to start — we’re talking milliseconds here so maybe not noticeably (except at scale) — and makes everything more efficient. TLS 1.3 also allows 0-RTT resumption, which streamlines subsequent connections to a TLS 1.3-enabled website even more.
But, given the number of moving parts in a TLS handshake, there’s plenty that can go wrong if a website or a device are misconfigured. A couple years ago we wrote about fixing TLS handshakes failed errors on Firefox, but these errors are far more universal than that. So now let’s talk about what can go wrong with the TLS handshake and what need to be done to fix it.
An Overview of SSL/TLS Handshake Failed Errors
To make this article a little bit easier to follow, we’re going to put all of the possible causes for SSL/TLS handshake failed errors (SSL handshake errors) and who can fix them. After that, we’ll have a dedicated section for each where we’ll cover how to fix them.
|CAUSE||DESCRIPTION OF THE TLS HANDSHAKE ERROR||FIX|
|Incorrect System Time||Client device has the incorrect time & date.||Client|
|Browser Error||A browser configuration is causing the error.||Client|
|Man-in-the-Middle||A third party is intercepting/manipulating connection.||Client|
|Protocol Mismatch||The protocol used by client is not supported by server.||Server|
|Cipher Suite Mismatch||Cipher suite used by client is not supported by server.||Server|
|SNI-Enabled Server||Client can’t communicate with SNI-enabled server.||Server|
Now, let’s dive into fixing these SSL handshake failed errors. Then we’ll finish with a couple of things you should definitely not do from the client-side to try and fix this mistake.
SSL/TLS Handshake Failed — Client Errors
When a handshake fails, it’s usually something going on with the website/server and its SSL/TLS configuration. This results in that pesky SSL/TLS handshake error.
Really, it’s just TLS configuration at this point as support for SSL 3.0 has been almost entirely deprecated. (SSL Labs reports that only 4.6% of sites still support the SSL 3.0. protocol as of August 2020.)
However, there are a few contexts in which a client-side error can cause the SSL/TLS handshake failed error. And a lot of them may seem pretty trivial — things like making sure your system time is correct and your browser is current.
But, as we discussed, there are a lot of moving parts with the TLS handshake, and sometimes even the tiniest hiccup can cause the whole thing to go kaput.
So, let’s go over a few of the client-side fixes for this issue.
Incorrect System Time
I’m really not sure why anyone would take their system clock off of the universal time option, but apparently it happens. Maybe you want to abide your own personal clock like some kind of psychopath or maybe the setting just got accidentally changed — it’s none of my business, really — but if your system time is wrong it can cause problems with TLS handshake. As a result, this can cause the SSL/TLS handshake failed error.
That’s largely owing to the fact that SSL/TLS certificates have finite lifespans, so time is important. In fact, in some rather high profile cases of certificate expiration — like with the Oculus Rift VR system — internet users have even purposely set their system times back to a date before said expiration so that they could still connect. (More recent examples of notable certificate expiries affecting everything from COVID-19 reporting to streaming music services.)
Obviously, don’t change your system time. If you’re still getting the SSL/TLS handshake failed error and your system time is correct, the issue is originating somewhere else.
This isn’t like a browser error — this is literally your browser making a mistake. Sometimes your browser can become misconfigured, or a plugin can cause things to work a little bit differently and it results in problems connecting to otherwise legitimate websites. While diagnosing exactly what needs to be tweaked on your current browser may be a little bit more difficult, narrowing the issue down to a specific browser error is pretty simple: just try another browser and see what happens.
If you’re using Google Chrome, switch to your OS’s native browser like Apple Safari or Microsoft Edge. Otherwise, hop on Mozilla Firefox (my preference) if you have it.
Basically, just switch it up and try connecting to the site. If you get the same SSL/TLS handshake failed error, then you know it’s not the browser causing the issue. But if you can connect, now you know something is up with your plugins or settings.
The fastest way to fix this SSL/TLS handshake error-causing issue is just to reset your browser to the default settings and disable all your plugins. From there, you can configure the browser however you want, testing your connection with the site in question as you tweak things. This may take a little bit of time, but it’s really the only way to address the issue if your browser is misconfigured or is making mistakes.
A man-in-the-middle (MITM) is typically presented as a nefarious hacker that’s attempting to steal information or cause harm. That’s actually not always the case. A lot of programs and devices intercept traffic for inspection or some other non-malicious purpose like load balancing, and then send it along to the application server. This process technically constitutes a MITM, too.
Unfortunately, sometimes issues with those devices can cause a TLS handshake to fail. It could be something like a network firewall preventing the connection, or it could be a configuration on an edge device on the server-side network. So, this issue can actually be either a client- or server-side fix depending on the scenario.
Here’s the thing: If this issue is client-side, you risk exposing yourself if you jigger with the settings on your antivirus or VPN. There should generally be a way to whitelist or create an exception for the site in question. But NEVER drop your firewall or your antivirus just connect to a website. If the issue is server-side, it’s likely a configuration issue on an edge device.
Recently, Ross Thomas, was telling me about a device he dealt with once that was intercepting traffic and affixing a small data string to indicate it had passed inspection. That was causing the data to fail check-sum hashes and could also potentially mess with authentication.
Again, there are too many possible origins for me to narrow it down to a single fix here, but if you have a device inspecting or intercepting traffic, start there.
SSL/TLS Handshake Failed: Server-Side Errors
The majority of the time SSL/TLS handshake failures are the result of server-side issues. Some of these are easy to fix, some of them are a little more involved, and some might not be worth fixing at all.
Let’s take a look.
This is actually an error that can occur on both the client- and the server-side, and it can actually be something that’s not worth fixing depending on the context. When it comes to supporting protocols and ciphers, the most important piece of wisdom is: always move forward, never move backwards.
TLS 1.2 came out more than a decade ago, yet there are still a small segment of websites that don’t support it. In 2018, TLS 1.3 was finally published as RFC 8446 by the IETF. As of August 2020, Qualys SSL Labs reports that 98.4% of the Alexa top 150,000 sites support TLS 1.2 and 32.8% support TLS 1.3.
In the other direction, PCI DSS requirements mandate that all websites that collect payment card information end support for SSL 3.0 and TLS 1.0. And the four major browser makers — Google, Firefox, Apple & Microsoft — jointly announced TLS 1.1 would be deprecated by 2020.
If you’re getting the SSL/TLS handshake failed error as a result of a protocol mismatch, it means that the client and server do not have mutual support for the same TLS version. Here’s an example:
|Supports TLS 1.0, TLS 1.1||Supports TLS 1.2|
In this scenario, there is no mutually supported TLS protocol and the server likely isn’t supporting backwards versioning. And before you ask, no, the server shouldn’t fix this. In this example, the client should upgrade their browser, or, in the case that the browser is current — configure it to support the latest TLS versions.
At this point, you should be using TLS 1.2 or TLS 1.3. If you’re not, add support for them. But remember, never go backwards.
Cipher Suite Mismatch
This is incredibly similar to the protocol mismatch — just a bit more granular. SSL/TLS isn’t just one algorithm that handles everything (though ECC is close), it’s actually a collection of algorithms that serve different functions and work in conjunction to make up SSL/TLS.
SSL/TLS is like the Megazord and the cipher suite is like the Power Rangers.
What? You try to make a grouping of algorithms sound more interesting.
Anyway, while the cipher suites used by TLS 1.3 have been refined, traditionally a Cipher Suite has had algorithms that handle:
- Asymmetric public key encryption
- Symmetric session key encryption
- Key generation
- Signature hashing
Different industries and government agencies have different encryption standards that suggest different cipher suites. Generally, there’s a lot of overlap there, and most websites support a handful of cipher suites so that clients have several options and will generally be able to find a mutually agreeable cipher. Obviously, the odds of successful negotiation would decrease substantially if a site only supported a single cipher suite.
Oftentimes this can happen within a network if you’re performing SSL bridging, where an edge device receives and decrypts HTTPS traffic, then re-encrypts it so send along to the application server. If the edge device and the application server don’t share a mutually supported cipher suite, it will cause errors.
Much like with protocol versions, you should only ever move forward with cipher suites — never backwards. Remember, when a protocol version or cipher suite is deprecated it’s not because the industry is trying to be difficult — it’s because a vulnerability has been found or is imminent. So, going backwards only makes your connections potentially less safe.
Incorrect SSL/TLS Certificate
There are a number of different things that can make a browser view an SSL/TLS certificate as incorrect and prevent the handshake from completing successfully. We’ll go through each in the next sub-sections. It’s also worth noting that, sometimes, these issues will materialize into a different error on the client-side as opposed to the SSL/TLS handshake failed message. Generally, something along the lines of the website not providing a secure connection. But on a technical level that error is occurring as the result of a failed handshake.
|Host Name Mismatch||The CN in the certificate does not match the host name.|
|Incorrect Certificate Chain||The certificate chain is missing intermediates.|
|Expired/Revoked Certificate||The server presented an expired, revoked or untrusted certificate.|
|Self-Signed Replacements||(Internal Networks) Certificate replacements confused path.|
Incorrect Host Name
This used to be a problem with WWW and non-WWW versions of websites. However, this issue has largely been mitigated by the certificate authority community allowing one to be listed as a SAN (subject alternative name) domain free of charge. This issue can usually be fixed by re-issuing the certificate or sometimes by using a wildcard certificate.
Incorrect Certificate Chain
We went in-depth on certificate chains, roots and intermediate certificates in a previous article, but here’s the quick version. The trust model in SSL/TLS and PKI in general relies on meticulously-curated root programs. These are collections of trusted CA root certificates that literally live on a computer system.
|ROOT PROGRAM||USED BY|
|Mozilla||Firefox Desktop and Mobile|
These CA roots are invaluable — so much so that rather than risk issuing directly from them, certificate authorities spin up intermediate roots and sign SSL/TLS leaf (end-user) certificates with those intermediates. Here’s where the chain starts to come in. The Root CA certificate is used to digitally sign the intermediate roots. Those intermediates are used to sign other intermediates or end-user, leaf SSL/TLS certificates.
When a browser receives an SSL/TLS certificate, one of the things it does to check its authenticity is follows the signatures. It looks at the digital signature on the SSL/TLS certificate and follows it back to the intermediate root that signed it. Then it looks at that intermediate’s digital signature and follows it back to the certificate that signed the intermediate. So on and so forth until, eventually, it reaches one of the root CA certificates in its trust store.
If it can’t do this, the certificate chain is oftentimes incomplete, meaning that the browser couldn’t locate one of the intermediates and the SSL/TLS handshake failed. To remedy this, you’re going to need to find and install the missing intermediate certificate. Depending on which CA you purchased your certificate from, they should have their intermediates available on their website.
While certificate revocation in the current SSL/TLS ecosystem leaves a lot to be desired, there are still some contexts where a browser will see that a certificate has been revoked and will fail a handshake on that basis. More often, it’s as a result of an expired certificate. SSL/TLS certificates are only valid for a set amount of time.
SSL/TLS certificate expiration occurs for a few potential reasons (depending on whom you ask):
- To ensure that validation information stays accurate.
- To proliferate protocol and cipher updates more quickly.
- To eliminate the need for certificate revocation lists (CRLs).
- To combat the possibility of cybercriminals from breaking standard encryption algorithms (although this is virtually impossible without quantum computing).
As of Sept. 1, 2020, max validity for an SSL/TLS certificate is now one year (398 days to be exact). That means you need to be swapping out certificates regularly. If you forgot to before one expired, that’s probably why the SSL/TLS handshake failed. Just get a valid certificate issued and install it — that should solve your problems.
On the public internet, a self-signed certificate will return an error 100% of the time if the client hasn’t manually installed your private root in their root store. But, on internal networks self-signed certificates are fairly common. And if you swap them out enough, that can cause problems.
Most browsers will cache certificates so that upon return to a website it makes the handshake go faster. But if you’re generating new certificates at regular intervals, continuously adding all of those newly-generated certificates to the local database is going to cause confusion. Eventually, the browser will struggle with path-building and crash.
In the past, Firefox has struggled with this considerably — to the point where 7-8 certificate re-issues will cause significant latency, and 10 or more can cause the handshake to take upwards of 30 seconds.
This is more of an internal issue that exists between devices, but sometimes a client communicating with a server name indication server when it’s not SNI-enabled can be why the SSL/TLS handshake failed.
The first thing you’ll need to do is identify the host name and the port number of the server in question and make sure it’s SNI-enabled as well as that it’s communicating everything it needs to be. Again, this is usually less of a public-facing issue, but it can be the cause from time to time internally.
What Not to Do – Don’t Reward Bad SSL/TLS Implementations
A lot of the time website owners don’t want to make a change until there’s a problem they can’t ignore. While there are a few client-side fixes for the SSL/TLS handshake failed error, it’s generally going to be a server-side issue.
That means as a regular internet user, your options are limited when it comes to mitigating SSL/TLS handshake errors. The best thing to do is to inform the site owner of the problem and wait for them to fix it. If they don’t, it might be wise just to stop using the website.
- Don’t drop your firewall. You can usually whitelist a website, but don’t drop your firewall. Ever.
- Don’t disable your antivirus. Again, whitelist if possible, but keep it on and updated.
- Don’t connect via HTTP or click through interstitial warnings. This is bad any way you look at it and can result in a lot of issues.
If the website can’t offer a safe browsing experience, you shouldn’t be visiting it. Eliminating the SSL/TLS handshake error isn’t worth jeopardizing your security.
Note: This article on TLS handshake failed errors (SSL handshake failed errors) was originally written by Patrick Nohe on Nov. 14, 2018. It was updated and re-published by Casey Crane as a “rehash” of the content on Sept. 3, 2020.
As always, leave any comments or questions below…
*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Patrick Nohe. Read the original post at: https://www.thesslstore.com/blog/tls-handshake-failed/