Certificate and Key format?

[foobar13373]

I have a .pem file and a .key file (from Let's Encrypt https://letsencrypt.org/), in the format -----BEGIN PRIVATE KEY----- and -----BEGIN CERTIFICATE----- respectivley, followed by a block of gibberish (the keys) and then the END lines. But I only get the message "Failed to read murmur.pem" and "Failed to read murmur.key" when writing them into mumble-server.ini to sslCert and sslKey.

The certificate and key is working fully fine with web servers (lighttpd and apache). In what format do the files need to be for murmur/mumble?

[mkrautz]

Is your Let's Encrypt certificate using RSA keys?

Murmur currently only supports RSA in certificates. 1.3.0 will hopefully support ECDSA as well.

[mkrautz]

And to answer your question: Murmur will work with PEM certs and keys.

Perhaps your issue is that Murmur doesn't have permission to read the files?

[foobar13373]

Yes, RSA, with key length 4096 as it seems. I worked with auto-generated certs before, do I have to clean some cache now, or something? I run murmur as root.

[mkrautz]

That should work fine. Did you check the permissions?

[foobar13373]

The permissions of what? The cert/key files are root:root with 400. murmur runs as root.

[foobar13373]

Oh, no, just saw that mumble does NOT run as root... But I did set uname=root in the ini. Why is this ignored? Do I have to change the daemon somehow? It's running as a daemon on Debian jessie.

[mkrautz]

If you REALLY, REALLY, want root, you should NOT set the uname field in the ini.

[foobar13373]

If I comment uname it out it still starts as the mumble-server user, starting it with sudo service mumble-server start.

[mkrautz]

I do not know what system you are on, but perhaps the init script (or equivalent) is explicitly launching murmurd as a less privileged user?

[foobar13373]

I changed the cert/key onwer to mumble-server and now it works. Thanks for you help. :)

Teh docs could be a bit more detailed on this issue, however.

[mkrautz]

Well, that's tough. You don't even specify what system you're trying to run it on.

The user the daemon drops to is chosen by the packager. Or, at least can be.

It's hard to document in exact steps, but I suppose it can be documented generally.

What would have helped you in this case?

A comment near the cert and key options in the ini, reminding users that the daemon might drop privileges, and thus the files should be readable by the daemon with dropped privileges?

[mkrautz]

Moved discussion of .ini file changes to mumble-voip/mumble#1950

Thanks.

[janschejbal]

For others having this problem, on Ubuntu 14.04 LTS, as of today, Mumble seems to drop privileges in two different places: Mumble itself will drop privileges after loading the certificate, meaning it can deal with root-only readable certificates. However, the init script /etc/init.d/mumble-server will also drop privileges as it starts the process (i.e. before loading certs) by passing --chuid $USER:$GROUP to start-stop-daemon if MURMUR_USE_CAPABILITIES is not 1.

The solution for this problem is running sudo dpkg-reconfigure mumble-server and allowing it to use priority in the second dialog. This will set MURMUR_USE_CAPABILITIES=1 in /etc/defaults/mumble-server. Subsequently, murmur will load the certificates with root privileges, then drop the privileges itself.

Regarding the format, use a full chain in PEM format for sslCert and a private key in PEM format for sslKey. For letsencrypt, that would be

sslCert=/etc/letsencrypt/live/somehost.example.com/fullchain.pem
sslKey=/etc/letsencrypt/live/somehost.example.com/privkey.pem

The chain in the client UI will show the server cert twice, once on top and once on the bottom, but this seems to be normal (haven't seen a server where this doesn't happen nor could I find a config that would not make it happen) and it will work without issue.

[sefsh]

Much obliged @janschejbal 🎉