letsencrypt on mail server

Ispconfig 3.1 supports letsencrypt certificates for client websites out of the box, but using LE certificates for the control panel itself or other services (postfix, dovecot, xmpp, mysql) requires manual setup. This is a short how-to for setting up a letsencrypt certificate on an ispconfig mail server from a multiserver install, and assumes the mail server is already setup in ispconfig and things are running other than the certificates. Maybe some day all the manual pieces can be compiled into a full howto (or one per OS?).

First install letsencrypt. Refer to the ISPconfig 3.1 Perfect Server guide for your OS, but in general if your OS provides a package, install that (eg. `apt-get install certbot -t jessie-backports`), otherwise:

Code:

mkdir /opt/certbot
cd /opt/certbot
wget https://dl.eff.org/certbot-auto
chmod a+x ./certbot-auto
./certbot-auto    # (answer "no" to continue)

Next, adjust your firewall. The letsencrypt configuration on a web server (and control panel server) uses the existing apache/nginx web server to intercept requests, but as an email server won't have a web server installed, we'll use letsencrypt's standalone plugin for this. You have likely protected your server with a firewall, so you'll need to allow tcp port 443 requests to your mail server.

Now determine what hostnames you want to be included in the certificate. There is a limit to the number of names which can be included (100?), so don't plan on including all your customer domains if you have very many domains. We'll include the server's hostname (an CN), and include one "pretty" name (unfortunately it seems you cannot request the bare ip address to be included); a dedicated mail server will need to use --standalone:

Code:

certbot auth --text --agree-tos --standalone --email postmaster@`hostname -d` -d `hostname -f` -d mail.`hostname -f`

If you have a webserver running you will need to use --webroot:

Code:

certbot auth --text --agree-tos --webroot --webroot-path /usr/local/ispconfig/interface/acme/ --email postmaster@`hostname -d` -d `hostname -f` -d mail.`hostname -f`

You should see a Congratulations! message. If not, troubleshoot till you do.

Now we'll create symlinks for the certificate and key files in the places ispconfig configures by default, which are the same for postfix and dovecot:

Code:

# postconf smtpd_tls_cert_file smtpd_tls_key_file
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
# doveconf ssl_key ssl_cert
ssl_key = </etc/postfix/smtpd.key
ssl_cert = </etc/postfix/smtpd.cert

# ln -s /etc/letsencrypt/live/`hostname -f`/privkey.pem /etc/postfix/smtpd.key
# ln -s /etc/letsencrypt/live/`hostname -f`/fullchain.pem /etc/postfix/smtpd.cert
# ls -l /etc/postfix/smtpd.{key,cert}
lrwxrwxrwx 1 root root 55 Aug  9 15:34 /etc/postfix/smtpd.cert -> /etc/letsencrypt/live/hostname.domain.com/fullchain.pem
lrwxrwxrwx 1 root root 53 Aug  9 15:33 /etc/postfix/smtpd.key -> /etc/letsencrypt/live/hostname.domain.com/privkey.pem

# service postfix reload
# service dovecot reload

At this point both postfix and dovecot answer with the new certificate. The only remaining thing would be to make sure certificate renewals happen and restart postfix/dovecot if so. A quick read of ISPConfig's letsencrypt cronjob looks like it should perform the renewal; as an additional measure, if you installed from an OS package, you might have another cronjob keeping renewals current; eg. the cronjob from jessie-backports runs every 12 days.

Once the certificate has renewed, postfix and dovecot must restart. You could blindly do this once a week or use a cronjob like this to test the certificate served over the network against the latest letsencrypt files and restart if they differ; save as /usr/local/sbin/letsencrypt-for-mail.sh:

Code:

#!/bin/bash

# letsencrypt-for-mail.sh:  compares the ssl certficate served by dovecot
# and postfix with the current certificate issued by letsencrypt,
# and restart the mail system if they differ

# this can be run as a cronjob to propogate letsencrypt certificate changes
# to the running mail services

LE_DIR=/etc/letsencrypt/live/`hostname -f`
LE_CA=${LE_DIR}/chain.pem
LE_CERT=${LE_DIR}/cert.pem
LE_KEY=${LE_DIR}/privkey.pem

OPENSSL=`which openssl 2>/dev/null | head -1`

# Check if letsencrypt has been setup
if [ ! -f ${LE_CA} -o ! -f ${LE_CERT} -o ! -f ${LE_KEY} ]
then
    echo "Letsencrypt files not found.  You must setup letsencrypt and issue a certificate first." 1>&2
    exit 0
fi

# Check openssl binary exists
if [ ! -f ${OPENSSL} ]
then
    echo "Cannot find openssl. Exiting." 1>&2
    exit 1
fi

le_serial=`${OPENSSL} x509 -noout -serial -in ${LE_CERT}`
smtp_serial=`${OPENSSL} s_client -connect localhost:25 -starttls smtp </dev/null 2>/dev/null | ${OPENSSL} x509 -serial -noout`
pop3_serial=`${OPENSSL} s_client -connect localhost:110 -starttls pop3 </dev/null 2>/dev/null | ${OPENSSL} x509 -serial -noout`
imap_serial=`${OPENSSL} s_client -connect localhost:143 -starttls imap </dev/null 2>/dev/null | ${OPENSSL} x509 -serial -noout`
imaps_serial=`${OPENSSL} s_client -connect localhost:993 </dev/null 2>/dev/null | ${OPENSSL} x509 -serial -noout`
pop3s_serial=`${OPENSSL} s_client -connect localhost:995 </dev/null 2>/dev/null | ${OPENSSL} x509 -serial -noout`

# if a service is down, this certificate verification will fail;
# we'll only restart services if they are actually running

function restart_postfix_if_running() {
    /etc/init.d/postfix status 2>/dev/null >/dev/null
    if [ $? -eq 0 ]
    then
        /etc/init.d/postfix restart >/dev/null
    fi
}

function restart_dovecot_if_running() {
    /etc/init.d/dovecot status 2>/dev/null >/dev/null
    if [ $? -eq 0 ]
    then
        /etc/init.d/dovecot restart >/dev/null
    fi
}

if [ "${le_serial}" != "${smtp_serial}" ]
then
    restart_postfix_if_running
fi
if [ "${le_serial}" != "${pop3_serial}" -o "${le_serial}" != "${imap_serial}" -o "${le_serial}" != "${imaps_serial}" -o "${le_serial}" != "${pop3s_serial}" ]
then
    restart_dovecot_if_running
fi
exit 0

Make that script executable and set a cronjob to run it:

Code:

# cat <<EOF >>/etc/cron.d/letsencrypt-restarts
15 3 * * *  root  /usr/local/sbin/letsencrypt-for-mail.sh
EOF

# chmod +x /usr/local/sbin/letsencrypt-for-mail.sh

 

I'd guess 3.2, but too early to say, and the rfe (https://git.ispconfig.org/ispconfig/ispconfig3/issues/3987) is not tagged with a milestone. It's not a tremendous amount of work to get it integrated, but there are still some bugs being found/fixed in 3.1 and of course everyone is anxious for a stable release, so unless it catches a developer's fancy to implement it right away, I'd expect it more in the 3.2 timeframe. It's not difficult to setup manually (if it were part of a Perfect Server guide, you'd never know the difference...), and after 3.1 ispconfig is going to target a stable release every 6 months, so seems reasonable to wait, as it'll get there pretty soon either way.

 

No, as postfix does not support SNI, you cannot have multiple certificates. What you can do that might fit your needs is request a single certificates and add additional names to it. That would work if the number of names you want to add isn't too large (the limit is maybe 100, from memory?) and if you don't need to change it too frequently and hence hit the limits for requesting certificates.

 

Both/either. All the names you provide must resolve in DNS to your server's ip address so letsencrypt can authorize them. The example above shows this being done with:

Code:

-d `hostname -f` -d mail.`hostname -f`

You just add more "-d domain" names to the request.

 

Yes, just make sure both Aname.com and Bname.com are setup in DNS to resolve to that same ip.

 

Yes, that should work to get other names added into the certificate.

 

What packages did you install? It should be 'certbot' and 'python-certbot-apache' I believe, plus their dependencies. But even just the 'certbot' package should give you /usr/bin/certbot: http://packages.ubuntu.com/yakkety/all/certbot/filelist

(note I don't have a ubuntu 16 server to reference, I'm just searching)

 

Yes, I'm now on my third renewal (May, July, September). One thought on that is it might not hurt to disable debian's certbot cronjob (/etc/cron.d/certbot), as the ispconfig renewal is smarter - if any certificates are renewed, it will also reload (restart?) the web server. Likely your web server will get restarted within a month's time anyways, but on systems that don't change config much, there's a chance the debian cronjob would renew the certificate, and the webserver would never reload and you'd get expired certificate errors after a month or so.