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 webmaster@yourdomain.com 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 notifications@github.com 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.

[drm87]

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?

[drm87]

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.j@gmail.com

[ataraxus]

+1

[danimo]

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