Here’s how to automatically setup SSL Certificates for HAProxy using certbot and Let’s Encrypt, without having to restart HAProxy.
This article assumes that you have certbot already installed and HAProxy already running.
As we are using HAProxy, we can’t just run
sudo certbot --haproxy like for nginx because certbot doesn’t officially support HAProxy, yet. Instead we have to use the
certonly command and the
--standalone option to run a standalone webserver.
We also want to include the certbot command in a script later on, so we need to supply all further options via the command line. The basic certbot command we will use, looks like this:
certbot certonly --standalone --agree-tos --non-interactive \ -m firstname.lastname@example.org -d domain
If you try to run the command on the machine where HAProxy is running, it will tell you that port 80 is already in use, because that’s the port HAProxy is listening on. To circumvent that, we will have to tell the standalone server to use another port:
certbot certonly --standalone --agree-tos --non-interactive \ -m email@example.com -d domain --preferred-challenges http \ --http-01-port 9785
We will also have to tell certbot to keep the certificate until it expires and that it should be renewed when we add new domains to it:
certbot certonly --standalone --agree-tos --non-interactive \ -m firstname.lastname@example.org -d domain --preferred-challenges http \ --http-01-port 9785 --renew-with-new-domains \ --keep-until-expiring
With the certbot part out of the way, we can continue with the HAProxy configuration.
For HAProxy, we begin with setting up a minimal SSL configuration for our example frontend:
frontend www-https bind *:443 ssl crt /etc/haproxy/ssl-certs/cert.pem reqadd X-Forwarded-Proto:\ https
We will also tell HAProxy to direct all requests to the standalone webserver to the correct port of the standalone webserver.
Our frontend is now done and looks like this:
frontend www-https bind *:443 ssl crt /etc/haproxy/ssl-certs/cert.pem reqadd X-Forwarded-Proto:\ https # Let the letsencrypt backend handle requests to the # acme-challenge url acl letsencrypt-req path_beg /.well-known/acme-challenge/ use_backend letsencrypt if letsencrypt-req # ... etc.
The letsencrypt backend sets the server to the local certbot standalone server:
backend letsencrypt server letsencrypt 127.0.0.1:9785
Be sure to validate the config with
haproxy -c -f /path/to/your/haproxy.cfg to check for mistakes.
Now we can reload the HAProxy config and try to run the certbot command from above again. It should work, but we aren’t done yet.
Putting it all together
The next step is to create a script that will execute the certbot command and copy the generated certificate to the directory where HAProxy is looking for it.
The script will be called
cert_renew and it will take a list of domains as an argument.
#!/bin/bash # This script takes a list of domains as arguments # and will setup a single certificate for all of them. cert_name="generic_cert" haproxy_cert_dir="/etc/haproxy/ssl-certs" email="email@example.com" domains="" for domain in "$@" do domains+="-d $domain " done certbot certonly --standalone --agree-tos --non-interactive \ -m $email --preferred-challenges http \ --http-01-port 9785 --cert-name $cert_name \ --renew-with-new-domains --keep-until-expiring $domains mkdir -p $haproxy_cert_dir # Combine the certificate chain and private key and put it # into the correct HAProxy directory cd /etc/letsencrypt/live/$cert_name cat fullchain.pem privkey.pem > "$haproxy_cert_dir/cert.pem" echo "Reloading haproxy" sudo systemctl reload haproxy
Using it like
cert_renew domain1.org domain2.net will setup one certificate for both domains at
/etc/haproxy/ssl-certs/cert.pem and reload HAProxy.
Setting up the Cronjob
Next, we will save the script at
/usr/local/bin/cert_renew and setup the cronjob, so that it runs twice per day:
5 7,17 * * * root /bin/bash -c '/usr/local/bin/cert_renew domain1.io 2>&1 | /usr/bin/logger -t certbot'
With that done, we only have to change the cronjob entry when we add new domains and never have to worry about expiring certificates again.
This post builds on a few other blog posts which have been really helpful. These are:
- This great post by Lee Hutchinson
- Scott Helme’s post and the comments below
- This post by Skarlso, too
Top comments (0)