I am self-hosting an XMPP-server running Prosody 0.10 with a certificate from Let’s Encrypt. Connecting to this XMPP-server using the XMPP-client Conversations on an LG Galaxy Nexus 5 (running either stock Android or LineageOS Android 7.1) has worked like a charm for a year or so.
I recently acquired a Samsung Galaxy S8 (Android 7.0) and Conversations on that device refuses to connect to the above mentioned XMPP-server, claiming “TLS negotiation failed”.
On the server side, all I can see is Prosody saying “Client disconnected: no shared cipher”. However, when I run adb logcat -s conversations on the phone in USB debugging mode I see “TLS certificate verification failed” from the client (Conversations).
Indeed, Let’s Encrypt’s CA certificates are not on the list of the phone’s security certificates. So I installed the two X3 certifcates on the phone and tried to serve each of them (in turn) together with the Let’s Encrypt cerificate for my server. Still no luck.
Has anyone run into the same problem and – more imprtant – solved the problem?
The Let’s Encrypt Intermediate Authority X3 is an intermediate certificate authority; it chains up to the DST Root CA X3 which is present in most devices. It is not necessary to install it manually (and it could change one day, it is numbered three for a reason…)
Most Let’s Encrypt clients create a file called fullchain.pem that contains your certificate and a copy of the Let’s Encrypt Intermediate Authority X3 signed by the DST Root CA. This is what you should use as your certificate file with prosody.
Since Android is not indicating a certificate problem but a cipher problem, I’m curious what ciphers your server offers.
If you have python installed on your computer, you can install a tool called sslyze that can analyze the cipher configuration of XMPP servers. (Python generally comes with Linux and Mac and can be easily installed on Windows.) Open a command prompt/terminal and run pip install sslyzeoreasy_install sslyze to install it and then python -m sslyze --starttls=xmpp --regular yourxmppserver.com:5222 to run an analysis. If you share that with us we might be able to point out what is troubling your device.
In addition, if you have any options set in the ssl = {} section of your prosody config besides the certificate and key files, please share those as well.
Another popular option is https://www.ssllabs.com/ssltest/ which can tell you about your ciphersuite settings and, to some extent, about the resulting client compatibility.
Thanks for your suggestions. I have a lot to try now.
What baffles me is that the same version of Conversations, installed from the same source (F-Droid or Play Store) on two different phones behave diffrently when trying to log in with the same account on the same server. And it doesn’t have any effect (on loginability) whether I use custom options in Prosody or not.
I have already established now that it can’t be the certificate chain as both phones can log in to another account on another server that also uses a Let’s Encrypt certificate.
Prosody uses the secp384r1 curve. I wonder if the underlying SSL library on the S8 uses another curve.
Careful with that, we have lots of Let's Encrypt sites that have the chain configured incorrectly and lots that have it configured correctly. The choice of certificate authority isn't what makes the chain correctly or incorrectly configured on a particular site.
Unfortunately SSLLabs won't work with an XMPP server.
I don't know why my web search yesterday didn't turn this up, but https://check.messaging.one appears to provide similar information for XMPP servers, if the OP would prefer a web-based tool.
It's because it uses the Android SSL stack. I wouldn't be the least bit surprised if TouchWiz is broken in some way and vanilla Android is not.
SSL Labs only works on port 443, the default port number for HTTPS. If you can somehow make your server listen temporarily on TCP port 443, then you can trick SSL Labs into scanning your TLS implementation.
Alternatively you can try https://www.htbridge.com/ssl/ which allows the usage of custom defined TCP ports.
The XMPP host in question had an elliptic curve certificate (P384). This has never caused any problems — neither on my XMPP server, nor on my webserver. I don’t know what Samsung has done to the SSL stack on the otherwise brand new Galaxy S8, but it didn’t like an EC certificate. As soon as I changed the certificate to an RSA4096 certificate, the XMPP client connected without any problems.
Thanks to everyone who has helped and given suggestions for how to proceed.
(Should I add “[SOLVED]” to the subject line now?)
