9:08 p.m.
On Tue, 2020-08-25 at 16:22 +0200, Damiano Venturin wrote:
This is a question I have in my mind since months.
I see that the nginx role allows a vm to become an acme server and catch
all the certificates generated by letsencrypt.
Just to clarify: the nginx host is not an 'acme server'. That would be the
Let's Encrypt Certificate Authority which is powered by the Boulder software.
The nginx host is an ACME client that can obtain signed TLS certificates.
These certificates can then be used by various services on that host.
I never tried this solution because my I'm concerned on how I can
distribute the certificates to other vms which are not involved with the
letsencrypt process.
What's the best practice for automatically distributing them?
You can do what I do: if I need a Let's Encrypt certificate on a host, I first
run debops.nginx against the host so that it can perform ACME challenges. Then
I run debops.pki to obtain the certificate. Sure, I may not need the nginx
service for anything else, but it's not a nuisance either.
I run a few services that share DNS names across hosts. One example is
www.imrejonk.nl. If you query that domain, you will get two address records
back. These address records belong to two different hosts. Yet my website has
a valid Let's Encrypt certificate. My trick for this is setting
nginx_acme_domain on host A to point to host B, and vice versa for the other
host. The result is that nginx on host A redirects the ACME challenge request
from Boulder to host B in case the challenge can't be found on host A, and
vice versa for the other host. So no matter which of the two hosts Boulder
connects to, it will either get the challenge back immediately or be
redirected to the correct host (which is perfectly valid for the ACME
protocol).
If you want to see this in action, try this:
`curl -I
http://hydrant.imre.amsw.nl/.well-known/acme-challenge/some-nonexistent-c...
Which will redirect you to unicycle.imre.amsw.nl, and this:
`curl -I
http://unicycle.imre.amsw.nl/.well-known/acme-challenge/some-nonexistent-...
Which will redirect you to hydrant.imre.amsw.nl.
You'll notice that the redirect=yes parameter is present in the redirect URL.
This is configured by the nginx role in order to prevent endless loops. This
does not hamper the ACME validation. This works for two hosts, but will need
some modifications when you want to use three or more hosts. More hosts also
means a more careful redirection scheme. I imagine that the ACME protocol or
Boulder limits the maximum number of redirects as well, so this should not be
used with a large number of hosts. In that case it's probably best to use a
proper load balancer instead.
https://webmail.ciphermail.com/ has three backend servers and two load
balancers. The load balancers are managed with debops.nginx, and their Let's
Encrypt certificates are obtained with the very same trick I just described.
Imre