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, this 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.
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.
The TLS Handshake 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 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 AES keys – that are generated client side. When a symmetric key is generated, both parties get a copy and can use it to both encrypt and decrypt.
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 handshake is for, it’s a set of checks where the client and server authenticate one another, 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 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 uses a handshake that makes multiple roundtrips between the client and the server.
We’re not going to go step-by-step, but essentially, the client and server ping one another, the SSL/TLS certificate is presented, the client authenticates it, they exchange a list of supported cipher suites and agree on one, then key exchange occurs.
TLS 1.3 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 – 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 they’re 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.
Taking a Closer Look at the SSL/TLS Handshake
In Everything Encryption By Patrick Nohe
There’s a lot going on underneath the hood when you connect to a website via HTTPS. First and foremost, everyone needs to… shake hands?!
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 and who can fix them, then a little later on we’ll have a dedicated section for each where we’ll cover how to fix them.
| CAUSE | DESCRIPTION | 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 | Protocol used by client is not supported by server | Server |
| Cipher Suite Mismatch | Cipher Suite used by client is not supported by server | Server |
| Incorrect Certificate |
| Server |
| SNI-Enabled Server | Client can’t communicate with SNI-enabled server | Server |
Now let’s dive into fixing these problems and what can be done, 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.
Really, it’s just TLS configuration at this point as support for SSL 3.0 has been almost entirely deprecated.
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 updated.
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.
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.
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.
Obviously, don’t do this. If you’re still getting the SSL/TLS handshake failed error and your system time is correct, the issue is originating somewhere else.
Browser Error
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 it down to a literal browser error is pretty simple: just try another browser.
If you’re using Google Chrome, switch to your OS’s native browser like Apple Safari or Microsoft Edge, or hop on Mozilla Firefox (my preference) if you have it.
Just switch it up and try connecting to the site. If you get the same SSL/TLS handshake failed error you know it’s not the browser. But if you can connect, now you know something is up with your plugins or settings.
The fastest way to fix this 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 making mistakes.
Man-in-the-Middle
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 purpose like load balancing, and then send it along to the application server. This 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 can 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.
Protocol Mismatch
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 ten years ago yet there are still a small segment of websites that don’t support it. Earlier this summer TLS 1.3 was finally published as RFC 8446 by the IETF. Sites are being advised to add support for TLS 1.3 at their earlier convenience.
In the other direction, PCI DSS requirements recently mandated 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:
| CLIENT | SERVER |
| 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. 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 go down 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 is 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.
| ISSUE | DESCRIPTION |
| 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, but that’s generally been mitigated by the Certificate Authority community allowing one to be listed as a SAN 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 a few months ago, but here’s the quick version. The trust model in SSL/TLS and PKI in general relies on meticulously-curated root programs, which are collections of trusted CA root certificates that literally live on a computer system.
| ROOT PROGRAM | USED BY |
| Mozilla | Firefox Desktop and Mobile |
| Android OS | |
| Apple | iOS, macOS |
| Microsoft | Windows |
These CA roots are invaluable, so much so that rather than risk issuing directly off of 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 what CA you purchased your certificate from, it should have its intermediates available on its website.
Expired/Revoked Certificates
While 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.
RELATED: This is what happens when your SSL/TLS certificate expires
SSL/TLS certificate expiration occurs for two reasons:
- To ensure that Validation information stays accurate
- To proliferate protocol and cipher updates more quickly
Right now max validity for an SSL/TLS certificate is two years (27 months because CAs will let you carry up to three months over from your previous certificate). Eventually, it may be as short as six months. That means you need to be swapping out certificates regularly. If you forgot to, that’s probably why the SSL/TLS handshake failed. Just get a valid certificate issued and install it – that should solve your problems.
Self-Signed Replacements
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 ten or more can cause the handshake to take upwards of 30 seconds.
SNI-Enabled Servers
This is more of an internal issue that exists between devices, but sometimes a client communicating with a Server Name Indication server when it is 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 time website owners don’t want to make a change until it creates 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 server-side.
That means as a regular internet user, your options are limited. 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. There are some things you definitely should never do to reach a 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 updated and on.
- Don’t connect via HTTP or click through interstitial warnings
If the website can’t offer a safe browsing experience, you shouldn’t be visiting it.
As always, leave any comments or questions below…
扫一扫
605
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
