CFNetwork SSLHandshake failed (-9800)

1,370 views
Skip to first unread message

David Quon

unread,
Aug 4, 2014, 8:25:14 PM8/4/14
to mobile-c...@googlegroups.com
I'm getting the following error output in the console logs when trying to do a push/pull replication with SSL.  We're setting up the push/pull replication as shown below passing the credentials and port as part of the URL to a CouchDB server running version 1.6.

Printing description of self->_pullReplication:
CBLReplication[from https://user:*****@stage.couch.com:6984/db_1]
Printing description of self->_pushReplication:
CBLReplication[to https://user:*****@stage.couch.com:6984/db_1]

Console Logs:
2014-08-04 15:35:30.121 AppName[2931:4f0f] CFNetwork SSLHandshake failed (-9800)
2014-08-04 15:35:30.143 AppName[2931:4f0f] CFNetwork SSLHandshake failed (-9800)

Does anyone have any input of what could be causing this and how to fix it?  The replication seems to work okay despite the error message.  Thanks.

Jens Alfke

unread,
Aug 4, 2014, 11:27:44 PM8/4/14
to mobile-c...@googlegroups.com

On Aug 4, 2014, at 5:25 PM, David Quon <dav...@amcoonline.net> wrote:

Console Logs:
2014-08-04 15:35:30.121 AppName[2931:4f0f] CFNetwork SSLHandshake failed (-9800)
2014-08-04 15:35:30.143 AppName[2931:4f0f] CFNetwork SSLHandshake failed (-9800)

Couchbase Lite doesn't log this; it seems to be something logged by the OS itself. I hadn't heard of it before, but googling that message shows a bunch of info. Sounds like it may be caused by problems with the local network?

—Jens

David Quon

unread,
Aug 6, 2014, 8:40:02 PM8/6/14
to mobile-c...@googlegroups.com
Yeah I saw a bunch of different info regarding similar SSL issues.  After sorting through all the noise these seem the most relevant which unfortunately don't yet give me a solution.  I forgot to mention I'm on CBL 1.0.0 as well as iOS 7.1.1 and iOS 7.1.2.

Jens I assume this fix made it into CBL 1.0.0?

This also looks like it could have been related:

But then it looks like you fixed this problem here:

Actually it looks like some of the fixes in CBLSocketChangeTracker.m were done recently.  Could that be what's causing the errors I'm seeing?  Thanks for your help as always Jens.

Jens Alfke

unread,
Aug 6, 2014, 9:00:05 PM8/6/14
to mobile-c...@googlegroups.com
On Aug 6, 2014, at 5:40 PM, David Quon <dav...@amcoonline.net> wrote:

Jens I assume this fix made it into CBL 1.0.0?

Yes, and that only applies when talking to Sync Gateway, not CouchDB.
CBLSocketChangeTracker has had a workaround for that problem for a long time.

Actually it looks like some of the fixes in CBLSocketChangeTracker.m were done recently.  Could that be what's causing the errors I'm seeing?  Thanks for your help as always Jens.

I don't think there have been any recent changes that would affect the SSL handshake. There is a recent change on the master branch affecting certificate verification, but that happens after the handshake is complete.

—Jens

David Quon

unread,
Aug 6, 2014, 9:33:53 PM8/6/14
to mobile-c...@googlegroups.com
Actually looking at your commit:

I think this maybe the fix we need {(id)kCFStreamSSLValidatesCertificateChain, @NO}:

I think the problem is our CouchDB certificate was purchased from GoDaddy and was signed with an intermediate certificate.  Unfortunately CouchDB doesn't have a way to deal with an intermediate certificate which breaks the chain.  :-(

David Quon

unread,
Aug 8, 2014, 5:54:47 PM8/8/14
to mobile-c...@googlegroups.com
Unfortunately `{(id)kCFStreamSSLValidatesCertificateChain, @NO}` wasn't the fix we were looking for.  Probably need to try to pre-install the intermediate SSL certificate in the keychain and see if that fixes the issue.

Jens Alfke

unread,
Aug 8, 2014, 6:50:25 PM8/8/14
to mobile-c...@googlegroups.com

On Aug 8, 2014, at 2:54 PM, David Quon <dav...@amcoonline.net> wrote:

Unfortunately `{(id)kCFStreamSSLValidatesCertificateChain, @NO}` wasn't the fix we were looking for.  Probably need to try to pre-install the intermediate SSL certificate in the keychain and see if that fixes the issue.

I don't think this problem is related to the certificate. Error -9800 is errSSLProtocol (it's defined in SecureTransport.h) which sounds like a low-level error; there are more specific error codes for cert related problems, like errSSLXCertChainInvalid and errSSLUnknownRootCert. Even a problem with cipher suites would result in errSSLNegotiation. errSSLProtocol sounds like a generic "WTF?" syntax error.

My guess is that the client is somehow connecting to something that isn't actually using SSL at all. Have you been able to packet-sniff the connection and see what the data being received is?

—Jens

rednas

unread,
Oct 2, 2014, 6:08:23 AM10/2/14
to mobile-c...@googlegroups.com
Did you find a fix for this David? I ran into the same problem. 

David Quon

unread,
Oct 2, 2014, 1:25:07 PM10/2/14
to mobile-c...@googlegroups.com
I've been meaning to comment on this.  In iOS 7 this was a failure that would just inform us the handshake failed but the replication would work as expected.  In iOS 8 the handshake failure was a lot worse as the replication wouldn't start until the failure timed out (10 minutes).  Here's the error we were receiving.

2014-09-24 17:24:26.426 XXXX[619:261226] CFNetwork SSLHandshake failed (-9800)
17:24:26.432‖ WARNING*** : CBLSocketChangeTracker[0x147d9e40 XXXX]: Can't connect, giving up: Error Domain=NSOSStatusErrorDomain Code=-9800 "The operation couldn’t be completed. (OSStatus error -9800.)"

This was fixed on the server side by hardcoding to always use TLS v1 which is supported by iOS 8.  We tried all different combinations of TLS v1.1 and v1.2 but the only one that wouldn't cause the problem above was always using TLS v1.  This is not an ideal fix but it worked for us.  If anyone else finds a more graceful solution please post.

Here's a couple of links that led us to the "solution":

Jens as usual you were correct in this failure being a lower level problem.  :+1:

Jens Alfke

unread,
Oct 2, 2014, 5:21:40 PM10/2/14
to mobile-c...@googlegroups.com

On Oct 2, 2014, at 10:25 AM, David Quon <dav...@amcoonline.net> wrote:

This was fixed on the server side by hardcoding to always use TLS v1 which is supported by iOS 8.  We tried all different combinations of TLS v1.1 and v1.2 but the only one that wouldn't cause the problem above was always using TLS v1.  This is not an ideal fix but it worked for us.  If anyone else finds a more graceful solution please post.

Here's a couple of links that led us to the "solution":

These look like different issues — the first thread is about a bug in keep-alive connection handling, while the second is about SSL handshakes. How do these relate?

Jens as usual you were correct in this failure being a lower level problem.  :+1:

I've found it's usually a good tactic to blame bugs on something else ;-) But seriously, there might be wiggle room here to work around this in CBL. From the descriptions on stackoverflow, it sounds like this has to do with certificate checking, not the mechanics of the handshake protocol. We might be able to change how we check the server cert.

Do you have any easy steps to reproduce this? We haven't run into it here, but I don't know if we've actually tested SSL connections on an iOS 8 device. Is your SSL server just Sync Gateway itself, or do you have a proxy/gateway doing it?

—Jens

David Quon

unread,
Oct 2, 2014, 8:52:57 PM10/2/14
to mobile-c...@googlegroups.com
You're correct Jens those links don't have directly anything to do with the problem we were facing.  I wasn't sure if I should have posted them but they were the clues we needed to find a temporary workaround to the problem.

This would be great to find a solution in CBL if possible.  Unfortunately I don't have an easy way to reproduce the problem although I can describe our setup.

Initially when we encountered this problem we were using CBL to talk directly to CouchDB.  Our certificate is from GoDaddy and they use an intermediate certificate to sign our certificate.  CouchDB unfortunately doesn't yet support these chained certificates.  In order to handle the certificate chaining properly we have a Nginx proxy in front of CouchDB.  Nginx handles the certificate chaining fine as we have no problems communicating to our CouchDB server in a browser or terminal.

Let me know if any other information would be helpful.  Thanks for your help as always Jens.

rednas

unread,
Oct 4, 2014, 1:31:39 AM10/4/14
to mobile-c...@googlegroups.com
Also nginx proxied couchDB over here. Changing the protocols in the nginx config to TLSv1 only (removing v1.1, 1.2 and SSLv3) solved this for me. 
Thanks, would never have guessed this myself!

Op vrijdag 3 oktober 2014 02:52:57 UTC+2 schreef David Quon:

rednas

unread,
Oct 8, 2014, 7:53:27 AM10/8/14
to mobile-c...@googlegroups.com
Jens, if you're able to work around this issue in CBL, that would be great! I'm able to get things working on my develop machine by limiting nginx to TLSv1, but there are a lot of SSLv3 handshake messages in my error log. I'm guessing that maybe the connecting infrastructure for some clients force SSLv3? If not SSLv3, I would certainly like to be able to enable TLSv1.1 and TLSv1.2. Is there anything you could do to make this possible?


Op donderdag 2 oktober 2014 23:21:40 UTC+2 schreef Jens Alfke:

Jens Alfke

unread,
Oct 8, 2014, 12:57:01 PM10/8/14
to mobile-c...@googlegroups.com
The first step is to file a bug report! Please give a detailed description of the configuration, and if possible, ways that we could reproduce this.

—Jens

rednas

unread,
Oct 9, 2014, 5:34:17 AM10/9/14
to mobile-c...@googlegroups.com
Ok, bug report filed. Please let me know if you need any more info. I could also DM you a url and credentials on my machine if you don't have a domain with a chained SSL certificate to your disposal.

Op woensdag 8 oktober 2014 18:57:01 UTC+2 schreef Jens Alfke:
Reply all
Reply to author
Forward
0 new messages