Using Caddy to Handle Mumble Server Certificates

If you’re hosting a mumble server, it’s nice to get a server certificate so that your server is trusted by default. This means that people joining your server won’t have to manually accept a self-signed server certificate.

Typically, you might use Let’s Encrypt (or similar) to get a standalone certificate for the mumble server, and then link to those in /etc/mumble-server.ini. If you go this route, you probably have set up certbot or acme.sh just to auto-renew and handle your mumble server certificate.

That’s the set up I used to have. But, in the spirit of reducing the number of tools I’m using and simplifying my server setup, I started using Caddy, which I was already using as a reverse proxy, to also handle renewing my mumble server certificates.

The main challenge with this was tracking down the right location for where the certificates are stored, and making sure mumble-server could access those files.

When run as a system service, caddy the server runs as caddy the user, whose default home directory is in /var/lib/caddy. You can see where your installation’s locations are by running

sudo journalctl -u caddy

And looking at the environment variables.

Next, we need to add the mumble server to the Caddyfile in /etc/caddy/Caddyfile.

...other websites here...

mumble.example.com {
    reverse_proxy localhost:64738
}

Just the existence of the entry in the Caddyfile will cause Caddy to automatically get and renew SSL certificates for the domain.

Finally, we can update /etc/mumble-server.ini with the paths to the certificate and key. It will likely look something like this:

; If you have a proper SSL certificate, you can provide the filenames here.
; Otherwise, Murmur will create its own certificate automatically.
sslCert=/var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/<example>/<example>.crt
sslKey=/var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/<example>/<example>.key

Restart the mumble-server and the certificate should be handled.

You can make sure there are not any issues by checking the mumble-server log:

$ sudo tail -f /var/log/mumble-server/mumble-server.log

Note that if you have a long-running mumble server, you will need to restart the server in order to grab new certificates once they expire. Caddy will still get the new certificate, but the mumble server won’t use it if it was changed until a restart.

Posts from blogs I follow

OpenAI Is A Bad Business

OpenAI, a non-profit AI company that will lose anywhere from $4 billion to $5 billion this year, will at some point in the next six or so months convert into a for-profit AI company, at which point it will continue to lose money in exactly the same way. Sh…

via Ed Zitron's Where's Your Ed At October 02, 2024

The Fastest Mutexes

Imagine you have a workload where all your threads need to do a serialized operation. With Cosmo, if you're looking at htop, then it's going to appear like only one core is active, whereas glibc and musl libc will fill up your entir…

via justine.lol October 02, 2024

Querying Metrics with OxQL

Bryan and Adam were joined by Oxide colleague, Ben Naecker, to talk about OxQL--the Oxide Query Language we've developed for interacting with our metrics system. Yes, another query language, and, yes, we're DSL maximalists, but listen in before you accuse …

via Oxide and Friends October 02, 2024

Generated by openring-rs from my blogroll.