How to setup an ssl certificate on docker mumble server? about mumble-docker HOT 10 CLOSED

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!

from mumble-docker.

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

from mumble-docker.

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.

from mumble-docker.

@azlux do you have experience with this?

from mumble-docker.

@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. =(

from mumble-docker.

@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.

from mumble-docker.

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!

from mumble-docker.

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

from mumble-docker.

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.

from mumble-docker.

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

from mumble-docker.