Unspecified certificate verification error tls handshake set result code to 5

Occasional unspecified certficate verification error with PSK on Windows Server 2019

Details

Description

Steps to reproduce:

1. Upgraded both server and agents from 4.4.x to 5.0.6
2. Using active agent checks and TLS with PSK, on Windows servers

Server logs occasionally:

10377:20201216:125835.926 failed to accept an incoming connection: from 10.11.22.33: unspecified certificate verification error: TLS handshake set result code to 5:
10374:20201216:125835.928 failed to accept an incoming connection: from 10.22.33.10: unspecified certificate verification error: TLS handshake set result code to 5:
10374:20201216:125907.068 failed to accept an incoming connection: from 10.33.33.8: unspecified certificate verification error: TLS handshake set result code to 5:

At the same time client (10.11.22.33 agent above) logs:

12628:20201216:125833.259 active check data upload to [zabbix-server-ip:10051] started to fail ( [connect] TCP successful, cannot establish TLS to [ [zabbix-server-ip] :10051]: SSL_connect() timed out)
12628:20201216:125835.938 active check data upload to [zabbix-server-ip:10051] is working again

Expected:
No messages in the logs when agents connect and send data to server.

Initially we had server 4.4.10 on Debian Linux 9 (Stretch) and agents 4.4.x, and we didn’t have those errors.

Then we first changed the server to a new one with Debian Linux 10 (Buster) with server 4.4.10 (new installation, copied the configurations), and that’s when the error messages started.

We then upgraded both server and agents to 5.0.6, but the occasional errors continued. There are less errors though with 5.0.6.

Notable detail is that agents on Linux, on Windows 10 or on Windows Server 2016 do not cause these errors (agents are 4.0.x, 4.4.x or 5.0.6).

Debian 9 server (old server with no problems) openssl version: OpenSSL 1.1.0l 10 Sep 2019

Debian 10 server (current) openssl version: OpenSSL 1.1.1d 10 Sep 2019

Источник

Jira Integration with self signed cert throws unspecified certificate verification error even openssl works

Summary

We self host our JIRA and GitLab (Docker).
We want to integrate the JIRA Features in Gitlab like descripted here: https://docs.gitlab.com/ee/user/project/integrations/jira.html

We entered a valid administrator account in username / password-fields.
We entered a valid url (https://jira.DOMAIN.int:8443).
We looked for the right transition ID and entered it (71 in our case).

Error: Test failed. Save anyway.

The integration_json.log shows:
SSL_connect returned=1 errno=0 state=error: certificate verify failed (unspecified certificate verification error)

What we have done so far?

• entered the correct host in /etc/hosts
• download the self signed certificat with Chrome in 3 files (main certificat and 2 roots certificat)
• Run reconfigure in gitlab and see the output, that all 3 files are recognized in Recipe: gitlab::add_trusted_certs
• Look in the /opt/gitlab/embedded/ssl/certs and see 3 correct system links to the 3 files in /etc/gitlab/trusted-certs
• Run OpenSSL from Gitlab: Connected!

*root@c9cab22e6481:/etc/gitlab# echo | /opt/gitlab/embedded/bin/openssl s_client -connect jira.xxx.int:8443 CONNECTED(00000003) Can’t use SSL_get_servername depth=0 C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA verify return:1

Certificate chain 0 s:C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA i:C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA

——BEGIN CERTIFICATE—— MIIDVTCCAj2gAwIBAgIEU135NjANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJE RTEMMAoGA1UECBMDUkxQMQswCQYDVQQHEwJLTzEUMBIGA1UEChMLR09FUkxJVFog QUcxDDAKBgNVBAsTA0dPRTENMAsGA1UEAxMESklSQTAeFw0xODA3MjMxMDU0NTRa Fw0yMjA4MzExMDU0NTRaMFsxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNSTFAxCzAJ BgNVBAcTAktPMRQwEgYDVQQKEwtHT0VSTElUWiBBRzEMMAoGA1UECxMDR09FMQ0w CwYDVQQDEwRKSVJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjeh6 g6I5ErXj6ZaIf9f+RIHZRbDDjRxk1APXWN914iO6EA+l/tdGvSKY0e4WJu16hOPn klUYq+iaMKVE9LTezu7W1LZ2r+QiDMus7GV3z+x1wq3UZ8m/Mxnr4iiz6WIemWEY Gdifmsa6BVicai/RZs3sQeVpuO3qovKbKV1DxbJ9TX+g2OFrEYqwE6mZiRR23/kp IzOeNOlhWtVYyjRXpIMmyGpWE+/H3ijVIMKBe2UDb59ORsxILGIk9llfDBWw7e1h Zx7MfCwQ5tb5B75a1He4ROAolymYigszgU+lEwmFcM+cu58gfyU99eF/QaLESBSS J3ZMP5+6xt2s3bCxEQIDAQABoyEwHzAdBgNVHQ4EFgQU3SRIHlvXyp+CDR5SCNww ramoI8kwDQYJKoZIhvcNAQELBQADggEBAB/mB7rys9JHZdvxzXI9z068MjXVifcK jif2GoSV3LC1PQXET4OxcpLdEVCuZP9KFKOQBYriblrlxT7uXoipqZ0VNN7EgYNv ivEZcKV6+JtkASCJMD1Tv1iWqoKZeJHgu2EJVQUnL3ZOsl4u57awYAaou8u25O1s ZtRe4V6GKdgetsp98qMK0B0YLM2+Ot8Nb2sWE6m+gDbMizRblny9hbv9znJbNSWE WgDmPK+ZKJQyumXZU+oJ5bvmPfA79H69mqytHRl42d7ql9yQlscuBYGVHoxevOKk Z94kd889sAjF2dZR7nc2JN4rV1qUNDB4tHV+o0RTmw9hBMg+E6sPYa4= ——END CERTIFICATE——

subject=C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA

issuer=C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA

No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA Server Temp Key: ECDH, P-256, 256 bits

SSL handshake has read 1345 bytes and written 419 bytes Verification: OK

New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 5F0445083881A3E4B6DE86A7C1238D35F05BFBB914FD9F8E6F463C4CA87BFF03 Session-ID-ctx: Master-Key: 5CF9A153121058D6E1D9D3D0D63F8A17BB813ED22464FFA8A35398F8069D34580359299E6EA80E08413D9B2524714B7C PSK identity: None PSK identity hint: None SRP username: None Start Time: 1594115336 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes

• Run openssl x509 -in /etc/gitlab/trusted-certs/certificat.cer -text -noout

Certificate: Data: Version: 3 (0x2) Serial Number: 1398667574 (0x535df936) Signature Algorithm: sha256WithRSAEncryption Issuer: C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA Validity Not Before: Jul 23 10:54:54 2018 GMT Not After : Aug 31 10:54:54 2022 GMT Subject: C = DE, ST = RLP, L = KO, O = xxx AG, OU = GOE, CN = JIRA Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:8d:e8:7a:83:a2:39:12:b5:e3:e9:96:88:7f:d7: fe:44:81:d9:45:b0:c3:8d:1c:64:d4:03:d7:58:df: 75:e2:23:ba:10:0f:a5:fe:d7:46:bd:22:98:d1:ee: 16:26:ed:7a:84:e3:e7:92:55:18:ab:e8:9a:30:a5: 44:f4:b4:de:ce:ee:d6:d4:b6:76:af:e4:22:0c:cb: ac:ec:65:77:cf:ec:75:c2:ad:d4:67:c9:bf:33:19: eb:e2:28:b3:e9:62:1e:99:61:18:19:d8:9f:9a:c6: ba:05:58:9c:6a:2f:d1:66:cd:ec:41:e5:69:b8:ed: ea:a2:f2:9b:29:5d:43:c5:b2:7d:4d:7f:a0:d8:e1: 6b:11:8a:b0:13:a9:99:89:14:76:df:f9:29:23:33: 9e:34:e9:61:5a:d5:58:ca:34:57:a4:83:26:c8:6a: 56:13:ef:c7:de:28:d5:20:c2:81:7b:65:03:6f:9f: 4e:46:cc:48:2c:62:24:f6:59:5f:0c:15:b0:ed:ed: 61:67:1e:cc:7c:2c:10:e6:d6:f9:07:be:5a:d4:77: b8:44:e0:28:97:29:98:8a:0b:33:81:4f:a5:13:09: 85:70:cf:9c:bb:9f:20:7f:25:3d:f5:e1:7f:41:a2: c4:48:14:92:27:76:4c:3f:9f:ba:c6:dd:ac:dd:b0: b1:11 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: DD:24:48:1E:5B:D7:CA:9F:82:0D:1E:52:08:DC:30:AD:A9:A8:23:C9 Signature Algorithm: sha256WithRSAEncryption 1f:e6:07:ba:f2:b3:d2:47:65:db:f1:cd:72:3d:cf:4e:bc:32: 35:d5:89:f7:0a:8e:27:f6:1a:84:95:dc:b0:b5:3d:05:c4:4f: 83:b1:72:92:dd:11:50:ae:64:ff:4a:14:a3:90:05:8a:e2:6e: 5a:e5:c5:3e:ee:5e:88:a9:a9:9d:15:34:de:c4:81:83:6f:8a: f1:19:70:a5:7a:f8:9b:64:01:20:89:30:3d:53:bf:58:96:aa: 82:99:78:91:e0:bb:61:09:55:05:27:2f:76:4e:b2:5e:2e:e7: b6:b0:60:06:a8:bb:cb:b6:e4:ed:6c:66:d4:5e:e1:5e:86:29: d8:1e:b6:ca:7d:f2:a3:0a:d0:1d:18:2c:cd:be:3a:df:0d:6f: 6b:16:13:a9:be:80:36:cc:8b:34:5b:96:7c:bd:85:bb:fd:ce: 72:5b:35:25:84:5a:00:e6:3c:af:99:28:94:32:ba:65:d9:53: ea:09:e5:bb:e6:3d:f0:3b:f4:7e:bd:9a:ac:ad:1d:19:78:d9: de:ea:97:dc:90:96:c7:2e:05:81:95:1e:8c:5e:bc:e2:a4:67: de:24:77:cf:3d:b0:08:c5:d9:d6:51:ee:77:36:24:de:2b:57: 5a:94:34:30:78:b4:75:7e:a3:44:53:9b:0f:61:04:c8:3e:13: ab:0f:61:ae

• Flush trusted-certs-directory-hash with rm /var/opt/gitlab/trusted-certs-directory-hash

Источник

Rehash: How to Fix the SSL/TLS Handshake Failed Error

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.

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

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.

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

Related: Secure Your Website with a Comodo SSL Certificate.

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.

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

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

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.

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.

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.

Expired/Revoked Certificates

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.

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 10 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’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…

Patrick Nohe

Patrick started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. Patrick covers encryption, hashing, browser UI/UX and general cyber security in a way that’s relatable for everyone.

Источник

Hello. I’m trying to connect to a server with https. I have the certificate which is a self signed certificate which is being included in the verify parameter but the result is an error ‘certificate verify failed’ error. I was suspecting it had to do with the certificate being self signed (by Microsoft IIS) but with curl this works.
Thanks in advance!

This is the openssl output:

openssl s_client -showcerts -connect server:44300
CONNECTED(00000003)
depth=0 CN = server
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = server
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=server
   i:/CN=server
-----BEGIN CERTIFICATE-----
<certificate data here>
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=server
issuer=/CN=server
---
No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1477 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: CC4A000083B1E03B446416C9C0B16CBEAB79949E3CF5C936A309A6F92FA01364
    Session-ID-ctx:
    Master-Key: 798A570B0EC2A0CBB7C4C4DE6167E7579A92239942D869CD794B8BEBEA6EB5E492394634AD32665A8BB829DE1F3858D2
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1510329948
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

Expected Result

I’m expecting, since the certificate is in the verify parameter, that the connection won’t fail. If I try the same with curl outside python it works:

curl https://server:44300 --cacert /usr/share/ca-certificates/server.crt
 HTTP/1.1 403 Forbidden
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Length: 1158
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Frame-Options: SAMEORIGIN
P3P: CP=None
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Allow-Headers: X-Requested-With,Content-Type
Access-Control-Allow-Credentials: true
Date: Fri, 10 Nov 2017 16:02:26 GMT

(It fails but not because of certificate issues)

Actual Result

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/adapters.py", line 506, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='nlybstqvp4nb75n.code1.emi.philips.com', port=44300): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

Reproduction Steps

import requests
requests.get('https://server:44300', verify='/usr/share/ca-certificates/server.crt')

System Information

$ python -m requests.help

{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.1.3"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.12"
  },
  "platform": {
    "release": "4.10.0-38-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010007f",
    "version": "17.3.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

I will tell you my situation step by step and ask me any necessary questions and help me to fix hmail certificate issue.

First of all :
1-
i am using a windows server 2008 — r2

2-
latest hmail server downloaded from it’s web site

3-
a little VPS using with static ip

4-
no extra smtp server

5-
firewall is off

6-
smtp ports -> 25, 587 — 465 (ssl) are open | imap ports -> 143 — 993(ssl) are open

7-
How did you create your certificate?
I installed openSSL latest x64 no-light version on VPS.
And here is the cmd commands on server machine (not local) :

Way 1 : from hmail web site (Self Signed Certificate)

openssl genrsa -des3 -out your_certificatedomain_com.key 2048
openssl rsa -in your_certificatedomain_com.key -out your_certificatedomain_com.key
openssl req -new -key your_certificatedomain_com.key -out your_certificatedomain_com.csr

US
New York
Rochester
Almas Ltd
Security
mydomain.com
info@mydomain.com
Blank
Blank

openssl x509 -req -days 365 -in your_certificatedomain_com.csr -signkey your_certificatedomain_com.key -out your_certificatedomain_com.crt

openssl s_client -connect smtp.mydomain.com:465 

8-
How did you test your created certificate?
Here is the command and it’s result :

openssl s_client -connect smtp.mydomain.com:465 >> Log.txt


CONNECTED(00000110)
---
Certificate chain
 0 s:/C=US/ST=New York/L=Rochester/O=Almas Ltd/OU=Security/CN=mydomain.com/emailAddress=info@mydomain.com
   i:/C=US/ST=New York/L=Rochester/O=Almas Ltd/OU=Security/CN=mydomain.com/emailAddress=info@mydomain.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDsjCCApoCCQDupf4WHA0lRTANBgkqhkiG9w0BAQsFADCBmjELMAkGA1UEBhMC
VVMxETAPBgNVBAgMCE5ldyBZb3JrMRIwEAYDVQQHDAlSb2NoZXN0ZXIxEjAQBgNV
BAoMCUFsbWFzIEx0ZDERMA8GA1UECwwIU2VjdXJpdHkxGDAWBgNVBAMMD2dtYWls
YWNjb3VudC5ncTEjMCEGCSqGSIb3DQEJARYUaW5mb0BnbWFpbGFjY291bnQuZ3Ew
HhcNMTYwMTA1MTQyMDUzWhcNMTcwMTA0MTQyMDUzWjCBmjELMAkGA1UEBhMCVVMx
ETAPBgNVBAgMCE5ldyBZb3JrMRIwEAYDVQQHDAlSb2NoZXN0ZXIxEjAQBgNVBAoM
CUFsbWFzIEx0ZDERMA8GA1UECwwIU2VjdXJpdHkxGDAWBgNVBAMMD2dtYWlsYWNj
b3VudC5ncTEjMCEGCSqGSIb3DQEJARYUaW5mb0BnbWFpbGFjY291bnQuZ3EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCuPbmpoK0I1J/qPYC+G2CnVtY7
FxiXO6XUR2b1pVCvp2Cmo7dAbJ61mCo8SWwi7kRulJNnsqHpkD3EglrUmsjLIVMq
xsmqzwYzehV1+ydhVP/4b2DwIRnzojUgvklSY8wd07btOaUJF4/QBydu6IIRjngL
HU6PwxKP1CtBiIkbmCvnvrjElikpKAEmtZg0cIY5Z7mbaYAGN/VMoCToPSzmD6Ys
rrO0LD7p+334C59z/xI9O9o+PhspkN8xTuajycPFqudH9ZhuEzknUA82m8OF2ymZ
JW1Cu9crgC3xs73i4w/kl0k0SVD/yerEoJIOsdvtikHDFId/1EgKyMmpjJC/AgMB
AAEwDQYJKoZIhvcNAQELBQADggEBAFmLO2qT4TzlYY+MJ3+JdtmmAnj28vzVuaug
Q0vJNa8WlC9qPmK8jPMl2MNan+6GvC3w7EpkBZ6T+5ofXZaqJg72ITHMPHZdYcga
e0T6l1CxcptQeLwZww0ZEi4HS845zQhuE+aGbrSYCfHRIhFcPIfOGuHNEM0yBZeF
tMpnu+0LRmhm2A0o0S6OSVkdYnywHYrZnyPunD6bWart+NFwGZ/Vk6cW0MQW1mB5
v/uwI2tpE/QB1n263ui0o8G/WhGE7XkDmj61kfCWh77akeIowKaMYDr6+/lnsupK
+1QoMJ1KjQr5GwPPHsQmE88IaaH+cRCy0FqglV8KliFQHECgIBY=
-----END CERTIFICATE-----
subject=/C=US/ST=New York/L=Rochester/O=Almas Ltd/OU=Security/CN=mydomain.com/emailAddress=info@mydomain.com
issuer=/C=US/ST=New York/L=Rochester/O=Almas Ltd/OU=Security/CN=mydomain.com/emailAddress=info@mydomain.com
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1609 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 93C68F70C836320E98476E0578BAA1BC30CEB69A2496910D80A612DAFE812AD6
    Session-ID-ctx: 
    Master-Key: A181E823F19A24D3E116B00807AED917E925539DB001B3D0B5B881C656F3B1861501857EFB3E160800F3BB20E9F077E9
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 8d 7d 83 3f 45 70 db dd-ea ce 81 6f 4b 4e bb cf   .}.?Ep.....oKN..
    0010 - 28 8b 65 e6 1c 62 03 4c-79 ad 8b 00 76 2b a4 24   (.e..b.Ly...v+.$
    0020 - dd 8d 7a f8 2c 28 3c 2c-24 8f c8 6d d6 29 ea c8   ..z.,(<,$..m.)..
    0030 - b8 bc cc db 23 02 83 ac-a6 f0 2b 68 64 9d e0 85   ....#.....+hd...
    0040 - a5 e6 09 ab ad af e6 74-e0 94 8d b4 a0 fc 79 3d   .......t......y=
    0050 - d8 3c d2 1f 49 8b 1f 06-da c0 63 59 46 cb 21 5b   .<..I.....cYF.![
    0060 - d7 d6 42 0a 29 a3 2c bd-83 c8 a0 d0 fd 6b fc 97   ..B.).,......k..
    0070 - 38 65 ef 80 8c bd 63 d9-5f aa 8e f4 18 f3 1c 2b   8e....c._......+
    0080 - e5 8e 55 96 9c 74 de 3f-1f 43 f1 d2 2d 34 80 fe   ..U..t.?.C..-4..
    0090 - f5 b8 fc e5 ee 41 92 e2-7b 52 cc 88 97 9b c0 4d   .....A..{R.....M

    Start Time: 1452065550
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
220 Hi, you are connected to SMTP server
221 goodbye

9-
And here is the log of hmail for using telnet command inside vps :

telnet smtp.mydomain.com 465


"DEBUG" 3792    "2016-01-06 11:02:30.203"   "Creating session 108"
"TCPIP" 3792    "2016-01-06 11:02:30.203"   "TCP - 23.93.218.54 connected to 23.93.218.54:465."
"DEBUG" 3792    "2016-01-06 11:02:30.205"   "TCP connection started for session 106"
"DEBUG" 3792    "2016-01-06 11:02:30.205"   "Performing SSL/TLS handshake for session 106. Verify certificate: False"
"TCPIP" 3792    "2016-01-06 11:02:30.275"   "TCPConnection - TLS/SSL handshake completed. Session Id: 106, Remote IP: 23.93.218.54, Version: TLSv1.2, Cipher: ECDHE-RSA-AES256-GCM-SHA384, Bits: 256"
"SMTPD" 3792    106 "2016-01-06 11:02:30.275"   "23.93.218.54"  "SENT: 220 Hi, you are connected to SMTP server"
"SMTPD" 4416    106 "2016-01-06 11:03:09.278"   "23.93.218.54"  "RECEIVED: quit"
"SMTPD" 4416    106 "2016-01-06 11:03:09.278"   "23.93.218.54"  "SENT: 221 goodbye"
"DEBUG" 3632    "2016-01-06 11:03:09.281"   "Ending session 106"
"DEBUG" 3792    "2016-01-06 11:06:44.774"   "Creating session 109"
"TCPIP" 3792    "2016-01-06 11:06:44.775"   "TCP - 23.93.218.54 connected to 23.93.218.54:465."
"DEBUG" 3792    "2016-01-06 11:06:44.777"   "TCP connection started for session 108"
"DEBUG" 3792    "2016-01-06 11:06:44.778"   "Performing SSL/TLS handshake for session 108. Verify certificate: False"
"TCPIP" 3792    "2016-01-06 11:06:58.755"   "TCPConnection - TLS/SSL handshake failed. Session Id: 108, Remote IP: 23.93.218.54, Error code: 336027900, Message: unknown protocol"
"DEBUG" 3792    "2016-01-06 11:06:58.756"   "Ending session 108"

10-
Here is the pictures :
image 1

image 2

Please tell me what this is mean : Verify certificate: False
And how can i fix TCPConnection — TLS/SSL handshake failed?

In person, a handshake can be used to greet someone or finalize an agreement with them. The same is true online.

When devices on a network — say, a browser and a web server — share encryption algorithms, keys, and other details about their connection before finally agreeing to exchange data, it’s called an SSL handshake. During this handshake, the browser and server might ask to see each other’s SSL certificates to verify them.

This handshake is essential for establishing a secure connection before transferring data, so it’s important to understand what an SSL handshake is and what to do if it fails.

Note: SSL and TLS are both cryptographic protocols that enable clients and servers operating over a network to communicate with each other securely. TLS has replaced SSL, but SSL is still a more commonly used term so we’ll continue to use it in this post.

SSL Handshake Steps

The exact steps in an SSL handshake vary depending on the version of SSL the client and server decide to use, but the general process is outlined below.

1. The client says hello. This “client hello” message lists cryptographic information, including the SSL version to use to communicate with each other. It also lists which encryption algorithms it supports, which are known as Cipher Suites.
2. The server responds hello. This “server hello” message contains important information, like which CipherSuite it chose, and its digital certificate. It might also request the client’s certificate.
3. The client verifies the server’s certificate. It also sends several byte strings, including one for allowing both the client and the server to compute a secret key for encrypting subsequent messages, including the “finished” messages. If the server sends a client certificate request, it will also send a byte string encrypted with its own private key and digital certificate.
4. The server verifies the client’s certificate. This step only takes place if client authentication is required.
5. The client says “I’m finished.” This “finished” message indicates that the client has completed its part of the handshake.
6. The server says “I’m finished, too.” This “finished” message indicates that the sever has completed its part of the handshake.

For the remainder of the session, the server and client can now exchange messages that are encrypted with the same secret key, which was shared in step three. This is known as symmetric encryption. You can learn more about symmetric encryption, and how it differs from asymmetric encryption, in this post.

The steps above will occur if the process goes smoothly. But what if it doesn’t? Below we’ll walk through how to resolve an “SSL Handshake Failed” error message.

What is SSL Handshake Failed?

SSL Handshake Failed is an error message that occurs when the client or server wasn’t able to establish a secure connection.

This might occur if:

• The client is using the wrong date or time.
• The client is a browser and its specific configuration is causing the error.
• The connection is being intercepted by a third party on the client-side.
• The client and server do not support the same SSL version.
• The client and server are using different Cipher Suites.
• The client or server’s certificate is invalid.

The SSL Handshake Failed error message may appear differently, depending on the client application you’re using or server you’re trying to communicate with. For example, in GitHub, it will look something like this:

Image Source

If you’re using Cloudflare, on the other hand, an SSL Handshake Failed will appear as a 525 error that looks something like this:

Image Source

Now that you know some of the causes of the SSL Handshake Failed error, let’s look at some solutions.

1. Correct the time and date on the client device.

Let’s start with the easiest fix. If the system time and date is incorrect on your computer or device, then it can cause the SSL Handshake Failed error. That’s because time is essential when it comes to SSL certificates: they have finite lifespans and become invalid past their expiration date.

If you check your system time and date and it’s correct, then move on to the next step.

2. Try another browser.

It’s possible that the browser you’re using is causing the SSL Handshake Failed error. It could be your settings, browser plugins, or another issue. To see if this is the problem, just switch to another browser.

Let’s say you were trying to connect to a website using Google Chrome, and it works just fine in Safari. In that case, you’ll have to narrow down what the problem is. Go back and reset Google Chrome (or whatever browser you were using) to its default settings and disable all your plugins. Then re-configure your settings and enable your plugins one-by-one, testing your ability to connect to the website each time. You should be able to isolate the specific setting or plugin that caused the SSL Handshake Failed that way.

If you try another browser and you still see the SSL Handshake Failed error, then move on to the next step.

3. Add website to allowlist.

It’s also possible that your firewall is causing the SSL Handshake Failed error by intercepting your request for inspection. To rule it out as the cause, you can temporarily deactivate your firewall —but that can leave you vulnerable to attack.

Instead, try adding the website to your allowlist. Here’s the process for Google Chrome:

• On your admin console homepage, go to Devices > Chrome.
• Click Settings> Users & browsers.
• Leave the top organizational unit selected (it’s selected by default). This will apply the setting to all users and enrolled browsers.
• Scroll to URL Blocking and enter the website you are trying to access under Blocked URL exceptions.
• Click Save.

If you try visiting that site again and you still see the SSL Handshake Failed error, then move on to the next step.

4. Update browser to use the latest SSL protocol.

It’s possible that you’re getting the SSL Handshake Failed error because your device (the client) and server do not support the same SSL version, which is resulting in a protocol mismatch. For example, let’s say your browser only supports TLS 1.1 and your server only supports TLS 1.2 or 1.3 (the latest version). If these two try to establish a secure connection, then it will likely result in an SSL Handshake Failed error.

In that case, you’ll need to update your browser. Most updated versions of major browsers like Google Chrome have TLS 1.2 automatically enabled. However, even if it is updated, it’s important to make sure it’s configured to to support the latest TLS version.

Here’s the easiest way to check:

• Visit SSL Labs.
• Navigate to Projects.

• Click SSL Client Test.

• Under Protocol Support, it will tell you whether your browser supports the latest versions of TLS.

If you verify that your browser and server are using the same protocol, then move on to the next step.

5. Check browser and server support for Cipher Suites.

Another reason you could be getting the SSL Handshake Failed error is that the client and server are using different Cipher Suites. Just like a protocol mismatch, a client and server who do not have mutual support for the same CipherSuite will not be able to establish a secure connection.

You can compare which Cipher Suites your browser support to which the server of the website you’re trying to visit supports by once again visiting SSL Labs.

• First, navigate to Projects.
• Click SSL Client Test.
• Scroll down to Protocol Features, where it will list which Cipher Suites your browser supports, in order of preference.

• Now, open SSL Labs in another tab, and navigate to Projects.
• Click SSL Server Test.
• Type in the domain name you are trying to visit that is resulting in the SSL Handshake Failed error.

• Scroll down to Configuration, where it will list which Cipher Suites the server supports, in order of preference.

If you verify that your browser and server are using the same CipherSuite, then move on to the next step.

6. Verify your SSL certificate is accurate and valid.

Any number of issues on an SSL certificate can prevent an SSL handshake from being completed. This may result in an SSL Handshake Failed error or another error message that ultimately means the handshake failed. For example, you might see something like this:

Image Source

If the SSL certificate has an incorrect host name, for example, or it’s past its expiration date, then the handshake will likely fail. So it’s important to ensure your SSL certificate is installed correctly and renewed when needed.

You can use an online tool like the above-mentioned SSL Server Test or SSL Shopper to test that your SSL configuration is installed, valid, and trusted in just a few minutes.

When a Client and Server Don’t Want to Shake Hands

Since an SSL handshake is an essential step in keeping data transferred over the internet secure, it’s important that users understand what the SSL Handshake Failed error means and how to fix it. By following the steps above, you should be able to resolve the issue and establish a secure connection between your device and the server you’re trying to connect to.