On 8/25/20 4:53 PM, Sergiusz Pawlowicz wrote: so basically you simply sync /etc/pki/realm/domain to the destination vm ? that's it?

On 8/25/20 5:06 PM, Sergiusz Pawlowicz wrote: I think it's a good idea also because it relies on ssh and avoids any latency (and cron job). Did you automate this in a role?

On Tue, 2020-08-25 at 16:22 +0200, Damiano Venturin wrote: 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. 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