Its not about what is configured on the server side, nginx and the turn server should both serve the fullchain including intermediate CAs and the leave certificate.
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.
In my opinion, this is an unfortunate design of the webrtc library in multiple ways.
- First, the hardcoded list of root CAs is badly chosen because the list seems to be published by google for a different purpose: It appears to be a list of CAs that are issuing certificates for any of the various google services and thus may be required to be trusted if one wants to use these google services.
- Second, a library should not come with a hardcoded list of CAs, especially if it does not provide an API to override the list. If Google and Mozilla have a hard time to maintain a list of trustworthy CAs, how (ad why) should a library maintain its own list.
- Third, apps that include this library are required to upgrade to the latest release of the library on a regular basis just to keep the list of CAs up to date.
- Fourth, the existence of this CA list and the fact that it is used by the webrtc library for TURNS connections seems to be badly documented,
The above is how I understand the issue and I may of course be wrong on some points. Hopefully, @saghul can shed some light on this, please?