Let’s Encrypt certificates for TURNS are rejected

I tried dev 0.23 build from https://buildkite.com/matrix-dot-org/riotx-android/builds/2964

It has the same TURNS error reported previously, here and here. The coturn is checked it with is 4.5.1.2.

The coturn config looks like so,

listening-port=3478
tls-listening-port=5349
alt-listening-port=3479
alt-tls-listening-port=5350
listening-ip=192.168.1.10
external-ip=xx.xx.xx.xx
min-port=49152
max-port=65535
verbose
fingerprint
use-auth-secret
static-auth-secret=xx
realm=turn.mydomain.com
userdb=/var/lib/turnserver/turndb
stale-nonce=600
cert=/etc/letsencrypt/live/mydomain.com/fullchain.pem
pkey=/etc/letsencrypt/live/mydomain.com/privkey.pem
cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5"
no-multicast-peers
mobility
cli-password=xx
no-tlsv1
no-tlsv1_1

[buzzdx]

It seems that what was mentioned in my previous post is correct. I switched to ZeroSSL certificates as replacements for Let’s Encrypt certificates, and without any other change, Element Android was immediately able to connect voice and video calls using turns across different networks. So the problem is indeed that for some reason, maybe that webrtc library having an incomplete list of trusted CAs as mentioned above, Element Android does not accept Let’s Encrypt certificates. The Jitsi devs have an open ticket where they stated that for now they will add Let’s Encrypt to the webrtc-lib’s trusted ca list. Maybe someone could do the same for Element Android?

[buzzdx]

i’m having the same problem. synapse and coturn are both set up to use turns. when i try to make a call from element android app to another android app on a different network the turnserver logs look like this:

turnserver[14012]: 860: IPv4. tcp or tls connected to: a.b.c.d:58145 turnserver[14012]: 860: session 001000000000000028: TLS/TCP socket disconnected: a.b.c.d.5:58145 turnserver[14012]: 860: session 001000000000000028: usage: realm=<my_realms>, username=<>, rp=0, rb=0, sp=0, sb=0 turnserver[14012]: 860: session 001000000000000028: closed (2nd stage), user <> realm <my_realms> origin <>, local h.i.j.k:5349, remote a.b.c.d, reason: TLS/TCP socket buffer operation error (callback)

when i switch the turn_uris to begin with turn: instead of turns: it works flawlessly from any device to any device (phone to app, app to phone, all over different networks).

as soon as tls is used with the android app it does not work anymore. this seems to be a real problem as there are more than one discussions about it on github and other sites.

coturn has access to the certs, which are let’s encrypt certs, as many others described.

this may be off topic, but there’s also a problem with the android app where you cannot verify anything if your first login after account creation is made with the android app. had to use desktop/web app to do the first login, after that all works as expected.

would be really great if somebody could solve this, or point to a solution or potential upcoming fix. thanks.

edit: is it possible that this is the same problem we are seeing here? https://community.jitsi.org/t/android-app-rejecting-lets-encrypt-certificates-for-turns/29468

quote of the final post on that page:

The problem – as I understand it – is on the client side:

If the Android app connects to the webserver (nginx) via https it verifies the server certificate using the list of trusted root CAs that is built into the Android OS. Let’s Encrypt certificates are verified successfully. However, if the app cannot establish a connection to the videobridge directly and needs to fallback to the turnserver a “different part” of the Jitsi Meet Android app is used to establish the turns:// connection: This connection is apparently handled by a webrtc library (which seems to be included in the Jitsi App as a native library via react-webrtc). And the webrtc library does not use the list of trusted CAs which is provided by the Android OS. Instead, another list of trusted CAs is compiled into this library and only the CAs contained in this hardcoded list are used to verify the certificate that the app receives from the turn server. Unfortunately, this hardcoded list of CAs does not include the trust anchor that’s needed to trust a certificate issued by Let’s Encrypt.