Difference between revisions of "Obtaining a Let's Encrypt Murmur Certificate"

From Mumble Wiki
Jump to: navigation, search
(Update sslCert/sslKey comment.)
(Live Reloading of Certificates)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Let's Encrypt provides a variety of ways how to get a certificate for your server for free but you must have a domain name you own, how to set up certbot or how to verify your domain depends on a high variety of factors, thus descibing the process for all the distributions is out of scope of this wiki entry. For Ubuntu 16.04 (with nginx) you can try [https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04 this guide].  
+
Let’s Encrypt is a trusted Certificate Authority. Using a certificate signed/created by them will make your server "trusted" by default. Users will not have to manually accept the server certificate as trusted. To indicate these "strong" server certificates, such servers are marked green in the public server list and on the servers root channel.
  
Using Let's Encrypt is an easy way to make sure the people connecting to your server know it's actually you that is hosting the server, as it's pretty hard to hijack Let's Encrypt to create a valid certificate for any malicious entity (unless your (DNS) server gets compromised).
+
Let's Encrypt provides a variety of ways how to get a certificate for your server for free but you must have a domain name you own. How to verify you own your domain depends on a high variety of factors. Please refer to the [https://letsencrypt.org/getting-started/ official Getting Started documentation of Let’s Encrypt]. ([https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04 This guide] for Ubuntu 16.04 and nginx by DigitalOcean may also be helpful.)
  
Example configuration you may need to add or modify in your mumble-server.ini:
+
In short: You will verify that you own the domain by making a file accessible through HTTP at a specified URL according to the ACME protocol. Depending on your system and Webserver this can be automated without configuration, or automated with manual web configuration. After obtaining an initial certificate, it should be renewed regularly (through an automated process), before the current certificate expires.
 +
 
 +
In your ''mumble-server.ini'' configuration file you will have to set the ''sslCert'' and ''sslKey'' settings to point to the respective certificate files:
  
 
  # The files fullchain.pem and privkey.pem should be the ones in the certificate folder letsencrypt created.
 
  # The files fullchain.pem and privkey.pem should be the ones in the certificate folder letsencrypt created.
  # Murmur needs restarting to load new certificates.
+
  # The server needs to be restarted to load the new settings/certificates.
 
  sslCert=''[path to]''/fullchain.pem
 
  sslCert=''[path to]''/fullchain.pem
 
  sslKey=''[path to]''/privkey.pem
 
  sslKey=''[path to]''/privkey.pem
 +
 +
The path (apart from the domain name) is likely to be:
 +
 +
sslCert=/etc/letsencrypt/live/''mumble.example.com''/fullchain.pem
 +
sslKey=/etc/letsencrypt/live/''mumble.example.com''/privkey.pem
 
   
 
   
# Has to be generated with for example '''sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048'''
+
 
  sslDHParams=/etc/ssl/certs/dhparam.pem
+
If your server fails to load the certificate files (due to insufficient permissions) it may be necessary to give directory execute permissions to the folders in the path ''/etc/letsencrypt/live/''mumble.example.com'' and ''/etc/letsencrypt/archive/''mumble.example.com'' for the server to be able to read the certificate files inside of them. The log warning message looks like this:
# Just using HIGH does not work, the clients do not support the strongest ciphers
+
 
  sslCiphers=EECDH+AESGCM:EDH+AESGCM:AES256-SHA:EDH+aRSA+AESGCM:AES256+EECDH:AES2
+
  ''<C>[date time] Failed to read /etc/letsencrypt/live/mumble.example.org/cert.pem''
 +
 
 +
=Live Reloading of Certificates=
 +
 
 +
From Version 1.3.0 onwards (commit [https://github.com/mumble-voip/mumble/commit/1742f8698377b187a6dabc0047ab64e4ad00dc35 1742f8]), SIGUSR1 can be used to reload SSL settings. So after you updated the Let’s Encrypt certificate you should call SIGUSR1 on the Mumble server process to make it load the new certificate.
 +
 
 +
Depending on your setup of automatic certificate renewal, this may look like this:
 +
 
 +
File ''/etc/cron.daily/letsencrypt''
 +
 
 +
  /opt/certbot/certbot-auto renew --quiet --post-hook "service nginx reload ; start-stop-daemon --quiet --oknodo --stop --signal 10 --pidfile /var/run/mumble-server/mumble-server.pid"
 +
 
 +
[[Category:Documentation English]]

Latest revision as of 15:19, 17 April 2017

Let’s Encrypt is a trusted Certificate Authority. Using a certificate signed/created by them will make your server "trusted" by default. Users will not have to manually accept the server certificate as trusted. To indicate these "strong" server certificates, such servers are marked green in the public server list and on the servers root channel.

Let's Encrypt provides a variety of ways how to get a certificate for your server for free but you must have a domain name you own. How to verify you own your domain depends on a high variety of factors. Please refer to the official Getting Started documentation of Let’s Encrypt. (This guide for Ubuntu 16.04 and nginx by DigitalOcean may also be helpful.)

In short: You will verify that you own the domain by making a file accessible through HTTP at a specified URL according to the ACME protocol. Depending on your system and Webserver this can be automated without configuration, or automated with manual web configuration. After obtaining an initial certificate, it should be renewed regularly (through an automated process), before the current certificate expires.

In your mumble-server.ini configuration file you will have to set the sslCert and sslKey settings to point to the respective certificate files:

# The files fullchain.pem and privkey.pem should be the ones in the certificate folder letsencrypt created.
# The server needs to be restarted to load the new settings/certificates.
sslCert=[path to]/fullchain.pem
sslKey=[path to]/privkey.pem

The path (apart from the domain name) is likely to be:

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

If your server fails to load the certificate files (due to insufficient permissions) it may be necessary to give directory execute permissions to the folders in the path /etc/letsencrypt/live/mumble.example.com and /etc/letsencrypt/archive/mumble.example.com for the server to be able to read the certificate files inside of them. The log warning message looks like this:

<C>[date time] Failed to read /etc/letsencrypt/live/mumble.example.org/cert.pem

Live Reloading of Certificates

From Version 1.3.0 onwards (commit 1742f8), SIGUSR1 can be used to reload SSL settings. So after you updated the Let’s Encrypt certificate you should call SIGUSR1 on the Mumble server process to make it load the new certificate.

Depending on your setup of automatic certificate renewal, this may look like this:

File /etc/cron.daily/letsencrypt

/opt/certbot/certbot-auto renew --quiet --post-hook "service nginx reload ; start-stop-daemon --quiet --oknodo --stop --signal 10 --pidfile /var/run/mumble-server/mumble-server.pid"