"ERROR: Fetching the page failed because SSL handshake error."



I’ve been trying to validate the card markup for the domain nextpeak.co. When I’m not using a https url, the validator works fine, but after submitting a https url to the validator, I’m getting a “ERROR: Fetching the page failed because SSL handshake error.”

I have been in contact with my hoster (http://uberspace.de) and they think it’s because the uberspace servers are using too secure SSL and the java on twitter’s servers isn’t able to handle that.

Test URL for the validator: https://nextpeak.co/checkin/NZjlDajz

The domain nextpeak.co gets a Grade A when testing the SSL implementation with SSL Labs, so I don’t think there’s anything wrong with the SSL setup itself: https://www.ssllabs.com/ssltest/analyze.html?d=nextpeak.co&s=

Is anybody from Twitter able to help me with the validation?

Best Regards,


I’m having the same issue as you. Maybe through a joint effort we can get a response from somebody who can give us a definitive answer. My issue is linked here:


I still do not have an answer to this problem.

Also, @tibor seems to have the same problem: SslHandshakeError on Card Validator

@andypiper, can you help?


I’m having the same issue here.

My website is also running on Uberspace but I’m using Let’s Encrypt for the SSL certificate instead of Comodo.

Test URL: https://www.theblondtravels.com/son-tra-peninsula-best-day-trip-around-da-nang-vietnam/


Anybody have a resolution to this yet?


I got the same problem - any suggestions?


I’m having the same problem with my uberspace hosted website. It started with enabling Letsencrypt SSL. No workaround for me yet.


Most of the solutions I’ve seen to this revolve around the ServerName directive in Apache not matching the name in the certificate.


Hey andypiper,
@ubernauten told me that as long as SSLLabs is telling me that the cert, the cipher and the whole setup is fine, there is no problem on my site. Can you tell us a more detailed answer? They said that it’s not the missing match of the ServerName on the certificate.


The detailed answer is described here on StackOverflow - Java’s SNI implementation doesn’t like a misconfigured ServerName or missing ServerAlias. The folks who have resolved this issue seem to have been helped by this. I can’t prove that this is the case with a specific site, but it’s the best clue I’ve seen so far.