iOS / Safari handshake failure

WillCarter · October 28, 2020, 5:24pm

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

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!

Osiris · October 28, 2020, 5:31pm

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.

griffin · October 28, 2020, 6:23pm

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.

Osiris · October 28, 2020, 6:30pm

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

Rip · October 28, 2020, 6:42pm

Hi @WillCarter here's an easy read.

JuergenAuer · October 28, 2020, 6:50pm

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.

Osiris · October 28, 2020, 6:55pm

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.

griffin · October 28, 2020, 6:57pm

@Osiris

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

Osiris · October 28, 2020, 7:01pm

@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 I'd advice you to read more carefully.

JuergenAuer · October 28, 2020, 7:02pm

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

griffin · October 28, 2020, 7:09pm

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

WillCarter · October 28, 2020, 7:36pm

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

2 different websites on same server, running on 2 different ports
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!

JuergenAuer · October 28, 2020, 7:38pm

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?

WillCarter · October 28, 2020, 7:44pm

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.

griffin · October 28, 2020, 8:01pm

Why two different ports?

SNI

WillCarter · October 28, 2020, 8:10pm

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

WillCarter · October 28, 2020, 8:12pm

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.

griffin · October 28, 2020, 10:01pm

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.

system · November 27, 2020, 10:01pm

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

Topic		Replies	Views
SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking Help	34	10379	September 8, 2023
Server sent fatal alert: handshake_failure Help	4	1326	December 3, 2021
2 Problems with my certificate Help	27	3297	May 16, 2020
Server sent fatal alert: handshake_failure Help	6	3881	October 3, 2020
Let's encrypt certificate not accepted by Safari and Chrome on iOS 16.2 Help	6	3920	June 17, 2023

iOS / Safari handshake failure

reverse proxy

Related Topics