iOS / Safari handshake failure

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:
I visited https://www.ssllabs.com/ssltest/analyze.html?d=politipoint.org

It produced this output:
under the safari/ios section:
|Safari 6 / iOS 6.0.1|Server sent fatal alert: handshake_failure|
|Safari 7 / iOS 7.1 R|Server sent fatal alert: handshake_failure|
|Safari 7 / OS X 10.9 R|Server sent fatal alert: handshake_failure|
|Safari 8 / iOS 8.4 R|Server sent fatal alert: handshake_failure|
|Safari 8 / OS X 10.10 R|Server sent fatal alert: handshake_failure|

My web server is (include version):
nginx version: nginx/1.14.0 (Ubuntu)

The operating system my web server runs on is (include version):
Operating System: Ubuntu 18.04.1 LTS
Kernel: Linux 4.15.0-122-generic
Architecture: x86-64

My hosting provider, if applicable, is:
digital ocean

I can login to a root shell on my machine (yes or no, or I don't know):
yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 0.31.0

I set up ssl with let's encrypt recently and got feedback from iOS/Safari user that they are getting a "Connection is not private" error. This seems to relate to handshake error I see when visiting: https://www.ssllabs.com/ssltest/analyze.html?d=politipoint.org

thank you!

1 Like

I think a handshake error would result in a very different error. The handshake error would also mean your user is using Safari 8 or older.. Which is like, ancient. Safari 8 and older are only supporting weak cipher suits. Those cipher suits are not enabled on your server, for good reason.

So I would recommend you verify the version of Safari with the user in question. If they are using Safari 8 or older, recommend to upgrade their browser to a more secure version. If they are using Safari 9 or newer, there's another issue at play and that would require more information.

3 Likes

To harden (or soften) your security to prevent attempts to use weak cipher suites (or allow them), you should consider which cipher suites are allowed by your server.

This will provide you with information about the different suites (and let you choose weaker ones):

* This post was updated to reflect the excellent analysis by @JuergenAuer posted below.

1 Like

It looks pretty hardened to me? It also looks like the default certbot nginx settings.. Which is based on the "Intermediate" recommendation of Mozilla.

Not sure what you think is wrong here: you should probably take it up with the certbot developers :wink:

2 Likes

Hi @WillCarter here's an easy read.

2 Likes

Hi @WillCarter

the Ssllabs - result says: Your configuration is too hard.

If you want to support some of the older clients, you have to allow some of the older Cipher suites.

2 Likes

I don't think the issue in this thread is a handshake error. Your Stack Overflow-thread clearly has an error explicitly mentioning the handshake error while the error mentioned in this thread is a generic "Connection is not private" error.. I think it's not the same.

2 Likes

@Osiris

The link from @Rip specifically mentions support for ciphers. I think your antagonism setting is set a bit high today. :wink:

1 Like

@griffin The text your quoting is just the output from SSLLabs. It is by no means proof of the actual situation of the user experiencing the error mentioned in the OP. You're letting you to be guided by assumptions of the OP, which might be the wrong assumptions.

Assuming I'm correct :stuck_out_tongue: I'd advice you to read more carefully.

2 Likes

PS: Checked your domain - https://check-your-website.server-daten.de/?q=politipoint.org#ct-logs

Issuer not before not after Domain names LE-Duplicate next LE
Let's Encrypt Authority X3 2020-10-28 2021-01-26 politipoint.org, www.politipoint.org - 2 entries duplicate nr. 2
Let's Encrypt Authority X3 2020-10-22 2021-01-20 politipoint.org - 1 entries duplicate nr. 1
Let's Encrypt Authority X3 2020-10-22 2021-01-20 politipoint.org, www.politipoint.org - 2 entries duplicate nr. 1
Let's Encrypt Authority X3 2020-10-21 2021-01-19 politipoint.org - 1 entries

Now you use the certificate with both domain names.

May be you have used the certificate with one domain name - then the www version would show that error.

But now, it's good.

2 Likes

You may very well be right, considering the post from @JuergenAuer above this one. We're all speculating though.

1 Like

Thank you @Osiris @griffin @JuergenAuer @Rip

I think I agree now that the handshake error is not related to the "Connection is not private" error that the user reported.

I have not been able to get the user's iOS version/Safari version yet, but have a request out to her.

My goal was to set up 2 different domains (politipoint.org and hikefinder.net) pointing to 2 different sites on the same server with ssl, nginx, and using a reverse proxy in my config. I thought I had it working. But the user reported the following (screenshots from her iphone/safari)
https://res.cloudinary.com/fergusdev/image/upload/v1603913157/politipoint/error/ios_pol_vtissv.png

So, it looks like when she went to politipoint.org, it incorrectly looked at the hikefinder.net certificate, likely causing the error?

I have since removed the hikefinder.net certificate and references to hikefinder.net in my nginx configs, as it is not as important currently and removing that variable. Her phone should only find the politipoint.org certificate now.

I also changed the ciphers as was instructed above and the test now comes back without handshake errors. But I think this is not related to user's error as was mentioned.

If you have any insight in what want to do...

  1. 2 different websites on same server, running on 2 different ports
  2. 2 domains, hikefinder.net and politipoint.org. I want these ssl, using reverse proxy. How can I prevent it from looking at the wrong cert?

I am still waiting to get user's iOS, safari version.

thanks again!

2 Likes

The online check can't reproduce that result. There the certificate is correct.

What's the time zone of that screenshot (how old)? Did you change your configuration later?

1 Like

the screenshot showing hikefinder.net is from 2 hours ago, 11:30am mtn. I have not gotten a test / screenshot from her since I deleted the hikefinder.net certificate and removed hikefinder.net from my nginx configs.

if it works for her now, i will know something.

1 Like

Why two different ports?

SNI

1 Like

well, let me clarify. there are actually 4 websites on that server:
http://138.68.23.63:8686/ (politipoint front end, node based)
http://138.68.23.63:3030/ (politipoint front api/backend, rails based)
http://138.68.23.63:8282/ (hikefinder.net front end, node based)
http://138.68.23.63:3000/ (hikefinder.net front api/backend, rails based)

in my politipoint.org.conf I set up these reverse proxies:

reverse proxy

location /api {
    proxy_pass http://127.0.0.1:3030/;
    include    nginxconfig.io/proxy.conf;
}

location / {
    proxy_pass http://127.0.0.1:8686/;
    include    nginxconfig.io/proxy.conf;
}

so that https://politipoint.org/api hits the api site at 3030

1 Like

I had the same setup as above for hikefinder.net and it seemed to work until this one user's issue. Hikefinder.net stuff is deleted now.

1 Like

There are several ways to go about solving this. Honestly though, the simplest way may be to just acquire a SAN certificate with all four domain names since all of your various applications are using the same IP address anyway. This would avoid concerns with SNI since your certificate would cover everything anyhow.

sudo certbot certonly --cert-name mycert --webroot -w /path/to/politipoint.org/webroot/folder -d "politipoint.org,www.politipoint.org" -w /path/to/hikefinder.net/webroot/folder -d "hikefinder.net,www.hikefinder.net"

The common name on the cert would be politipoint.org, but the cert would contain subject alternative names (SANs) for all four names and thus could be validly served for any of them.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.