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

The Past, Present, and Future of Digital Storytelling with Ramy Katrib

Ramy Katrib has been at the forefront of digital storytelling for over 25 years, with his post-production company, DigitalFilm Tree, earning a reputation as one of Hollywood's most technically adventurous post-production houses. He joined Bryan and Adam to explore the past, prese…

via Oxide and Friends July 23, 2026

On AI

In 2019, I started watching Andreas Kling's programming videos, many of which were live-coding sessions writing his new operating system Serenity OS. He was always pretty fast at writing code, especially since his IDE, Qt Creator, had knowledge of all his C++ code and could auto-…

via joshua stein July 23, 2026

Hardening Rust Code For Production

We talked about patterns for defensive programming in Rust before, in which implicit invariants that aren’t enforced by the compiler lead to utter misery. But being careful isn’t enough! Even valid code can fail at runtime in ways that are hard to predict and control. That’s what…

via Corrode Rust Consulting July 23, 2026

Generated by openring-rs from my blogroll.