ERROR: Fetching the page failed because SSL handshake error


#21

Your post seriously helped me. Thank you! I kept getting handshake errors from Twitter when trying to test various Twitter cards. It turns out that it was indeed SNI issues associated with Apache.

Note to others who have a CN (Common Name) associated with your SSL that uses a wildcard (e.g. *.mydomain.com) you will have to set a ServerName and a ServerAlias in your VirtualHost to account for that. For example:

ServerName mydomain.com
ServerAlias *.mydomain.com

This SO article explains wildcard support in more detail: https://serverfault.com/questions/139628/servername-wildcards-in-apache-name-based-virtual-hosts/139629#139629?newreg=523b41dfd9754959b21fcbc7b2ae3912


#22

Hi
I am getting the ERROR: Fetching the page failed because SSL handshake error. , for website



Please let me know how can i resolve this issue .
I am using godaddy hosting so i dont have the apache folder access to modify the serverName and serverAlias

The certificate Signature algorithm = SHA256 + RSA

Any help would be appreciated
Thanks


#23

You’ll need to talk to your host about this.

Running your site through SSLLabs checker https://www.ssllabs.com/ssltest/analyze.html?d=www.loginextsolutions.com

The key lines here are towards the middle of the report, specifically the errors “Client aborts on SNI unrecognized_name warning” which is what causes the crawler to be unable to connect to your site.


#24

This error has been evading us too for sharing a video on a Twitter timeline, e.g. the video on https://beyourself.crohnsandcolitis.org.uk/cards/beyourself/
The player is at https://beyourself.crohnsandcolitis.org.uk/cards/beyourself/player.html

I’m fairly certain the twitter tags are correct (pasted at the bottom). Similarly, on Facebook, the still image displays but not the video in the timeline (with no errors reported), and I wonder if that is down to the same issue as on Twitter. But we don’t know what needs to change on the domain. We are using nginx, so the apache solution doesn’t apply. We believe that SNI is covered.

On https://www.ssllabs.com/ssltest/analyze.html?d=beyourself.crohnsandcolitis.org.uk
the domain gets an overall A rating, with maximum scores on everything except DNS CAA, linked to more info at:
https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum

Can that be relevant to the problem, or should we be looking elsewhere? Any help would be appreciated.

    <meta name="twitter:url" content="https://beyourself.crohnsandcolitis.org.uk/cards/beyourself/">
    <meta name="twitter:card" content="player">
    <meta name="twitter:site" content="@CrohnsColitisUK">
    <meta name="twitter:title" content="Be yoursELF for Crohn’s and Colitis Awareness Week">
    <meta name="twitter:description" content="Be yoursELF | Crohn’s & Colitis UK.
We are making the invisible visible…">
    <meta name="twitter:image" content="https://beyourself.crohnsandcolitis.org.uk/assets/video/video-poster-preview.jpg">
    <meta name="twitter:player" content="https://beyourself.crohnsandcolitis.org.uk/cards/beyourself/player.html">
    <meta name="twitter:player:width" content="1280">
    <meta name="twitter:player:height" content="720">
    <meta name="twitter:player:stream:content_type" content="video/mp4">
    <meta name="twitter:player:stream" content="https://beyourself.crohnsandcolitis.org.uk/videos/beyourself/beyourself.mp4">
    <meta name="twitter:image" content="https://beyourself.crohnsandcolitis.org.uk/assets/video/video-poster-preview.jpg" />
    <meta name="twitter:image:alt" content="Animated Elf card for Crohn’s and Colitis Awareness Week" />

[EDIT]: SSL settings in the nginx conf for the domain

    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_ecdh_curve secp384r1;
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;

    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    expires 5m;
    add_header Cache-Control "must-revalidate, proxy-revalidate";

#25

Unfortunately although the SSL checker site shows you that “A” rating, it also shows (further down the page) that a Java app attempting to negotiate an SSL handshake fails. That’s the most likely cause of the error and I’m not sure what you’d need to change on the server side, but it looks like an SSL/TLS handshake issue.


#26

Thanks Andy. I had missed that. So maybe it is a mismatch of protocol or cipher suite between the java app and the server.

The ssl response coming from the domain is:

The java app on the site checker has these capabilities:
https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=8u31&key=86

They are both using TLS 1.2. I can’t see that there’s a mismatch between the cipher capabilities(?)
The nginx ssl ciphers are ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384.


#27

We’ve received a good suggestion about this. I’ll report back.


#28

Finally cracked this, thanks to some help from @SynchroM on a mailinglist. He pointed me at the testssl.sh tool and suggested that I add TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 to my nginx ssl_ciphers line.

I did this, but testssl.sh -e beyourself.crohnsandcolitis.org.uk was still showing none of those ciphers, even after an nginx restart.

Then I changed the ssl_ciphers to only include those ciphers, but nginx -t then reported an error:

ginx: [emerg] SSL_CTX_set_cipher_list("TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256") failed (SSL: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match)
nginx: configuration file /etc/nginx/nginx.conf test failed

which clued me in to the fact that you need to look at nginx and openssl. Running openssl ciphers -v showed neither of those two ciphers, so I needed to pick ciphers that the Java client understood and that my install of openssl supported.

Again, @SynchroM to the rescue, he pointed me at https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=8u31&key=86 which lists the Java client’s ciphers, and https://testssl.sh/openssl-rfc.mapping.html which maps them to openssl.

Open SSL                        Cipher Suite
--------------------------------------------------------------------
AES128-SHA	                    TLS_RSA_WITH_AES_128_CBC_SHA		
DHE-DSS-AES128-SHA	            TLS_DHE_DSS_WITH_AES_128_CBC_SHA		
DHE-RSA-AES128-SHA	            TLS_DHE_RSA_WITH_AES_128_CBC_SHA		
AES128-SHA256 	                TLS_RSA_WITH_AES_128_CBC_SHA256		
DHE-DSS-AES128-SHA256	        TLS_DHE_DSS_WITH_AES_128_CBC_SHA256		
DHE-RSA-AES128-SHA256	        TLS_DHE_RSA_WITH_AES_128_CBC_SHA256		
AES128-GCM-SHA256	            TLS_RSA_WITH_AES_128_GCM_SHA256		
DHE-RSA-AES128-GCM-SHA256	    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256		
DHE-DSS-AES128-GCM-SHA256	    TLS_DHE_DSS_WITH_AES_128_GCM_SHA256		
ECDH-ECDSA-AES128-SHA	        TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA		
ECDHE-ECDSA-AES128-SHA	        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA		
ECDH-RSA-AES128-SHA	            TLS_ECDH_RSA_WITH_AES_128_CBC_SHA		
ECDHE-RSA-AES128-SHA	        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA		
ECDHE-ECDSA-AES128-SHA256	    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256		
ECDH-ECDSA-AES128-SHA256	    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256		
ECDHE-RSA-AES128-SHA256	        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256		
ECDH-RSA-AES128-SHA256	        TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256		
ECDHE-ECDSA-AES128-GCM-SHA256	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256		
ECDH-ECDSA-AES128-GCM-SHA256	TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256		
ECDHE-RSA-AES128-GCM-SHA256	    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256		
ECDH-RSA-AES128-GCM-SHA256	    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256				

I ended up adding all of them…

AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDH-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDH-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-GCM-SHA256

to my ssl_ciphers line:

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDH-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDH-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-GCM-SHA256;

and finally! The Twitter card validator can handshake.


#29

Working backwards, strongest first, ECDHE-RSA-AES128-GCM-SHA256 is all I actually need to add.

Here’s the relevant part of the nginx config:

ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256;
ssl_ecdh_curve secp384r1;
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

It’s A rated at https://www.ssllabs.com/ssltest/analyze.html?d=beyourself.crohnsandcolitis.org.uk and passes the https://cards-dev.twitter.com/validator


#30

Thanks for sharing the solution, that’s super-helpful!