DNS Load Balancing Multiple Certs?

[hanskohls]

I have a service using DNS Round Robin load balancing with two (and in future more) A records like this:

A x.domain.com -> [ip address 1]
A x.domain.com -> [ip address 2]
...
A x.domain.com -> [ip address N]

The service is both trivial and not critical (it’s an analytics pixel) so this is not in a failover mode so all A records are constantly live.

Can I configure all these servers to individually generate certificates via certbot?

If not I’ll have to ensure the certificates are stored and mounted on a network drive which I try to avoid.

[Osiris]

@hanskohls

Can I configure all these servers to individually generate certificates via certbot?

There are rate limits in place, so if there are too many servers, you might run into those rate limits. I would advice against is, especially because DNS round robin won't work flawlessly: if server A requests a cert, Let's Encrypt might try to verify the challenge at server B or C or D and the validation would fail.
A way to counter this is all servers to redirect requests for /.well-known/acme-challenge/ to a specific hostname (for example acme-verification.example.com) with just one IP address: that server would verify and receive all ACME validation requests. It would also be the only server which will request and get certificates.

That would mean the certs would have to be distributed somehow indeed, but that's a requirement due to the round robin DNS setup anyway. That would be scriptable though, but should be done securily for the private key.

[_az]

You can also try use stateless HTTP validation like this: https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mode . Just make sure the same ACME account key is predistributed to each server, and it’s pretty straightforward. This way, it does not matter which server responds to the challenge request.

DNS validation is a solid option as well, if you have the ability to automate the DNS updates available.

[sigprof]

If all your servers attempt to obtain a certificate for the exact same FQDN (x.domain.com), these requests will run into the Duplicate Certificate rate limit (5 per week).

A way around that limit is to give every server an unique FQDN (e.g., serverN.domain.com), and make each server obtain a certificate with both the common FQDN (x.domain.com) and the name which is unique to a particular server (serverN.domain.com). If you do this, certificates for different servers would not be considered as duplicates; however, at the first issuance they will be subject to the Certificates per Registered Domain rate limit (50 per week). Once these certificates have been issued for the first time, however, subsequent renewals will not count against the Certificates per Registered Domain limit.

Obviously, each server must be able to validate its unique FQDN in addition to the common FQDN, but validating the server-specific FQDN may be much simpler (e.g., http-01 validation would need just a single A record in DNS pointing to that server). Some solutions for validating the common FQDN were already given in other answers.