How to setup an ssl certificate on docker mumble server?

Istria1704 commented 1 year ago

The issue

I'm wondering if I could get some help with setting up my Mumble server with a ssl certificate. So that I don't have to convince my gaming friends I'm not trying to hack them when they get the "untrusted certificate" message.

So I recently installed a Mumble server using docker-compose.

Normally, I use Nginx Proxy Manager to set up ssl to the various services I'm running on my homeserver. It's a noob-friendly GUI. You click "add proxy", set the subdomain, forwarding up address and port, and then click "request ssl certificate". And voila, it works.

So my domain is "example.com" which points to my ISP ip address. Also all subdomains point to the same ip (A records are example.com and *.example.com). In the ISP router, ports 80 and 443 are forwarded to the VM running Nginx Proxy Manager. This is how it works now for plex, nextcloud, etc.

Could someone help me with which steps I should go through to basically get rid of the "untrusted certificate" message with the docker-based Mumble server? Adding a proxy in Nginx Proxy Manager and forwarding "mumble.example.com" to the ip and port the docker server is running on doesn't seem to work.

Thanks I advance!

Mumble version

Latest as of last week.

Mumble component

Server

OS

Linux

Additional information

No response

Istria1704 commented 1 year ago

Update: I have made some progress.

I forwarded port 443 and 80 to the VM that is running docker where the mumble server container is running on.

Then I used certbot to generate an ssl certificate.

In the docker compose file, I added: volumes:

/opt/mumble/data:/data

I put the ssl files in /opt/mumble/data.

I added environment variables to the docker-compose file pointing to the ssl files.

But the result is that the docker container won't start anymore. It just keeps restarting every 1 or 2 seconds.

I thought maybe mumble doesn't have permission to read the root-owned ssl files. So I tried using MURMUR_USE_CAPABILITIES=1. But the server still won't start.

Any idea what I'm doing wrong? Is the MURMUR_USE_CAPABILITIES=1 depricated perhaps? Since I noticed most "murmur" references (like murmur.ini), are called mumbleserver.ini in the repo now.

Thanks again in advance!

Krzmbrzl commented 1 year ago

If you are using 1.5 then chances are this option is now called something like MUMBLE_SERVER_USE_CAPABILITIES.

bioluks commented 1 year ago

I thought maybe mumble doesn't have permission to read the root-owned ssl files. So I tried using MURMUR_USE_CAPABILITIES=1. But the server still won't start.

I had the same issues, also using the docker container. Like you said it's probably because of missing permissions. A not so cool method I used for this was to copy the certificate and key to a separate location that is bound inside the container, chmod 744 the key file (key.pem) only so the Mumble/Murmur docker container can read it (it's now readable for everybody on your system, just FYI). After the chmod command you obviously have to restart the container. If you have a very serious use case for voice chatting on Mumble, depending on your threat model this may not be the best method; if it's gaming in general I wouldn't bother though, especially if you are using VM's on top of that. Since there is no automation involved you would have to copy the new files over again after the certificate renewal.

Krzmbrzl commented 1 year ago

@azlux do you have experience with this?

Istria1704 commented 1 year ago

@bioluks,

I think that workaround could be acceptable for me. I just use it for simple gaming voice chat with some friends. So there is no very high demand for a super safe hack-proof system. If someone wants to hack me and listen in, he/she can feel welcome and join in on the gaming. =p

What would exactly be the risk of this method? What would be the worst thing someone with bad intentions could do? In my case, mumble is running in a docker container. And docker is running in a (unprivileged) lxc container. However, there are other docker containers running inside that same lxc container. Could this put those other containers at risk too?

To make sure I understood you correctly: So you copied the certificate files to INSIDE the docker container? So not in a directory that you mounted/bound via the docker compose file? And if so, what is the path you used in the docker compose file to point to the certificate?

Thanks for the help! Most of my gaming friends seem to just click past the "untrusted certificate" warning. But I already received a "what kind of espionage shizzle is this?" in the WhatsApp group. =p

@Krzmbrzl I tried the MUMBLE_SERVER_USE_CAPABILITIES too, but it also resulted in the server just restarting over and over. =(

bioluks commented 1 year ago

@Istria1704 A malicious script/unauthorized access to your system could decrypt your encrypted traffic since key.pem is readable by everyone. This is exaggeration for both of us since we don't have extreme use cases. To make things easier not only for you but anybody with this problem here is a fully working docker-compose:

version: '3.3'

services:
    mumble-server:
        image: mumblevoip/mumble-server:v1.4.230-6
        container_name: murmur
        hostname: murmur
        restart: always
        volumes:
            - type: bind
              source: ./data/mumble
              target: /data
              read_only: false
            - type: bind
              source: ./data/certificates
              target: /certificates
              read_only: false
        environment:
            MUMBLE_CONFIG_SSL_CERT: /certificates/cert.pem
            MUMBLE_CONFIG_SSL_KEY: /certificates/key.pem
            MUMBLE_SUPERUSER_PASSWORD: <your-superuser-password>
            MUMBLE_CONFIG_SERVERPASSWORD: <your-server-password>
            MUMBLE_CONFIG_USERS: 1000 # Max amount of users that can connect at the same time
            MUMBLE_CONFIG_USERSPERCHANNEL: 0  # Means unlimited if zero
            MUMBLE_CONFIG_WELCOMETEXT: "Welcome to my server. bla bla bla"
            MUMBLE_CONFIG_ALLOWHTML: true
        ports:
            - 64738:64738/tcp
            - 64738:64738/udp
#       expose:
#           - 6502 --> Needed for ICE RPC

Notice how the files are in the current directory inside data/certificates. The permissions are as follows:

the cert.pem is readable by default, but for the key.pem file you'll need to chmod 744 it.

And about the gaming group. It's always like this, speaking from experience they never question the big brother apps and companies but don't you dare as a fellow friend to care about their and your own privacy! It's totally okay if they steal data or spy, because then if you ask them there is nothing to hide.

Istria1704 commented 1 year ago

Yes! Got it to work finally! Thank you @bioluks for your example yml.

I did have to make some changes in order for it to work for me:

Added user: root to the docker-compose.yml. Without it, it was unable to bind the directories and would just keep restarting over and over again.
MUMBLE_CONFIG_SSL_CERT: /certificates/cert.pem MUMBLE_CONFIG_SSL_KEY: /certificates/key.pem had to be changed to: MUMBLE_CONFIG_SSL_CERT: /certificates/fullchain.pem MUMBLE_CONFIG_SSL_KEY: /certificates/privkey.pem

With those 2 changes, it worked! No more 'untrusted certificate' warning. =)

And about the gaming group. To be honest, I can hardly blame them. When something is well known like Discord, Facebook, Google, etc., and "everyone" knows and uses it, I guess it "feels" safe. But when some dude you barely know suggests to connect to some voice chat service you've never heard of, with a domain extension you've never heard of ("what the hell is .cc???) and then you get a large warning popup with the word "UNTRUSTED" in it, I can understand you could become suspicious of it. Especially if you're not tech-savvy.

Anyway, thanks again for helping me getting this to work properly!

bioluks commented 1 year ago

@Istria1704 Glad to hear it worked for you, no problem 👍

You are right about the key.pem and cert.pem files, mine were named like this but Let'sEncrypt users have fullchain.pem and privkey.pem instead.

About the gaming group, again; a well-known TLD and a readable domain could help ;)

Just out of curiosity, did you need to change the file permissions of privkey.pem or was copying it over enough? Or did you directly bind the LetsEncrypt directory?

Istria1704 commented 1 year ago

I didn't try weather it worked or not with Mumble before chmodding the file. But I did see under ls -la that the privkey file had no reading permissions for "others" before chmod. And did (same as in your example) after.

P.S. Should I close this issue/thread now? Or leave it open in case someone else has similar problems and/or additional questions? Not sure what the github etiquette/protocol is.

Krzmbrzl commented 1 year ago

Let's close it as it has been resolved. It can still be found by future users if they search for their problem.

mumble-voip / mumble-docker