We’ve come a long way since we launched Encrypt the Web, our initiative to onboard the World Wide Web to HTTPS. Not only has Let’s Encrypt issued over 380 million certificates, but also nearly 85% of page loads in the United States are over HTTPS, and both figures are still on an upward trajectory.

However, TLS, the technology that helps to secure HTTP connections, can and should be used to protect all Internet communications—not just the HTTP protocol used to fetch webpages. Though HTTP/S makes up the majority of Internet traffic, there are other network protocols out there that are extremely important to secure. The Internet’s address book, file-sharing between computers, and email don’t use HTTP; they use other communication protocols which are also insecure by default and can benefit from TLS as well, to varying degrees of success.

Since most of Certbot’s users are website owners, most of Certbot’s documentation (and our own TLS messaging) is geared towards this demographic. The “Software” section of Certbot’s instruction generator only lists popular webserver software and reverse proxies.

But we’ve decided to expand our mission—from Encrypting the Web to Encrypting the Internet. And we’re tackling SMTP, the protocol that servers used to send email, next! With the most recent release of Certbot v0.29.1, we’ve added some features which make it much easier to use with both Sendmail and Exim. In this guide, we’ll explain how to use Certbot and Let’s Encrypt if you’re trying to secure a mailserver (or actually, anything that isn’t a webserver).

Brief background: How does Certbot work?

Let’s Encrypt is a Certificate Authority, which issues certificates, and Certbot is a piece of software you run on your server that requests them for you. Certbot makes these requests to Let’s Encrypt’s servers using a standardized protocol called ACME.

As part of the ACME protocol, Let’s Encrypt will issue a “challenge” to your server, asking it to prove control over the domain you’re trying to get a certificate for. The most common way to do this requires your server to use port 80 to serve a file with a particular set of contents.

Obtaining and renewing your TLS Certificate

Since the most common ACME challenge that Certbot performs is over port 80, the complexity in Certbot’s most popular webserver plugins (namely, Apache and Nginx) are so that website owners can obtain and renew certificates while still serving content from the same port 80 without experiencing downtime.

If you’re running a mailserver, you might not have a complex service competing for port 80 on your machine, so you don’t need all these bells and whistles. If you do have a webserver running on port 80, you can also supply a webroot directory for Certbot to use. Either way, Certbot is still easy to use!

First, use our instruction generator for the recommended way to install Certbot on your platform:

1. Choose “None of the above” in the software selector. In the system selector, choose the closest match to the operating system where you’re running the mailserver.
2. Then, you’ll want to follow the instructions for running Certbot with the --standalone flag with your mailserver's hostname as the domain flag.
   
   

   sudo certbot certonly --standalone -d <mail.example.com>

   [If you are running a webserver on the same machine, you’ll need to use our webroot plugin instead of the `standalone` flag!]

3. Make sure to also follow through the Automating renewal section, and set up a regular cronjob, systemd timer, or equivalent on your system to run certbot renew regularly.

A note about port 80

If you've got a firewall blocking port 80 on your machine, you'll have to punch a port-80-shaped hole for the duration of Certbot's challenge. You can do this by adding the following to /etc/letsencrypt/cli.ini:

pre-hook = <allow port 80 traffic through firewall>
post-hook = <disallow port 80 traffic through firewall>

There's more information about these renewal hooks in Certbot's documentation.

Installing the certificate

Once you’re done, your certificate and associated private key will be stored at:

/etc/letsencrypt/live/<HOSTNAME>/fullchain.pem
/etc/letsencrypt/live/<HOSTNAME>/privkey.pem

Where <HOSTNAME> is the hostname for your mailserver; for instance, mail.example.com.

Point your mailserver configuration files at these filepaths. You should be able to read up on your particular mailserver’s guide for setting up TLS; we’ve included some examples for popular email software below.

If you have trouble at this step, or your documentation isn’t clear, ask for help! Some folks at the Let’s Encrypt Community Forums may be able to help you install your shiny new certificate.

Congratulations! That’s it. You now have your very own certificate.

Guides for particular mailserver software

The most recent release of Certbot (v0.29.1) provides some features that make it easier to use with some mailserver software, including Exim and Sendmail. In particular, you can set the group owner and group mode on the private key, which should be preserved on each renewal.

Postfix

Run the following commands:

sudo postconf -e smtpd_tls_cert_file=/etc/letsencrypt/live/<HOSTNAME>/fullchain.pem
sudo postconf -e smtpd_tls_key_file=/etc/letsencrypt/live/<HOSTNAME>/privkey.pem

Your new certificates should roll over automatically in about a day; if you’d like this change to take place immediately, run sudo postfix reload to reload Postfix. Postfix's TLS guide has more detailed information as well.

Dovecot

Most Linux distributions throw Dovecot SSL configs into /etc/dovecot/conf.d/10-ssl.conf. Edit the file to point to your new certificates:

ssl_cert = </etc/letsencrypt/live/<HOSTNAME>/fullchain.pem
ssl_key = </etc/letsencrypt/live/<HOSTNAME>/privkey.pem

You can also follow Dovecot's guide on configuring TLS. Then, ask Dovecot to reload its configuration.

sudo doveadm reload

Sendmail (Certbot 0.29.1+)

Check where the TLS options are set on your system. For instance, on Debian distributions, this is /etc/mail/tls/starttls.m4 by default. Set the following variables to point to your new certs:

define(`confSERVER_CERT', `/etc/letsencrypt/live/<HOSTNAME>/fullchain.pem')dnl
define(`confSERVER_KEY', `/etc/letsencrypt/live/<HOSTNAME>/privkey.pem')dnl
define(`confCACERT', `/etc/letsencrypt/live/<HOSTNAME>/chain.pem')dnl
define(`confCACERT_PATH', `/etc/ssl')dnl

As of Certbot 0.29.1, the permissions should be set properly on your private key. If your Certbot version is earlier than this, you’ll have to put chmod 600 /etc/letsencrypt/live/<HOSTNAME>/privkey.pem in a hook.

Then re-compile your configs and restart sendmail:

make -C /etc/mail install && make -C /etc/mail restart

Exim (Certbot 0.29.1+)

Exim usually doesn’t run under root, but under a different user group. Set the permissions of the cert directory and key material, as well as the appropriate places in the `archive` directory.

HOSTNAME=<mail.example.com, for instance>
GROUPNAME=<Debian-exim, for instance>
DIRECTORIES=”/etc/letsencrypt/live /etc/letsencrypt/live/$HOSTNAME /etc/letsencrypt/archive /etc/letsencrypt/archive/$HOSTNAME”
chmod 640 /etc/letsencrypt/live/$HOSTNAME/privkey.pem
chmod 750 $DIRECTORIES
chgrp $GROUPNAME $DIRECTORIES /etc/letsencrypt/live/$HOSTNAME/privkey.pem

As of Certbot 0.29.1, the permissions you set on your private key material should be preserved between renewals. If your Certbot version is earlier than this, you’ll have to put the above in a hook or your renewal cronjob.

Then, set the following variables in your Exim configuration:

tls_certificate= /etc/letsencrypt/live/<mail.example.com>/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/<mail.example.com>/privkey.pem

And restart Exim.

A note about older versions of Certbot

Both Sendmail and Exim have permissions requirements for the private key file that you give them. Versions of Certbot older than 0.29 may not preserve your keys’ permissions settings, so you’ll have to perform the permissioning adjustments mentioned above in a post hook or in your renewal cronjob.