Closed Bug 756763 Opened 12 years ago Closed 3 years ago

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

Categories

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

Product:
Firefox for Android Graveyard
Component:
Android Sync
Platform:
ARM
Android
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: dakkar, Unassigned)

References

Details

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.
Severity: normal → minor
OS: Linux → Android
Hardware: x86_64 → ARM
Let's see if the Sync team has a plan for this.
Severity: minor → normal
Status: UNCONFIRMED → NEW
Component: General → Android Sync
Ever confirmed: true
Product: Fennec Native → Mozilla Services
QA Contact: general → android-sync
Whiteboard: sync
Version: Firefox 14 → unspecified
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>
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
(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.
sync triage: not scoping for first release. p3
Priority: -- → P3
Gianni, also, thanks for filing :)
(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.
(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.
Blocks: 765064
See Also: → 789021
Whiteboard: sync
Priority creep. This seems to be a common request from more technical users, particularly because it just worked in XUL.
Priority: P3 → P2
What about those (me for instance) who do not want to root their phones (yet) is there progress on the UI customization front?
(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.
Doesn't this bug also apply to Android 4.x? In that case the title should be changed.
(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
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.
Summary: Native Sync can't accept self-signed certificates for custom Sync servers on Android 2 → Android Sync can't accept self-signed certificates (or roots unknown to Android) for custom Sync servers on Android 2
Of course, it really needs a CA certificate and not a "normal" used to sign the webserver certificate. (tried, it doesn't work)
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.
(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!
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.
(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.
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.
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?
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.
It's possible that you're using an unsupported cipher. A log would confirm it, but please file a new bug.
Product: Mozilla Services → Android Background Services
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
(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!
(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).
(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.
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
(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.
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.
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.
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.
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.
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.
(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.
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
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
(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.
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)
(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.
(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.
(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.
(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.
> 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.
Depends on: 789021
[Tracking Requested - why for this release]:
status-firefox45: --- → ?
tracking-firefox45: --- → ?
Priority: P2 → P3
Product: Android Background Services → Firefox for Android
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.