Client: SSL handshake error with OSX client

[clayton256]

The OSX client used to connect but I don't know when it stopped working. It now fails to connect to an owncloud install on my web hosting site (bluehost.com). I get error "SSL handshake failed".
The client log shows:
06-19 11:08:54:414 ownCloudInfo Network Error: 6
06-19 11:08:54:414 status.php returns: "" 6 Reply: QNetworkReplyImpl(0x1015b3be0)
06-19 11:08:54:414 No proper answer on "https://box282.bluehost.com/~m/owncloud/status.php/status.php"

If I run curl on that url, it get, what looks like a valid OC response:
$curl -3 https://box282.bluehost.com/~m/owncloud/status.php
{"installed":"true","version":"5.0.12","versionstring":"5.0.7","edition":""}$

The linux (Ubuntu 13.04) client works fine.

I don't see anything interesting in the server logs.

owncloud 5.0.7
OSX clients 1.3.0beta3 and 1.2.5
PHP 5.4.15
Apache 2.2.24
openssh 5.3p1

[MarcelWaldvogel]

The spurious "SSL handshake failed" error messages I have been seeing were due to putting the Mac to sleep. When waking up, the network connection would be gone. Could this be your problem as well? If so, it might be "good enough" for the client to just retry.

[clayton256]

Thanks for the input. However, I get this error from the setup wizard. I did some digging in the code but with little insight. The best I can tell is that the error is coming from the QT network manager. I goggled and found someone else complaining about QT network manager giving the same error when curl worked fine. A suggestion that poster to use wireshark to see what is different btw the QT app and curl sounds like a good next step me.

[clayton256]

An update to this issue. I installed the owncloud iPhone app and it was fine. Between this app and the linux client working fine, I'm assuming it's not a server setup issue but an OSX client issue.

I used wireshark to capture the packets. The curl connection produces more traffic and the connection succeeds. The OS X client's traffic seems to be truncated. I don't understand all of the negotiations in the packets. I can provide my wireshark packet traces if someone working on this bug wants them. I don't want to post them publicly so PM me to get them.

Thanks,
Mark

[clayton256]

A couple of updates to this issue.

1) I updated the iOS app this morning and it still works.

2) I installed OC on a testbed server. This server that does _not_ have https capability. The OC client connects to it fine. With the previous client version I could _not_ connect to this server.

I hope all this info helps someone with this bug. I'd love to help with a patch but it's way over my head. Maybe if someone can point me in the right direction I could take a stab at it.

Thanks,
Mark

[tracerrx]

Having the same issue on OSX. (Windows/iPhone client works fine). Running owncloud via SSL on a non standard port, everything works fine across ALL clients if I utilize IP address:Port, however if I utilize domain name:port, works on all clients EXCEPT OSX where it throws an SSL handshake error. Very strange. All clients except OSX client prompt to accept the self signed cert, maybe this is the issue?

[tomscat]

same here,
did work fine until ~21 days ago
Mac OS X Lion
owncloud client 1.4.0

[ghost]

Related to https://github.com/owncloud/mirall/issues/831?

Some pointers to possible workarounds: https://github.com/owncloud/mirall/issues/831#issuecomment-22388767

[danimo]

Ok guys, let's investigate this. First off a few of my observations:

1. "But it works on XY" is not a sufficient indication that it works elsewhere. To ensure your SSL setup is correct, use http://ssllabs.com to check your host (usually the problem is a missing intermediate certificate (which makes it fail on all platforms, but works on browsers because they will fetch the intermediate), or sending the root certificate, which should be in your browser (it's best practice not to do that, it's a hard requirement for the ownCloud client on Mac OS).
2. Qt on Mac has a few gotchas that we cannot workaround easily
3. So far, I've gotten OS X to connect eventually (with modifications to the setup if required), I am interested why it fails for you.

I need your feedback on the following issues:

1. SNI: Are you using SNI (Server Name Indication, aka SSL vhost)?
2. Is this one certificate with several hosts ("Subject Alternative Name", or SAN), or one host per certificate?
3. Are you using a reverse proxy?
4. Which Server are you using (Apache, nginx, etc), for Reverse-Proxy users: which reverse proxy software are you using?

[boschma1]

I have done some checks with SSLLabs and mitigated a certificate chain issue, that in the end didn't solve the issue. The results of my check are included here in this screenshot:

Pertaining to your questions:

1. AFAIK, I am not using SNI
2. The certificate is only issued for one CN: owncloud.loomion.com, no alternate subject name defined
3. Nope
4. Apache on my QNAP 259+

Thank you for your precious time. I offer you to connect to my system in order to obtain a live view. Just let me know whether this is of interest for you.

Cheers
Markus

[danimo]

@boschma1 I already tried to check the setup on your system, and it seems the server is sending three certificates:

1. Server cert.
2. Intermediate cert.
3. Root cert.

Please remove the root cert from your certificate bundle. There is no point in doing so (after all the client can only trust the root if its in its own root-cert-store) and it's causing issues with the client.

[boschma1]

@danimo : if I remove the Root CA, then the Windows client shows the same symptoms as the Mac client. Currently the server certificate seems to have 2 intermediate certificates involved (see screen shot):

[danimo]

@boschma1 Oh, well, then I was wrong and what I thought was the root cert was in fact another intermediate. Oh my... Will continue investigation later then, if it's ok for you.

[danimo]

@boschma1 Can you try to disable SSLv2 (and possibly v3)? v2 seems to provide no cipher suites. It's possible that the rather old openssl on mac os cockes on this.

[boschma1]

@danimo Just to be on the safe side: you are referring to apache-ssl.conf? Could you please confirm that switching off SSL v2 happens in the line marked by the red box. AFAIK, SSLv2 has been disabled in this line already, correct?

Adding SSLv3 in this fashion leeds me to the same problem:

Was I modifying these settings in the right place?

[danimo]

No, this just disables the respective CipherSuites (which I assume is leading to the problem). Add:

SSLProtocol +ALL -SSLv2

or even

SSLProtocol All -SSLv2 -SSLv3 (although v3 should be fine given that you are not requiring SNI).

You should also add

SSLHonorCipherOrder On

while you're on it if you care about the order of the proposed cipher suites (which you should).

[boschma1]

I added the lines to apache-ssl.conf and restarted Apache. But the lines in there get deleted automatically. Seems like my Apache doesnt like them.

[danimo]

What if you delete SSLHonorCipherOrder?

[boschma1]

No, I mean: I add these lines and after the mandatory restart of Apache, they are vanished.

[danimo]

Apache doesn't do that by itself. Must be a bug in the QNAP firmware. Can you sort that out with the QNAP community? How do you restart? /usr/local/apache/bin/apachectl graceful should work without messing with config files.

Which version of Apache are you running? (/usr/local/apache/bin/apache -v)

[boschma1]

To be honest: QNAP Apache edition is a big mess, so many redundant files and you don't really know if you are touching the right one.

So far, I used /etc/init.d/Qthttpd.sh restart to restart, I'm not sure whether /usr/local/apache/bin/apachectl graceful does the same or where the differences are. Just the output of the first makes me more confident:

Whereas your method doesn't show any output but the prompt.

I have this versio of Apache installed on my NAS:
Server version: Apache/2.2.14 (Unix)
Server built: Sep 12 2013 05:26:32

[danimo]

@boschma1 Sorry, but debugging weird QNAP issues (even though it's a popular NAS system) is a bit beyond our scope. Can you try to sort this out with the QNAP community?

[ghost]

Hi,

sorting this out with the QNAP community as danimo has written above is probably the best what you can do here. See here for example for some more infos:

http://wiki.qnap.com/wiki/Modify_apache.conf
http://www.tim-carter.com/index.php?t=QNAP+-+Restart+Apache+%28Webserver%29&Menu=4&SubMenuId=18&ItemId=102

They are using an different apache config than you're using.

[boschma1]

Well, that is completely understood. QNAP offers a really bad support here and the fact that they overwrite each time I boot the files far beyond acceptable... Well, I figured it out when I stumbled over this article: http://forum.owncloud.org/viewtopic.php?f=14&t=14253

Here are the basic steps:
1) I defined a Virtual Host on the GUI of QNAP:

2) I modified /etc/hosts and added the FQDN to the servers IP

That was about it. All the fiddling directly with config files and vi is obsolete...
Thank you, @danimo and @RealRancor

[BenS89]

Seems like this issue is related to QNAP QTS 4.0. ownCloud client 1.4.1 worked very well under QTS 3.8. With QTS 4.0, I get the same error: ownCloud client is not able to connect: "Im Ablauf des SSL-Protokolls ist ein Fehler aufgetreten"

[BenS89]

Problem solved:

you need to ensure that you have the correct server name set in your apache configuration. In your /etc/apache2/sites-enabled/default-ssl, make sure that the 'ServerName' setting matches your certificate CN. If for example you access your OwnCloud using https://cloud.yourdomain.com then your certificate CN should be cloud.yourdomain.com. If you access your OwnCloud using https://yourdomain.com/owncloud then your certificate CN should be yourdomain.com
For example:

CODE: SELECT ALL

ServerAdmin [email protected]
ServerName cloud.yourdomain.com
DocumentRoot /var/www

Options FollowSymLinks
AllowOverride None


Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all

For QNAP-Users, the path to this file is different from a generic apache installation. I corrected ServerName in /etc/config/apache/apache.conf
etc/config/apache/extra/httpd_ssl.conf
etc/config/apache/apache-ssl.conf

After that. everything worked fine. When you read through forums, this problem is quite often related to a wrong ServerName.

[lotus49]

I have exactly the same issue but with a different server platform.

I am running Debian Wheezy (7.2) on a PC but my symptoms are the same. The Linux and Windows sync clients work fine and all three platforms (Ubuntu, Windows 8 and Mac OS X) work fine with the web front end but using the latest version of the Mac OS X sync client (the only one I've ever tried) produces the same results as the above screen shot.

When I check the certificate in a browser, the site identifies itself using exactly the same name as that in the cert CN. To be explcit, I access the server using the URL https://tewit.mydomain.org (no /owncloud) and the CN is tewit.mydomain.org.

[lotus49]

I have a little bit more information that may or may not be useful.

I deleted the trust for the self-signed certificates in Firefox and tried to open https://tewit.mydomain.org. I was prompted in relation to the now untrusted self-signed cert. I then closed the window without trusting the SSL cert and I imported the CA certificate into the keychain on my Mac and trusted it for all purposes. I then re-opened the web page and the certificate was immediately trusted as it should be.

However, the client is still not accepting the SSL cert for tewit.mydomain.org. I presume that many or most Mac users have got this to work but I don't understand how the client could reject the cert when I had trusted the CA cert.

[lotus49]

They matched on mine too. In the end I gave up and got a free domain validated certificate from StartCom and that sorted out the problem since it is no longer self-signed.

Daniel Scheikl [email protected] wrote:

Hello!

Any news on that issue with self-signed? I have exactly the same
behaviour on the Mac as others have described. I'm not too much into
SSL stuff, so I just played around creating self-signed root
certificates, certificate chains (to have an intermediate certificate),
etc.

Every single method I tried worked with all my browsers on any
plattform, the iPhone client, the Windows client, except for Mac OS X
(Mavericks) client (v1.5.0, build 1811). Each time I tried I got the
SSL handshake error message.

I know this post isn't very helpful, but I'm curios if there is already
some kind of recipe how to get self-signed certificates to work, except
for "CN and URL has to match" (what it actually does in my case)?
I love the simplicity of OwnCloud, but this error drives me nuts :)

Thank you for the great work btw.

---

Reply to this email directly or view it on GitHub:
https://github.com/owncloud/mirall/issues/712#issuecomment-32487294

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[ghost]

I now got my own "official" certificate from StartCom (thanks for that hint), but still the same issue.

01-18 13:28:07:619 Client is on latest version!
01-18 13:28:11:621 void Mirall::AbstractNetworkJob::setTimeout(qint64) 10000
01-18 13:28:11:622 !!! Mirall::CheckServerJob created for QUrl( "https://cloud.xxx.com" ) querying "status.php"
01-18 13:28:11:728 Mirall::CheckServerJob Error: "SSL handshake failed"
01-18 13:28:11:747 status.php from server is not valid JSON!
01-18 13:28:11:747 status.php returns: QMap() 6 Reply: QNetworkReplyImpl(0x104fe2720)
01-18 13:28:11:748 No proper answer on QUrl( "https://cloud.xxx.com/status.php" )

https://cloud.xxx.com/status.php in the browser returns: {"installed":"true","version":"6.0.0.14","versionstring":"6.0.0a","edition":""}

[danimo]

Please check your ssl setup with ssllabs.com

[ghost]

I got this:

Do you need any specific information?

[danimo]

Looking at the details is important. You need to go ahead and fix your setup until you have at least an A grading. Especially the ciphers and key exchange gradings sound like you are running on an either very old or very badly configured web server.

[ghost]

Not really. I just played around with the prefs to solve my problem.
This is what I usually have:

It's not that bad. However, the OS X client does not work.

[ghost]

Is the Mac OS X client supporting TLSv1 only (this is what it seems when looking at a wireshark trace)?

[danimo]

@cyphorious I guess you checked for the issues described in the thread? (SNI, Root CA in certificate chain, etc)?

[schmunk42]

All clients except OSX client prompt to accept the self signed cert, maybe this is the issue?

Same here, I'd like just to ignore the warning for testing the desktop client.

[matt06sg]

I find it strange as I set up 2 instances on 2 diff mac machine and one client has got SSL handshake error. The one having issue happen to be Mountain Lion server and the other is Mavericks. Clients are same version running direct local connection to their respective bitnami stacks. Bitnami own cloud is of the latest version: owncloud-6.0.1-0

[vlindhol]

I have the same handshake problem, my setup is as follows:

• I have a domain foo.com and a subdomain mail.foo.com. The subdomain points at the same IP is the main domain at the moment.
• I have acquired a free SSL certificate from startssl.com. I got it for foo.com, but the certificate creation wizard forced me to also provide a subdomain name, so I put in mail.foo.com.
• This created a certificate with two domains, mail.foo.com as the main name and foo.com as an "alternative name" (as stated in the SSL Labs report, I don't know what standard that entails).

Pointing my owncloud mac client to foo.com/owncloud gives the handshake problem, but pointing it to mail.foo.com/owncloud (which is the same IP) works fine. In other words the client doesn't seem to understand that the certificate also covers foo.com.

[danimo]

Please retry with a 1.6 beta.

[masteralarm]

I have the same problem. When I use the IP, i get the "untrusted certificate" windows where I can allow this exception. If I use the domain name, that is given in the SubjectAltName of the certificate, I get the SSL handshake error using the MacOS client (1.5 and 1.6 beta).

[danimo]

@masteralarm what does ssllabs.com have to say about your web server?

[masteralarm]

ssllabs.com gives me an A- rating. But I already avoided the problem by using a different certificate and setting a different servername in my apache configuration. One or both of these actions solved the problem.

[slmagus]

Same, when using the ip address with both http and https works fine(default self sign cert). Using the host name returns the invalid JSON format issue. The below is the logs when using an ip. Using build 1.6.0beta2 build 153 of osx client on OSX 10.9.2 .

05-05 13:45:32:865 SSL-Errors happened for url "https://127.###.###.###/owncloud/status.php"
05-05 13:45:32:866 Error in QSslCertificate( "3" , "16326" , "bWFdxJNLh6Bm9GH9Z2jrHw==" , "SomeOrganization" , "SomeOrganization" , QMap() , QDateTime("Mon May 5 16:52:33 2014") , QDateTime("Tue May 5 16:52:33 2015") ) : "The host name did not match any of the valid hosts for this certificate" ( "The host name did not match any of the valid hosts for this certificate" )
05-05 13:45:32:867 Error in QSslCertificate( "3" , "16326" , "bWFdxJNLh6Bm9GH9Z2jrHw==" , "SomeOrganization" , "SomeOrganization" , QMap() , QDateTime("Mon May 5 16:52:33 2014") , QDateTime("Tue May 5 16:52:33 2015") ) : "The certificate is self-signed, and untrusted" ( "The certificate is self-signed, and untrusted" )
05-05 13:45:32:869 # # # # # #

[ghost]

I have the same problem, and I got this message from ssl Labs:

Common names TS Series NAS MISMATCH

What can I do to solve it?

[ghost]

@pipsen

This is a cert configuration problem. Set a correct common name.

[danimo]

This issue has become a sink for a lot of SSL-related issues none of which can be debugged reliably because we not have the exact details that cause failures, nor can I reach any of the domains because their name has been redacted or they no longer exist. So everyone who can still reproduce this problem with a version >= 1.6.0beta2 please open a new issue including as many details as possible.

1.6.0 offers the following improvements on OS X:

• (Server Name Indication) SNI support (Requires TLS, doesn't work with SSLv2/3)
• Support for newer TLS versions (1.1, 1.2)

Unfortunately, SSLv3 and TLS are not compatible, which sometimes causes handshake errors depending on server and client implementation details.

What you can do to mitigate the issue:

• Ensure that support for TLS is active in your configuration
• Ensure that your server has at least following protocols enabled: SSLv3, TLS1 (optionally: TLS 1.1 and 1.2)
• Ensure that the handshake still fails if you remove SSLv3 from the list of allowed protocols on the server
• Try to ensure that you have no proprietary load balancers / SSL accelerators in your setup. If you can trace it down to a misbehaving appliance, please report it so we can upstream the issue to the Qt bug tracker.

If nothing helps, please file a new report, and be as verbose as possible. In addition to the usual information, please provide at least:

• Your current server setup (paste of effective Apache/nginx SSL server config, server version)
• A pcap file (wireshark recording) of the SSL handshake
• Specifically what is failing (i.e. does it connect, but fails to sync, or doesn't it connect in the first place).

If you feel uncomfortable to disclose URLs, you can send them to me in private (danimo AT owncloud DOT com). If your setup is not public, you can still try to attach a wireshark dump with the Handhshake included.

Also, please refrain from "+1" or "I have the same problem", unless we have established that you really do. A failed handshake can have a gazillion of different reasons.

Thanks for your understanding.

[danimo]

One more thing that I just saw in the wild. If

openssl s_client -tlsextdebug -state -connect yourhost.com:443 -CApath -servername yourhost.com 2>&1< /dev/null|grep read:warning

yields

SSL3 alert read:warning:unrecognized name

then please fix your SNI setup.

If the client requests a host name, the server responds with a TLS Alert (Level Warning, Description: Unrecognized Name). Some implementations choose to ignore this (e.g. most browsers), others decide to make the handshake fail as a precaution or because they don't handle the error as a warning (Java 7, Qt).

Sometimes ensuring that SSLStrictSNIVHostCheck off is set might help, but you really should take a look at the SNI reference setup at https://sni.velox.ch/ to fix your setup.

If you are using a NAS, it is important to look at the _effective_ settings (those generated by the web interface)

[joubin]

@danimo

You had mentioned that people are putting in server info with redacted information. I am having the issue noted above and if youd like, I can provide you with a login into my server as well as the detailed info from ssl labs.

Please email me if interested!
joubin.[email protected]

[ataraxus]

+1

[danimo]

@joubin @ataraxus : have you verified that SSL3 alert read:warning:unrecognized name does not happen to you?

[joubin]

@danimo Sort of. I am getting an A- on SSL labs. The command you provided returns an error for me. says unknow option where you have yourhost.com the second time .

EDIT:OpenSSL on Mac 10.9 and Ubuntu 12.04, 14.04

[ataraxus]

@danimo same problem as @joubin using ubuntu openssl to test.

[zestysoft]

@danimo Add me to the list too. Qualys SSL's test gives me an A+, no errors.
Your openssl s_client command only gives one warning, but that's just related to closing the session:
SSL3 alert write:warning:close notify

Clients for Windows and IOS devices work flawlessly.

Certificate is purchased, not self-signed.

Apache doesn't log the mac client connection attempt (ssl_connect_log, ssl_request_log, ssl_error_log all remain silent), but I do see some tcp back and forth with tcpdump (from the server).

Server: Apache/2.4.9 (Fedora) OpenSSL/1.0.1e-fips PHP/5.5.12 mod_perl/2.0.9-dev Perl/v5.18.2

Edit:

I cranked up the server logging to debug, here's what Apache is reporting:

[Tue Jun 03 17:04:06.929538 2014] [ssl:info] [pid 933] [client x.x.x.x:50582] AH01964: Connection to child 7 established (server xxxx.xxxx.xxx:443)
[Tue Jun 03 17:04:06.930115 2014] [ssl:debug] [pid 933] ssl_engine_kernel.c(1929): [client x,x,x,x:50582] AH02044: No matching SSL virtual host for servername xxxx.xxxx.xxx found (using default/first virtual host)
[Tue Jun 03 17:04:07.449573 2014] [ssl:debug] [pid 933] ssl_engine_io.c(1212): (70014)End of file found: [client x.x.x.x:50582] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Tue Jun 03 17:04:07.449700 2014] [ssl:info] [pid 933] [client x.x.x.x:50582] AH01998: Connection closed to child 7 with abortive shutdown (server xxxx.xxxx.xxx:443)

[zestysoft]

@danimo

Here is wireshark's capture of the communication:

  7   4.028764 client -> server TCP 78 50855 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=1413293448 TSecr=0 SACK_PERM=1
  8   4.028945 server -> client TCP 74 https > 50855 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=273364807 TSecr=1413293448 WS=128
  9   4.060303 client -> server TCP 66 50855 > https [ACK] Seq=1 Ack=1 Win=131760 Len=0 TSval=1413293473 TSecr=273364807
 10   4.068103 client -> server SSL 192 Client Hello
 11   4.068196 server -> client TCP 66 https > 50855 [ACK] Seq=1 Ack=127 Win=29056 Len=0 TSval=273364846 TSecr=1413293480
 16   4.576222 server -> client TLSv1 2962 Alert (Level: Warning, Description: Unrecognized Name), Server Hello
 17   4.576554 server -> client TLSv1 1266 Certificate
 18   4.576852 server -> client TLSv1 629 Server Key Exchange
 19   4.606028 client -> server TCP 66 50855 > https [ACK] Seq=127 Ack=2897 Win=128864 Len=0 TSval=1413293876 TSecr=273365354
 20   4.608678 client -> server TCP 66 50855 > https [ACK] Seq=127 Ack=4097 Win=127664 Len=0 TSval=1413293876 TSecr=273365355
 21   4.608888 client -> server TCP 66 [TCP Window Update] 50855 > https [ACK] Seq=127 Ack=4097 Win=131072 Len=0 TSval=1413293876 TSecr=273365355
 22   4.609460 client -> server TCP 66 50855 > https [FIN, ACK] Seq=127 Ack=4097 Win=131072 Len=0 TSval=1413293876 TSecr=273365355
 23   4.609704 server -> client TCP 66 https > 50855 [FIN, ACK] Seq=4660 Ack=128 Win=29056 Len=0 TSval=273365388 TSecr=1413293876
 24   4.610526 client -> server TCP 60 50855 > https [RST] Seq=127 Win=0 Len=0
 25   4.610609 server -> client ICMP 82 Destination unreachable (Host administratively prohibited)
 42   4.920583 server -> client TCP 629 [TCP Retransmission] https > 50855 [FIN, PSH, ACK] Seq=4097 Ack=128 Win=29056 Len=563 TSval=273365699 TSecr=1413293876[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
 43   4.947994 client -> server TCP 77 50855 > https [RST] Seq=128 Win=0 Len=23

I can only assume that that "Unrecognized Name" error is because the server is set up to host multiple domains. (The SSL cert is a UCC type that has other alternate names)

Otherwise, the only other thing I can think of that is causing the client to drop the connection is the piggybacking of the intermediate cert that gets sent along with the server public cert?

[zestysoft]

Here's more detail:

Client HELLO asks for these Cipher Suites:

                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a)
                Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099)
                Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
                Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
                Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
                Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
                Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
                Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

and correctly specifies the FQDN of the server in the HTTP request.

Server HELLO replies with an Alert warning: Unrecognized Name, and then specifies this supported Cipher Suite, which is the first one the client asks for:

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

The server then sends the certificate contents which include both the server's public key, and the intermediate certificate owned by the signing cert company (Starfieldtech). This second cert is needed to complete the chain back to the trusted certs that the client would have on file on the local workstation. Note that the common name in the server's cert matches the FQDN the client asked the server for.

The client then responds with a TCP FIN thus starting the breakdown of the communication.

[zestysoft]

@danimo

I got the client to work when I specified the server name in the Apache ssl configuration file:

ServerName xxxx.xxxx.xxx:443

This breaks the server's ability to serve other domains securely with the UCC cert, so I had to disable it, but I think this is your smoking gun: The mac client software is incorrectly honoring that "Unrecognized Name" warning as being an error instead.

[protist]

@zestysoft 's advice is right on the money. Setting the ServerName in /etc/apache2/sites-available/000-default.conf fixed it for me. (I should learn to read threads backwards.)

[robertwenner]

Same here: I had ServerName myServer in /etc/apache2/apache2.conf already, but Mac OS added the .local suffix to host names, so adding ServerName myServer.local and running service apache2 reload did the trick.

[timtelcik]

Hello All,

just in case it's helpful to another reader of this thread, I bumped into a similar issue, an SSL SNI handshake error.

My SSL handshake error manifested as follows:

{code}
$ git clone https://GIT-HOST/GIT-PROJECT.git
Cloning into 'GIT-PROJECT'...
fatal: unable to access 'https://GIT-HOST/GIT-PROJECT.git/': SSL peer handshake failed, the server most likely requires a client certificate to connect
{code}

My local Mac development environment:

• Mac OS : Mac OS Sierra (10.12.2)
• Git client : 2.10.1 (downloaded from Git sourforge, not the default Apple Mac OS release)
• Open SSL : OpenSSL 1.0.2j 26 Sep 2016
• Package manager : Mac Port (not Brew)

I resolved the SSL SNI handshake error as follows:

1/ Upgraded openssl resources for Mac Port

{code}
sudo pip install ndg-httpsclient pyasn1
sudo pip install ndg-httpsclient pyasn1 --upgrade
{code}

2/ Upgraded Apple XCode developers tools

e.g.

{code}
xcode-select --install
{code}

3/ Update Git client configuration

Edit file $HOME/.gitconfig and change "sslvertify" from "false" to "true"

From ...

{code}
...

[http]
postBuffer = 209715200
sslverify = false

....
{code}

To ...

{code}
...

[http]
postBuffer = 209715200
sslverify = true

....
{code}

Some helpful references:

• How to upgrade OpenSSL in OS X?
  ** http://apple.stackexchange.com/questions/126830/how-to-upgrade-openssl-in-os-x

• Command Line Tools bash (git) not working - macOS Sierra final release candidate
  ** http://stackoverflow.com/questions/39484218/command-line-tools-bash-git-not-working-macos-sierra-final-release-candidate

• kennethreitz requests - https GET request fails with "handshake failure" #2022
  ** https://github.com/kennethreitz/requests/issues/2022#issuecomment-133204955

Regards,

Tim

email: [email protected]

[chscorpio]

Instead of wireshark, here is a simpler way to reveal this issue if you have openssl...

$ openssl s_client -servername domain.com -connect domain.com:443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL3 alert read:warning:unrecognized name
SSL_connect:SSLv3 read server hello A