We are very proud to host the first Swiss mirror of the Chinese deepin Linux distribution!

At ENIDAN, we have chosen to have a central server for managing Let’s Encrypt (LE) certificates.  This is a just a simple summary of our setup, perhaps somebody might be inspired.

To be honest, there is not much information here you will not find on the LE websites or elsewhere. I have not added much, no black magic or clever code. I’m only describing our Let’s Encrypt setup with a single central server.

Overall reasoning

There are plenty of alternative plugins available, but the basic LE setup appears to be focused on an environment where it will be run on the webserver where the certificates are needed.

When I started contemplating using LE, it wasn’t really appealing to me to have the LE scripts and directory structures installed in multiple locations; instead, I wanted to have a central location, a core server, for dealing with managing (e.g. issuing and renewing) LE certificates. Also, certificates are not used only by webservers, but also for TLS in email-exchange, signing emails, VPNs and probably a few other applications I haven’t thought of. I wanted to avoid installing webservers in all of those locations.

Core server

In our case, the core server is just a xen guest running apache. It could just as easily be a container (LXC, Docker etc.), but we already had a central server with apache running (doing other stuff). I added a virtual host, hostname = “core123.example.com”, whose sole purpose is to respond to the domain validation challenges from LE, i.e. serve the keys stored in .well-known/acme-challenge.

Webservers

Our webservers that need certificates are configured to proxy the domain-validation challenge to the core server:

ProxyPass /.well-known/acme-challenge/ http://core123.example.com/.well-known/acme-challenge/

You can obviously do this with URL rewriting too, but ProxyPass is really enough unless you need to add conditions.

Mail and other servers

Other servers with no webservice listening on port 80 are also “proxied” to the core server, just slightly differently:

iptables -A PREROUTING -t nat -p tcp --dport http --j DNAT --to core123.example.com

An example server might be mail.example.com. We do not add this as a hostname to the Apache config on the core server, we just let it use the default vhost.

Getting a new certificate

To acquire a new certiticate, on “core123.example.com” run this:

certbot-auto certonly --webroot -w /srv/www/vhosts/core/htdocs/ -d mail.example.com

The certificates are left in /etc/letsencrypt/live/mail.example.com/. For the time being, we copy them manually to their destinations.

Certificate renewal

Certificate renewal is run via cron twice daily (as per LE recommendation , see section “Automating renewal”), on the core server. Using “–renew-hook”, we call a script that currently only notifies us when a certificate has been renewed – we then manually update the server with the new certificates. We intend to update this to automatically copy new/renewed certificates to their destinations.

Summary

To sum up, with two very simple means (iptables DNAT and Apache Proxying) we have managed to keep the LE management on a single server and still cater to both webservers and non-webservers. The distribution of certificates still needs some work, but nothing major.