Prosody certificate and Android app issues

Hello there,

First: thank you all for this beautiful project. This is my issue (sorry if i’m not a real expert in configuring certificates, i tried to search for this issue here in community and also on google and prosody website).

I have 2 servers both running Ubuntu 18-04: server “a” with apt install of jitsi-meet (fully working) and server “b” with an edited install (from github) of jibri (fully working).
The “a” (the server with meet) has a dns name registered under godaddy and using a godaddy certificate for subdomains; everything seems to work - no problem with trusting on ssl on all browsers - except the android app.
As i read here, this kind of problem is caused by not fully working certificate and, in fact, when i check for the ssl on my domain on digicert verification tool, there is one voice that i think is not good for android app ( TLS Certificate is not trusted).

What i tried:
for testing, i bought and generate a new ssl cert and tried to use the new one in prosody configuration. I also had to change the owner on the new files as prosody log reported an error in reading those files (chown prosody:prosody -R directory) and, finally, on prosody log there are no more errors. I also tried to renew godaddy’s certificate and do the same things as above. I also concatenated all cert files in one.

Results:
On android i’m able to join a room only by using chrome in “desktop version”; within the app it seems impossible as it get disconnected after selecting the room.
There is another strange thing (for me): after changing certificate and certificate authority in prosody domain config, after restarting prosody and jicofo and meet services, verifications on digicert (also by showing up certificates on chrome/firefox/edge), the certificate authority does not change (continuing to show godaddy and not the new one).
Is there something that i’m doing wrong or something i can do at this point?

Please let me know if you need more infos and really thank you to anyone who can spend some time in helping me with this issue.

EDIT
I’m not using nginx nor apache on the servers.

1 Like

I have the exact same issue with the android app. Meet is fully working on desktop and iOS but not android.

@Marco_Giordano why did you change your certificate?

Thanks in advance

Any suggestions? Why Jitsi works in android chrome (by forcing desktop view) and not in app?
Also the prosody cert thing is really strange to me.
Please help me, I just want to use your app in mobile and not to force Jitsi to work on mobile browsers.

Thank you.

Why this question seems to be less important than something else?

You can test your TLS setup using https://www.ssllabs.com/ssltest/ - this usually includes some indication about different user agents like mobiles vs desktop. As an example, older Android models may not support certain cipher suites or TLS protocol versions.

You should also make sure that the whole cert chain (including intermediate CA-certs) is correctly delivered. You can check this for example with openssl s_client -connect example.com:443 -showcerts. However, as far as I know, on Android both Apps and Chrome use the system CA store and terefore shold behave in the same way. Did you check adb logs to see whether the App logs something?

Have you applied the certificate settings to the http[s] service of prosody as described at https://prosody.im/doc/certificates#service_certificates ?

Hello there, I have the same Problem.
My Jitsi meet works on:

  • Chrome Desktop (or the mobile chrome with “Desktop site” checked)
  • latest iOS App (or inside the Rocket.Chat iOS App)

It does not work with the Android App however (or inside Rocket.Chat Android App)

I am running a test environment using a pretty vanilla jitsi/docker-jitsi-meet (from github) and the .env configurations for lets encrypt (which work like a charm, ssllabs reports no issues at all):

CONFIG=/etc/opt/jitsi-meet-cfg
HTTP_PORT=80
HTTPS_PORT=443
TZ=Europe/Zurich
PUBLIC_URL=https://meet.example.org
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.org
LETSENCRYPT_EMAIL=admin@meet.example.org
(the rest of the .env was unchanged)

I already tried lowering the TLS version in the nginx config -> still the same behavior.

The only other thing I edited was the CONFIG/web/nginx/ssl.conf file:

ssl_certificate /etc/letsencrypt/live/meet.example.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/meet.examle.org/privkey.pem;

I have encountered other installations of jitsi which work normally on android (for example open.meet.switch.ch ).

Thanks in advance for any insights and hints.

@Marco_Giordano Did you check which service is actually listening on port 443? Maybe its jetty or whatever server you use where you need to configure the certificates and not prosody. I believe prosody is normally used internally only by jvb and jicofo.

What error do you see, what makes you think its related to TLS? Do you see anything in adb logs? Or something in the nginx logs?

Hello Plokta, really thank you for helping!

So:

  • it seems that the process listening on 443 (on meet server) is only listed as “java”;
  • the cert chain is correct with the new one but - for some reason - “something” that is listening on 443 is using the incorrect and old cert. I have to find out what is the exact process and how to change the associated cert (maybe you could help me in this, if you can);
  • Did not check the logs of the app cause, unfortunately, i don’t really know how to but i’m just searching for it;
  • in prosody conf, it seems that everything is well configured (as also reported in your link).

More infos:
I mentioned nginx only because, for trying out new certificate, i had to use some “working” server and then i just installed nginx - before this step there was no nginx on the server (so after jitsi, but on same machine but with port 8443 for ssl) and tested that new cert was working good. After that, i stopped and then removed nginx. (sorry, this was an aswer for your latest reply but that was not for me)
My jitsi-meet is an “apt install” and was installed on a fresh new Ubuntu 18.04 server without having nginx or apache2 or anything else. It is working as provided by repository.
I think it’s something related to TLS because old certs (that something still uses) were incorrect and i read here on this community that most of the problems within the android apps (while everything was working good in iOS and others) were caused by ssl cert’s issues.

Thank you!

thanks for the reply @plokta

Well it was the just first thing that came to mind due to the fact that it
a) works perfectly fine on all other types of clients
b) works on this kind of device for other third-party installations (like open.meet.switch.ch)
I have no strong suspicion though.

I don’t get any errors on the server side (only http 200 access logs for nginx, no errors or warnings).
On the Android Phone it immediately shows You have been disconnected. You may want to check your network connection. Reconnecting in 26 sec…

I am not a Android Dev so setting up adb logging seems like a time-intensive last resort for me at the moment. If I find the time I may try to set it up over the weekend.

Here the adb logs when i try to connect to my server from android app

04-02 20:55:34.485 751 24893 E AntiBanding: antiBandingGetImageData(), error:sensor info is 0! 04-02 20:55:34.492 23951 24027 E JitsiMeetSDK: [features/base/lib-jitsi-meet] Failed to load config from https://MY.MEET.DOMAIN/config.js?room=popo Error(TypeError){“message”:“Network request failed”,“stack”:“TypeError: Network request failed\n at anonymous (index.android.bundle:135:7285)\n at call (native)\n at dispatchEvent (index.android.bundle:126:5676)\n at value (index.android.bundle:121:6095)\n at value (index.android.bundle:121:2835)\n at apply (native)\n at anonymous (index.android.bundle:121:5024)\n at apply (native)\n at value (index.android.bundle:50:1280)\n at apply (native)\n at value (index.android.bundle:37:3685)\n at anonymous (index.android.bundle:37:841)\n at value (index.android.bundle:37:2939)\n at value (index.android.bundle:37:813)”} 04-02 20:55:34.511 751 24898 I ImagingSystem: getOTPTestResult: OTP module_id=0x12,vendor_id=0x0,checksum=0x1 04-02 20:55:34.512 751 24898 I ImagingSystem: getOTPTestResult: check sucess. m_subotpresult = 0x0. 04-02 20:55:34.517 23951 24027 I JitsiMeetSDK: [features/overlay] The conference will be reloaded after 22 seconds. 04-02 20:55:34.517 751 24889 I ImagingSystem: getOtpInfo enter,type=1 04-02 20:55:34.517 751 24889 E ImagingSystem: getOtpInfo invalid arguments, type = 1 04-02 20:55:34.517 751 24889 E DeviceBaseImpl: [HWA_CAM3]getOtp() get SENSOR_OTP_AF otp failed! 04-02 20:55:34.517 23951 24027 D JitsiMeetSDK: ExternalAPI Sending event: CONFERENCE_TERMINATED with data: { NativeMap: {“url”:“https://MY.MEET.DOMAIN/popo”,“error”:“TypeError: Network request failed”} } 04-02 20:55:34.518 23951 23951 D JitsiMeetActivity: Conference terminated: {error=TypeError: Network request failed, url=https://MY.MEET.DOMAIN/popo}

Sorry, don’t really know what to make out of the Network request failed error, I was hoping for something in logs that clarifies if it really is a TLS error.

Nevertheless, I am pretty certain that the web certificate needs not be configured in prosody and wonder why you don’t have the default nginx configuration. Did you follow the quick install guide? How (and why) did you end up with no webserver installed? Usually nginx will be setup when using apt install ... (as described in https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md ).

Maybe you should consider to backup your certs, purge all jitsi related packages and do a clean installation. Or wait and hope that somebody else can help…

In your nginx log, do you see the GET request to /config.js with a 200 status? User agent should be okhttp, and this should be the first request from the app. If so, and assuming your setup always redirects http to https, than its likely not a TLS issue you are facing. Other than checking that I currently don’t have other ideas what to try, sorry.

1 Like

Thank you for your reply!

From the quick install (that is the one i followed for installing meet) it says: “If none of the above is found it then defaults to Nginx.”. So you’re right and, from the readme, i assumed that nginx had to be installed with other dipendencies automatically. In fact, i never had any nginx related folder on my system except /etc/nginx that was created after i manually installed nginx for testing purposes (as i said).

So now, my question is: who the hell is opening my machine to the internet? What kind of server? Are we sure that jitsi-meet really need nginx or similiar?
The only one processes i have under netstat (port 80 an 443) are by java on ipv6.

Unfortunately, none of the developers seemsto be able to answer this question.

Thank you again Plokta :slight_smile:

Ok, so from here [jitsi-dev] The way latest jitsi-videobridge listens on TCP port 443 it seems that, if you don’t have nginx and apache previously installed, everything is “orchestrated” by jitty (who is the “java” in netstat).
I have to find out how to modify jitty configuration.

EDIT
Just found something like this https://www.thesslstore.com/knowledgebase/ssl-install/jetty-java-http-servlet-webserver-ssl-installation/ and i think that, in this case, it will be much more easier to purge and reinstall meet with nginx or apache.

Hmmm I am using nginx and I am getting the same error as you @Marco_Giordano . Did using nginx fix your problem?

28617 E JitsiMeetSDK: [features/base/lib-jitsi-meet] Failed to load config from https://meet.example.ch/config.js?room=room Error(TypeError){"message":"Network request failed","stack":"TypeError: Network request failed\n    at anonymous (index.android.bundle:135:7285)\n    at call (native)\n    at dispatchEvent (index.android.bundle:126:5676)\n    at value (index.android.bundle:121:6095)\n    at value (index.android.bundle:121:2835)\n    at apply (native)\n    at anonymous (index.android.bundle:121:5024)\n    at apply (native)\n    at value (index.android.bundle:50:1280)\n    at apply (native)\n    at value (index.android.bundle:37:3685)\n    at anonymous (index.android.bundle:37:841)\n    at value (index.android.bundle:37:2939)\n    at value (index.android.bundle:37:813)"}

04-07 10:45:27.806 28547 28617 D JitsiMeetSDK: ExternalAPI Sending event: CONFERENCE_TERMINATED with data: { NativeMap: {“error”:“TypeError: Network request failed”,“url”:“https://meet.example.ch/room”} }
04-07 10:45:27.835 28547 28547 D JitsiMeetActivity: Conference terminated: {error=TypeError: Network request failed, url=https://meet.example.ch/room}

@plokta The android App never reaches my server (unlike the iOS app or webbrowsers). The iOS App does GET 200 the /config.js but the android app generates no access log at all.

So this could indeed be a failing TLS handshake then. However, I can only give some generic debugging tips at this point.

  • Do you see something in nginx’s error.log for the Android app?
  • What do you see anything unusual in a tcpdump on the server when trying to connect with the Android device? In particular, which TLS version, ciphersuites etc. are negotiated.
    • what differs when connecting with iOS?
  • What is the Android version (older versions require a cross-signed CA for Letsencrypt certificates to be trusted).
  • Do you place another webserver in front of the docker container?
1 Like

Hi,

Unfortunately my jitsi server is runningh without nginx or apache so i’m not able to use it on android app because none of the developers is trying to help me out on how to change certificates into jetty.

Also try to verify if your certificate is correctly created.

  • Do you see something in nginx’s error.log for the Android app?

No, nothing


What do you see anything unusual in a tcpdump on the server when trying to connect with the Android device? In particular, which TLS version, ciphersuites etc. are negotiated.

1      SYN-SENT       178.174.49.18:42449 > 157.230.101.129:https
1      SYN-RECEIVED   178.174.49.18:42449 > 157.230.101.129:https
1      ESTABLISHED    178.174.49.18:42449 > 157.230.101.129:https
...............................h2.http/1.1.......,.../.0.........../.5...d..............MY.DOMAIN.NAME.....#...
......
......(
1      FIN-WAIT-1     178.174.49.18:42449 > 157.230.101.129:https
1      FIN-WAIT-2     178.174.49.18:42449 > 157.230.101.129:https
1      TIME-WAIT      178.174.49.18:42449 > 157.230.101.129:https
1      CLOSED         178.174.49.18:42449 > 157.230.101.129:https
tcpick: done reading from android.pcap

10 packets captured
1 tcp sessions detected
  • TLS Version is 1.2
  • Cyphers:
Cipher Suites Length: 24
            Cipher Suites (12 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

what differs when connecting with iOS?

  • there are more ciphersuites:
Cipher Suites Length: 34
            Cipher Suites (17 suites)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
  • after TCP connection is established there comes data instead of FIN-WAIT-1 -> CLOSED (I can make out letsencrypt.org in the hex dump)

What is the Android version?

7.0


Do you place another webserver in front of the docker container?

no


thank you very much

thanks. well ssllabs says everything is fine and acording to letsencrypt every Android OS >= v2.3.6 should work which is definitely the case for me. it is also working in google chrome on the same android device which I assume uses the same trust store…?