756763 - Android Sync can't accept self-signed certificates (or roots unknown to Android) for custom Sync servers on Android 2

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Android Sync, defect, P3)

Description

[Gianni Ceccarelli]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20100101 Firefox/10.0.4
Build ID: 20120507165410

Steps to reproduce:

I have set up a custom Sync / Weave server under my own domain at https://weave.thenautilus.net/ (it won't accept creation of users).

I sync successfully with that server from multiple desktop Firefox instances, and from multiple non-native Fennec.

When I updated to beta 14 on my ICS tablet, it could not sync: the system log showed the same exception as in bug #753457

I then installed the certificate for my own "certificate authority" (the one I used to create the certificate for my server), and now everything works.

On my phone (Nexus One running Android 2.3.6) I performed the same procedure, but the error did not go away.

From some research on the net, it looks like the system trust store before ICS does not allow adding CA certificates: custom certificates are only used for WPA and VPN, not for HTTPS.

This article http://nelenkov.blogspot.co.uk/2011/12/using-custom-certificate-trust-store-on.html seems to contain some suggestions to work around the issue.

I realise I'm asking to fix an issue that is not really inside Fennec, affects very few users (only those with custom sync servers and self-signed certificates), and is not a real problem in recent Android versions…



Actual results:

"javax.net.ssl.SSLPeerUnverifiedException: No peer certificate" in the log


Expected results:

At the very least, a visible error message. Optimally, a process to import or trust a certificate for the custom server.

Comment 1

[Aaron Train [:aaronmt]]

Let's see if the Sync team has a plan for this.

Comment 2

[Richard Newman [:rnewman]]

We already use a custom HTTP (and SSL) layer, so in theory we can do whatever we want with the certificate trust chain.

It's really a question of augmenting the UI here, and thus one of prioritization.

The simplest solution is to add a cross-root chain to your cert, which is exactly what we did for Mozilla's own servers: Bug 720478, and see 

<https://bugzilla.mozilla.org/show_bug.cgi?id=717691#c17>

Comment 3

[Gianni Ceccarelli]

Thank you rnewman; the cross-root certificate is not really applicable to my case, since if I could / wanted to have my domain verified by a "proper" CA, I could just use their certificate directly. In the meantime I think I'll root my phone and add my certificate directly to the bks

Comment 4

[Richard Newman [:rnewman]]

(In reply to Gianni Ceccarelli from comment #3)
> In the meantime I think I'll
> root my phone and add my certificate directly to the bks

Do please let us know if this works; it'll be good to know if it's a viable workaround.

Comment 5

[Allison Naaktgeboren :ally]

sync triage: not scoping for first release. p3

Comment 6

[Allison Naaktgeboren :ally]

Gianni, also, thanks for filing :)

Comment 7

[Gianni Ceccarelli]

(In reply to Richard Newman [:rnewman] from comment #4)
> Do please let us know if this works; it'll be good to know if it's a viable
> workaround.

It works. I have followed the instructions at http://nblock.org/2011/09/03/how-to-update-the-android-certificate-store/ and added both my own CA certificate and the certificate for my sync server, and now my (rooted) phone syncs with my server. Adding just the CA certificate appeared not to be enough, but it might have been because I did not reboot the phone.

Comment 8

[Richard Newman [:rnewman]]

(In reply to Gianni Ceccarelli from comment #7)

> It works.

Great, thank you so much for letting us know.

I'll leave this bug open to track supporting custom certs.

Comment 9

[Richard Newman [:rnewman]]

Priority creep. This seems to be a common request from more technical users, particularly because it just worked in XUL.

Comment 10

[Sylvain D]

What about those (me for instance) who do not want to root their phones (yet) is there progress on the UI customization front?

Comment 11

[Richard Newman [:rnewman]]

(In reply to Sylvain D from comment #10)
> What about those (me for instance) who do not want to root their phones
> (yet) is there progress on the UI customization front?

None yet.

Comment 12

[Patrick]

Doesn't this bug also apply to Android 4.x? In that case the title should be changed.

Comment 13

[Richard Newman [:rnewman]]

(In reply to Patrick from comment #12)
> Doesn't this bug also apply to Android 4.x? In that case the title should be
> changed.

Unclear:

http://nelenkov.blogspot.com/2011/12/using-custom-certificate-trust-store-on.html

Comment 14

[Gianni Ceccarelli]

Android 4.* allows you to import custom CA certificates (I've done it on 3 devices, no root access necessary), and Firefox will use them. In Android 2 the importing is broken.

Comment 16

[Sylvain D]

Of course, it really needs a CA certificate and not a "normal" used to sign the webserver certificate. (tried, it doesn't work)

Comment 17

[Claudius]

I have a signed certificate from startcom, which is both in the Android 4 system AND apparently in firefox. I still get an error message when adding my self-hosted sync-server.
I would love to provide you with more information, but there isn't anything besides a small text-message below the URL-field stating that the URL is invalid.

Comment 18

[Richard Newman [:rnewman]]

(In reply to bugzilla from comment #17)
> I have a signed certificate from startcom, which is both in the Android 4
> system AND apparently in firefox. I still get an error message when adding
> my self-hosted sync-server.
> I would love to provide you with more information, but there isn't anything
> besides a small text-message below the URL-field stating that the URL is
> invalid.

Please file a new bug with a log:

http://160.twinql.com/how-to-file-a-good-android-sync-bug

Thanks!

Comment 19

[alex]

Still not able to sync to a server with a certificate, which is not trusted by an android root-ca.

On desktop firefox, an easy workaround is, to visit https://yoursyncsite, and add an exception. On firefox mobile you can add the exception as well, but sync does not use it.

Comment 20

[Nick Alexander :nalexander [he/him]]

(In reply to Alexander Schier from comment #19)
> Still not able to sync to a server with a certificate, which is not trusted
> by an android root-ca.
> 
> On desktop firefox, an easy workaround is, to visit https://yoursyncsite,
> and add an exception. On firefox mobile you can add the exception as well,
> but sync does not use it.

Fixing this will mean registering your cert with Android, which (see earlier comments) seems to be shaky at best.  An adb log will help verify that this is the real issue.

The exception does not help because Android Sync does not use the same networking code as Firefox for Android; to slim down our footprint when we're running in the background, we use the Android networking stack.

Comment 21

[alex]

The problem with the android certificate store is, that you need to use a pin/password for unlock, and cannot use the more convenient methods like pattern, face unlock or even slide to unlock.
This is not a mozilla specific issue, but it was kind of a "feature" that firefox can manage own exceptions.

Comment 22

[Sam]

I have similar issues. I configured my own sync server. Took a SSL from godaddy. I installed nginx with the intermediate certificates. All works fine from desktop firefox and even from firefox mobile browser. but sync won't work. In the nginx logs i see, that sync connects, but probably does not accept the ssl. Is there a workarround?

Comment 23

[Sam]

I did some more investigation. it seems that it's not intermediate certificate related, as it works with a certificate

New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit

but if i create a stronger encryption

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit

it won't work. but in the firefox mobile browser both do work. only in the firefox android sync the second seems not to be accepted.

Comment 24

[Richard Newman [:rnewman]]

It's possible that you're using an unsupported cipher. A log would confirm it, but please file a new bug.

Comment 25

[alex]

It seems, the sync does not work with wildcard certificates?

Seems the Sync-Service must check for wildcard-certs by itself, as described in the answer here:
http://stackoverflow.com/questions/3135679/android-httpclient-hostname-in-certificate-didnt-match-example-com-ex

Comment 26

[Richard Newman [:rnewman]]

(In reply to Alexander Schier from comment #25)
> It seems, the sync does not work with wildcard certificates?

Correct wildcard certs should work. That stackoverflow post is about incorrectly using a wildcard cert.

If you're finding that that is not the case, please file a new bug with ADB logs. Thanks!

Comment 27

[alex]

(In reply to Richard Newman [:rnewman] from comment #26)
> (In reply to Alexander Schier from comment #25)
> > It seems, the sync does not work with wildcard certificates?
> 
> Correct wildcard certs should work. That stackoverflow post is about
> incorrectly using a wildcard cert.
> 
> If you're finding that that is not the case, please file a new bug with ADB
> logs. Thanks!

Do you have some good reference, how a correct Wildcard Certificate should look like? Or is the only problem, that *.domain does not match ^domain$ (but should match ^sync.domain$)?

Sorry, but this stuff is rather hard to debug. I'm having some CACert-Certificate, which is not included as default in android, and experimenting with sync, adding it (with root) to the android cert-list, and using a server with subdomain for sync and wildcard certificate all at the same time ... getting certificate errors all the time without really knowing at which part of this the problem lies.

just a function "add an exception for sync" to allow a single certificate would be a usable solution anyway. I thought this would not work, because sync is android network stack, but i.e. the caldav-sync app does this as well. I think it would only need a second exceptions-list, then.

When i get something more than "invalid certificate error" in the logs, i will post it here (or if unrelated in a new bug).

Comment 28

[Richard Newman [:rnewman]]

(In reply to Alexander Schier from comment #27)
> Or is the only problem, that *.domain does not match ^domain$
> (but should match ^sync.domain$)?

That's the issue in that bug, yes. *.domain does not match domain.


> When i get something more than "invalid certificate error" in the logs, i
> will post it here (or if unrelated in a new bug).

Great, thanks.

Comment 29

[Beppe]

Hi, any further progress on this one?

The frustrating bit is that it use to work in early builds, when the sync part was in Firefox and use it own cert store.

Which got me thinking of inconsistency =0) 

Hope to see it accepting self-signed certificates.

::beep

Comment 30

[Richard Newman [:rnewman]]

(In reply to Beppe from comment #29)
> Hi, any further progress on this one?
> 
> The frustrating bit is that it use to work in early builds, when the sync
> part was in Firefox and use it own cert store.

If by "early builds" you mean "XUL Fennec, 18 months ago", sure :D

There is nobody working on this right now, and there isn't much pressure to do so -- not only is Sync currently on ice, but this omission doesn't affect most of our users, or the majority of Android devices, and it's easy enough to work around by just buying a cert.

You'll be able to see if someone starts working on this because the Assigned To field of the bug will change.

Comment 31

[Skunnyk]

I made some debugging, as I'm facing the same bug (and #819762).
My setup is nginx + https with custom wildcard certificate + server-full . It works great on desktop but not on firefox mobile (android 4.2.2 + firefox 22), with "Please enter a valid server URL" message, and no error on server side.
With tshark, on ssl negociation, I see that only RC4-SHA is proposed on ClientHello handshake. As we can see in mozilla-central/mobile/android/base/sync/net/TLSSocketFactory.java , it's the expected behavior ( SSL_RSA_WITH_RC4_128_SHA ).
But since nginx 1.0.5, defaults ciphers are  	

ssl_ciphers HIGH:!aNULL:!MD5;

SSL_RSA_WITH_RC4_128_SHA is NOT in HIGH category (only key lengths larger than 128 bits), but in medium, so this don't works. Add ssl_ciphers RC4+RSA in ffsync vhost, now ssl negociation is ok, and sync works on android.

Comment 32

[bofh]

This bug is going to be a real issue with Android 4.3.

Till Android 4.2.2 it was possible to use firefox 10.0.5, as this is the last firefox with sync internally. As of Android 4.3 this old version of firefox won't start on the device. (at least not on an Samsung S2 I9100 with CM 10.2)

Persoanlly, I'm now without a usefull browser. :(

Is it possible to recompile 10.0.5 for the newer androids so at least I can get access to my data on my private weave server at home? Moving to NSA/FBI controlled space will not happen.

Comment 33

[Richard Newman [:rnewman]]

What about Sync being implemented in Java means that you cannot use a modern, secure version of Firefox?

You're missing out on critical security fixes as well as massive performance and usability improvements.

If it's a self-signed cert, you can import that on Android 4.3.

Comment 34

[bofh]

How? 

I've already added the cert to android using this manual (http://rlaskey.org/words/2093/android-adding-your-self-signed-certs/), but that doesn't let firefox sync work with a private weave server with self-signed cert.

I've found several other descriptions for importing certs as well, but they all are basically the same, or for a CA.

Comment 35

[Gianni Ceccarelli]

For the people who are getting problems syncing even after adding their own CA cert to the Android trust store: comment #31 can help. I had recently tightened the set of SSL ciphers on my server, and FF stopped syncing. I've re-added 'RC4-SHA' to the SSLCihperSuite setting in Apache, and FF is now syncing again.

Comment 36

[Richard Newman [:rnewman]]

(In reply to bofh from comment #34)

> I've already added the cert to android using this manual
> (http://rlaskey.org/words/2093/android-adding-your-self-signed-certs/), but
> that doesn't let firefox sync work with a private weave server with
> self-signed cert.

With respect, there are several people who've commented in this bug that have done this and succeeded. Perhaps your available cipher suites don't match (see later comments)?

I've never needed to this myself, and Bugzilla isn't the right forum for walkthroughs (come to IRC, #sync), so I'm in no position to hand-hold, I'm afraid.

Comment 37

[Sigi]

It seems there is also a problem with SNI. Have a longtime working sync-server as name virtual host in apache. RC4-SHA is allowed. LogLevel Debug says:
[Thu Aug 15 22:58:23 2013] [debug] ssl_engine_kernel.c(1879): OpenSSL: Read: SSL negotiation finished successfully
[Thu Aug 15 22:58:23 2013] [debug] ssl_engine_kernel.c(1884): OpenSSL: Write: SSL negotiation finished successfully
but then connection immediately ends... opposite to FF Desktop version

Comment 38

[Beppe]

Hi,

Can confirm on Richard Newman comment 
>If it's a self-signed cert, you can import that on Android 4.3.

It works, i got access log on my apache, but discover that the authentication bit doesn't.

I know that it's another issue, does any of you know whats the prob.
This is from my apache access log. 
10.16.136.220 is from my desktop and is authenticated as beppe while 10.16.136.181 is my android and gets error 404 

10.16.136.181 - - [21/Aug/2013:15:14:53 +0200] "GET /weave-sync/user/1.0/beppe HTTP/1.1" 404 283
10.16.136.220 - beppe [21/Aug/2013:15:52:45 +0200] "GET /weave-sync/1.1/beppe/info/collections HTTP/1.1" 200 206

I do have version 1.0 and 1.1 installed.
Will FireFox Sync on android update to version 1.1?

kind regards,
Beppe

Comment 39

[Richard Newman [:rnewman]]

(In reply to Beppe from comment #38)

> It works, i got access log on my apache, but discover that the
> authentication bit doesn't.

This is not a good place for tech support. Please mail <https://mail.mozilla.org/listinfo/services-dev> or join irc.mozilla.org #sync.

Comment 41

[Renaud Allard]

I am using a valid certificate and it indeed doesn't work.

I am only permitting the following encryption schemes:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH 256 bits (eq. 3072 bits RSA)   FS		256	
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 	256	
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 	168

Firefox is able to access the URL from the browser part without even giving an error or warning (which is the expected behavior). So not being able to access ffsync for running a too high encryption scheme, while the browser supports it is a little bit strange.

Here is the adb log (on android 4.4) I get:
I/FxSync  (16278): firefox :: EnsureUserExistence :: Error checking for user existence.
W/FxSync  (16278): firefox :: AccountAuthenticator :: Authentication failed.
W/FxSync  (16278): javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
W/FxSync  (16278):      at com.android.org.conscrypt.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:146)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:818)
W/FxSync  (16278):      at ch.boye.httpclientandroidlib.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:752)
W/FxSync  (16278):      at org.mozilla.gecko.sync.net.BaseResource.execute(BaseResource.java:229)
W/FxSync  (16278):      at org.mozilla.gecko.sync.net.BaseResource.retryRequest(BaseResource.java:268)
W/FxSync  (16278):      at org.mozilla.gecko.sync.net.BaseResource.execute(BaseResource.java:239)
W/FxSync  (16278):      at org.mozilla.gecko.sync.net.BaseResource.go(BaseResource.java:296)
W/FxSync  (16278):      at org.mozilla.gecko.sync.net.BaseResource.get(BaseResource.java:302)
W/FxSync  (16278):      at org.mozilla.gecko.sync.setup.auth.EnsureUserExistenceStage$3.run(EnsureUserExistenceStage.java:111)
W/FxSync  (16278):      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
W/FxSync  (16278):      at java.util.concurrent.FutureTask.run(FutureTask.java:237)
W/FxSync  (16278):      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
W/FxSync  (16278):      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
W/FxSync  (16278):      at java.lang.Thread.run(Thread.java:841)

Comment 42

[Richard Newman [:rnewman]]

(In reply to Renaud Allard from comment #41)

> I am only permitting the following encryption schemes:

I think you want Bug 889749 instead of, or as well as, this bug.

> Firefox is able to access the URL from the browser part without even giving
> an error or warning (which is the expected behavior). So not being able to
> access ffsync for running a too high encryption scheme, while the browser
> supports it is a little bit strange.

Sync uses the Android network stack, not Gecko's.

Comment 43

[Markus Unterwaditzer]

(In reply to Richard Newman [:rnewman] from comment #42)
> (In reply to Renaud Allard from comment #41)
> 
> > I am only permitting the following encryption schemes:
> 
> I think you want Bug 889749 instead of, or as well as, this bug.
> 
> > Firefox is able to access the URL from the browser part without even giving
> > an error or warning (which is the expected behavior). So not being able to
> > access ffsync for running a too high encryption scheme, while the browser
> > supports it is a little bit strange.
> 
> Sync uses the Android network stack, not Gecko's.

That's interesting because i added a root CA to Android's CA store, added a site exception for the specific host i wanted to use with ffsync and it still raises the error given in the OP.

Comment 44

[Markus Unterwaditzer]

(In reply to Markus Unterwaditzer from comment #43)
> (In reply to Richard Newman [:rnewman] from comment #42)
> > (In reply to Renaud Allard from comment #41)
> > 
> > > I am only permitting the following encryption schemes:
> > 
> > I think you want Bug 889749 instead of, or as well as, this bug.
> > 
> > > Firefox is able to access the URL from the browser part without even giving
> > > an error or warning (which is the expected behavior). So not being able to
> > > access ffsync for running a too high encryption scheme, while the browser
> > > supports it is a little bit strange.
> > 
> > Sync uses the Android network stack, not Gecko's.
> 
> That's interesting because i added a root CA to Android's CA store, added a
> site exception for the specific host i wanted to use with ffsync and it
> still raises the error given in the OP.

I also verified that the site in question loads errorless in both Firefox and the default browser.

Comment 45

[Markus Unterwaditzer]

(In reply to Markus Unterwaditzer from comment #44)
> (In reply to Markus Unterwaditzer from comment #43)
> > (In reply to Richard Newman [:rnewman] from comment #42)
> > > (In reply to Renaud Allard from comment #41)
> > > 
> > > > I am only permitting the following encryption schemes:
> > > 
> > > I think you want Bug 889749 instead of, or as well as, this bug.
> > > 
> > > > Firefox is able to access the URL from the browser part without even giving
> > > > an error or warning (which is the expected behavior). So not being able to
> > > > access ffsync for running a too high encryption scheme, while the browser
> > > > supports it is a little bit strange.
> > > 
> > > Sync uses the Android network stack, not Gecko's.
> > 
> > That's interesting because i added a root CA to Android's CA store, added a
> > site exception for the specific host i wanted to use with ffsync and it
> > still raises the error given in the OP.
> 
> I also verified that the site in question loads errorless in both Firefox
> and the default browser.

Sorry for the noise, adding RC4+RSA to the server's cipher list fixes the issue, as already mentioned.

Comment 46

[Nick Alexander :nalexander [he/him]]

> Sorry for the noise, adding RC4+RSA to the server's cipher list fixes the
> issue, as already mentioned.

Yeah, sorry for forcing a weak ciphersuite.  We're considering landing https://hg.mozilla.org/projects/elm/rev/589597d28687 onto trunk, which at least includes two modern ciphersuites.  The list is so small because it is the intersection of what several different Java environments support.

Comment 47

[djk]

[Tracking Requested - why for this release]:

Comment 50

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.