Since this page was originally written certbot has improved significantly to the point where you should be able to use it straight out of the box.  Information below the warning has been left here to help troubleshoot if you run into difficulties rather than anything but if you install certbot with the apt then you should not have any problems.

Multiple sites served by the same certificate

If you want to have multiple sites served by the same certificate (usually for “mydomain.com” and “www.mydomain.com” for example then you can expand the certificate by running the following command:

certbot --expand -d mydomain.com,www.mydomain.com

You can add as many sub domains as you like, just separate each with a comma (,).

To check the certificate afterwards just run:

certbot certificates

and check the results.

NOTE:  You will almost certainly need to have a parent and www sub domain if you use the domain for both email and a website.

 

 

 

WARNING:  INFORMATION NOW OUTDATED AND ONLY RETAINED FOR HISTORICAL PURPOSES

For many purposes a self signed certificate is absolutely fine, but there are occasions where you need a valid certificate from a certificate authority.  Valid certificates can be quite expensive, especially if they are validating multiple domains, however there is a free certification service that offers certificates that last 90 days.  Now obviously you do not want to have to manually recertify every 90 days so it if you are going to use the certificates then it is a good idea to automate the renewal task.  Thankfully for this purpose we have “certbot” which will set up a cron job to renew the certificates before they expire.

 

Install

If you are on debian stretch then you can install certbot in the normal way, however if you are on Jessie then you will need to enable backports by adding this line:

deb http://ftp.debian.org/debian jessie-backports main

to your /etc/apt/list You can also find a list of other mirrors at https://www.debian.org/mirror/list

You can now install certbot by running

#apt-get install certbot -t jessie-backports

This will also install a load of python stuff if it is not already installed.

 

Apache

Certbot will run in a standalone mode, but if you have apache (as we do) you will need to amend some of the configuration files in order that certbot gets certificats for the right domains.  Next you need to install the certbot apache plugin (note you don’t need backports here regardless of os version).

#apt-get install python-certbot-apache

The next thing to do is to see what happens when you try to run certbot

#certbot --authenticator webroot --installer apache --staging

Certbot needs strictly written configuration files so correct any errors before going any further. If all is well you should see

Which names would you like to activate HTTPS for?

followed by a list of sites. Do not go any further for now (Press <CTRL>+c)

 

Mail server certificates

You will need to add those domains that are only used for your mail server to your default apache configuration file as ServerName or ServerAlias directives (ServerName for the top level and ServerAlias for any others)

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAlias mail.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
……
</VirtualHost>

If all is correct when you run

#service apache2 reload
#certbot --authenticator webroot --installer apache --staging

You should see the all the aliases that you have added in the list (again, do not go any further).

The way certbot works is that it creates a small file in the web root directory which it uses for validation. Once it has validated the domain then it deletes the file.

Certbot is reliant on port 80 for and plain old http for this validation because it may have to validate a site without there being an initial https setup.

In our particular setup, if you have set up apache then you will already have secure sites using self signed certificats (A step that I would recommend in all circumstances as it is a good fallback option should letsencrypt cease providing free certificates)

Now if we have any https based virtual hosts we need to amend the configuration files so that when certbot performs its validation routine it will complete the task successfully.

If you will look in a configuration file you will see something like

<VirtualHost *:80>
       ServerName webmail.example.com
       Redirect "/" https://webmail.example.com/
</VirtualHost>

This redirects all traffic to our https virtual host however this is no good for certbot for reasons outlined above, so we need to add an exception.  The easiest and arguably best way to do this is to enable the rewrite engine (# a2enmod rewrite), and replace the configuration above with something similar to the following:

<VirtualHost *:80>
    ServerName webmail.example.com
    Redirect "/" https://webmail.example.com/
    Documen193.237.11.183tRoot /var/lib/roundcube/
    CustomLog ${APACHE_LOG_DIR}/access.log common
    ErrorLog ${APACHE_LOG_DIR}/error.log
    RewriteEngine on
    RewriteRule ^/.well-known/ - [L]
    RewriteCond %{SERVER_NAME} =webmail.example.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

This is an example for a roundcube web portal. Note that it is important to set the DocumentRoot and ServerName correctly.

The magic happens here:

RewriteRule ^/.well-known/ - [L]

as this is the path where certbot puts the file that it uses for verification i.e. webmail.example.com.well-known……

You are advised to look at some of the live configuration files as they all have subtle differences.  Once you have everything configured you can reload apache and then go ahead and generate your certificates:

#certbot --authenticator webroot --installer apache

Follow the instructions on screen, and make sure you get the webroots correct or you will generate errors.

NOTE:  If you are not confident of your configuration then use the –staging flag first.

 

Setting the certificates for postfix

First of all you need to know the path of the certificate for your mailserver so just run

#certbot certificats

which should produce something like

Found the following certs:
Certificate Name: epsilon.inplico.uk
Domains: example.com mail.example.com webmail.someotherdomain.org.uk
Expiry Date: 2018-10-26 17:31:41+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem
----------------------------------------------------------------------

You can now amend your /etc/main.cf file to point at the new certifcates and restart postfix. Note that I like to comment out the original certificate paths rather than delete so that it is an easy reference should it be necessary to use the fallback option.

NOTE Don’t forget that you will need to reconfigure msmtp (see bacula) to use the new certificate as this is not an automated process.