Using Let's Encrypt for redirect domains on a load balanced site – A collaborative effort between Dev & Ops

What we were trying to do

A few months ago we were required to move the hosting for one of our major client’s products. We were required to migrate the website from being hosted from one of our on-premise web servers to being hosted on two newly provisioned cloud web servers. Hosting the website from two servers also meant that we could load balance the site. The site already supported 9 domains and it supported both HTTP and HTTPS for each of the domains. We also wanted to use Let's Encrypt to generate SSL certificates for 8 of those 9 domains and we only wanted to purchase a certificate for one domain (the main domain).

Why didn't we just ask our client to purchase 9 certificates?

  • Our client would have had to purchase the certificates – Certificates are very affordable, but still.
  • Renewals and time expended to renew them.
  • Problems introduced if our client decided to purchase more domains – More certificates would need to be purchased and more time expended to renew them. The renewals would most likely occur at different times to that of the original 9 certificates.

What is Let's Encrypt?

A certificate authority that is open-sourced, produces certificates free of charge and automates the renewals. Pretty amazing.

What problems did we encounter with Let's Encrypt's Domain Validation?

Let's Encrypt does not play well with load balanced sites. Before we can generate certificates, Let's Encrypt kicks off a process known as Domain Validation. This is where our Let's Encrypt Agent tries to prove to Let's Encrypt's CA (Certificate Authority) that we own the domain. This can be done using one of two methods...

  • We can add a special entry to the DNS, which was not an option as we do not manage our client's DNS.
  • The CA sends a cryptographic nonce to our Agent to sign before sending it back to the CA. Again this was not an option, because when the CA sends us the nonce and load balancing does not guarantee that the server containing the Agent will be hit.

What did we do about it?

  • We setup the site to support only one domain (the main domain).
  • We setup a redirect site, which supported the other 8 domains (redirect domains).
  • The redirect site was not load balanced, meaning that we could use Let's Encrypt to generate the certificates for the 8 redirect domains.
  • Hosting arranged for the Let's Encrypt certificates to be copied to a second server as a failover.
  • We purchased one standard certificate (i.e. not using Let’s Encrypt), which was for the main domain.

alt

Something to bear in mind is that Let's Encrypt does have a guide on how to handle load balanced sites, with extra servers. We decided that this approach was unnecessary given our circumstances with the workaround implemented hosting on two web servers.

Let's Encrypt documentation - https://letsencrypt.org/docs/