Prosody certificate and Android app issues

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…?

From the redacted pcap its not even clear to me whether or not the TLS handshake was completed. In particular, we cannot see any errors or TLS alerts. If you have a full tcpdump of an Android connection (and maybe an iOS connection for comparison) but don’t want to post it here, feel free to send me a PM so that I can have a look - although I can’t promise anything, as I am not even sure that the TLS connection is the real issue here…

When you say:

Why was this necessary? Wasn’t this set automatically and if not, what had been set there by the automated config?

Do iOS and Android use the same http version (http2 vs http/1.1)?

In addition, as mentioned in another thread ( SOLVED: Android immediately disconnects, always ), you could check with https://whatsmychaincert.com/ if your server is really sending the whole cert chain.

I’m having a similar issue with the Android app (running on Android 10) when it tries to communicate with the coturn server via TURNS. When presented with a Let’s Encrypt certificate chain (with either the cross-signed intermediate or the ISRG-signed intermediate) the Android app sends an “Unknown CA” fatal TLS alert to coturn. Swapping the Let’s Encrypt certificate chain with a certificate chain signed by a different CA (InCommon in my case) results in a successful connection.

I had this working today by installing Jitsi after Nginx and using certificate by Comodo after failing using letsencrypt ones with nginx.

The letsencrypt certificate seems not to be working on Android (mine is kernel 4.4.23) as the fullchain it provides (when requesting certificate with certbot) is not correct.

I did this:

  • Buyed a cert from Comodo;
  • Concatened all cert files into one bundle.crt (i had 4 .crt files, one for domain and 3 for CA and intermediates): be careful as there is a certain order for concatenating crt files;
  • Installed it by changing the nginx sites-enabled (my.domain.conf) configuration;
  • Restarted everything;
  • Reinstalled Jitsi app and added my domain in its settings.

Hope this can help someone.

Here I found the correct chain order for two kind of CA (please tell me if it is not possible to mention vendors here):

For TrustSign
Example :

Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate 1 - USERTrustRSAAddTrustCA.crt
Intermediate CA Certificate 2 - TrustSignRSADVCA.crt
Your SSL Certificate - 000000000.crt (une chaine de chiffre)

For COMODO/ SECTIGO
Example :

Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate 1 - ComodoRSAAddTrustCA.crt OR ComodoECCAddTrustCA.crt
Intermediate CA Certificate 2 - ComodoRSADomain/Organization/ExtendedvalidationSecureServerCA.crt OR ComodoRSAECCDomain/Organization/ExtendedvalidationSecureServerCA.crt
Intermediate CA Certificate 3 - ComodoSHA256SecureServerCA.crt
Your SSL Certificate - yourDomain.crt
1 Like

is there an advantage for purchasing a cert, as opposed to getting one free at https://letsencrypt.org/

Not any that I would be aware of, no. Purchasing a cert from a commercial CA should not be required to host a Jitsi instance via TLS.

While you might be able to purchase commercial certificates with specific KeyUsage and ExtendedKeyUsage fields, LetsEncrypt certs come with defaults that are sufficient for server certificates, including for Jitsi Meet.

Make sure to configure your server to correctly serve the full chain of certificates. Very old devices may not recognize the LetsEncrypt CA, but that should rarely be an issue.
I think there was also some problem when using nginx to multiplex to the turnserver on port 443 but I cannot find the related forum thread atm.

Hi there,

I am experiencing the same issue.
I am getting “TLS Alert (Fatal): Unknown CA” when an Android 10 device tries to connect to my TURN server (installed by jitsi-meet) using the Android app.

The server is configured to use a LetsEncrypt certificate. The TURN is offering the fullchain.pem but for some reason the Android app does not seem to be trusting it when connecting to the TURN server using “turns”.

The error does not seem to show if I use Chrome with the desktop User Agent.

Has anyome been able to find the source of the problem?

Worked well for me too using a Gandi wildcard certificate bundled with the Intermediate Gandi pem.

UPDATE
I had this working by using nginx (and not Jetty; if I remember well now Jitsi uses nginx as default) and letsencrypt. A couple of times it seemed that certbot did not create certificates correctly, so I’ve had to re-run certbot for certificates.

There is also another issue, not depending on Jitsi: in Italy, when using Vodafone as a provider, it seems that it considers letsencrypt certificates not trusted as Vodafone has a proprietary security system called “Vodafone Secure Net” and you need to disable it.

Anyway, everything is working good now.