element-android: 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
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 11
- Comments: 23 (4 by maintainers)
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?
I just had a WebRTC call via matrix and by looking at the remote candidates (my buddy was using element android) it seems that letsencrypt certificates work. My own coturn server which offers TURNS, started to show up as a remote candidate with both IPv4 and IPv6 addresses.
The call was built in the end with my Librewolf using my TURN server, that talked to directly his IPv6 address. Call quality was good.
Can someone confirm?
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:
I believe this is a security issue!