# How to issue certificates for Round Robin DNS setup?

**URL:** <https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858>\
**Category:** Help\
**Created:** [February 24, 2024, 5:29pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858 "2024-02-24T17:29:25Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![hyperknot](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/hyperknot/32/37907_2.png) [@hyperknot](https://community.letsencrypt.org/u/hyperknot)\
**Post date:** [February 24, 2024, 5:29pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/1 "2024-02-24T17:29:25Z")

</div>

Hi, I'd like to issue a certificate for a few servers in a Round Robin DNS setup. There is no load balancer involved, it's just direct, DNS level load balancing, with A records.

My understanding is that basically only the DNS challenge works, is that correct?

So I'd have a script running once per day, doing the DNS challenge and renewing the certificate if needed. The machine this script runs at doesn't even need any incoming connection if I understand correctly, it could even be a cloud function or a docker image on an unrelated host. Then I'd upload the cert + key into some private storage and the actual HTTP servers would download from this place once per day.

Is this kind of correct?

---

<div class="post-metadata">

**Author:** ![hyperknot](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/hyperknot/32/37907_2.png) [@hyperknot](https://community.letsencrypt.org/u/hyperknot)\
**Post date:** [February 24, 2024, 5:33pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/2 "2024-02-24T17:33:48Z")

</div>

As an alternative, I've read it here that Stateless mode might be an option:

> **[Stateless Mode](https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mode)**
>
> A pure Unix shell script implementing ACME client protocol - acmesh-official/acme.sh

How would it work in my case? Should I register the account anywhere, even on a dev machine, get this fingerprint and just deploy the servers with this fingerprint hard-coded? Does this never change?

Is there any downside of using fingerprints? I mean it seems so simple compared to anything else.

---

<div class="post-metadata">

**Author:** ![danb35](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/danb35/32/70869_2.png) [@danb35](https://community.letsencrypt.org/u/danb35)\
**Post date:** [February 24, 2024, 5:34pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/3 "2024-02-24T17:34:32Z")

</div>

> [@hyperknot](#):
>
> My understanding is that basically only the DNS challenge works, is that correct?

The DNS challenge may be the easiest way for you to do it. The other possibility would be if you could push the challenge token to all of the servers, so that no matter which one is (or "ones are") hit, it will respond with the right value. But with this method, whatever system is trying to obtain the cert would need to be able to create (and then remove) those challenge tokens from each of the servers in question.

Using DNS validation, what you describe should work.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [February 24, 2024, 5:35pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/4 "2024-02-24T17:35:49Z")

</div>

Just have one of the servers _also_ listen to the hostname `acme.example.com` where that hostname points to just a single server instead of doing round robin and have the other servers serve the challenge file on that `acme` host (e.g. using NFS if they're on a secured network or use `scp` or think of something clever 🙂). And on all the servers you'd redirect every request for `/.well-known/acme-challenge/` to `acme.example.com`.

Or even simpler: if a random server does a challenge, simply distribute that challenge over all servers.. That way one of the servers will always answer and do it correctly.

---

<div class="post-metadata">

**Author:** ![hyperknot](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/hyperknot/32/37907_2.png) [@hyperknot](https://community.letsencrypt.org/u/hyperknot)\
**Post date:** [February 24, 2024, 6:02pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/5 "2024-02-24T18:02:55Z")

</div>

Thanks, I'll go with the DNS solution. Do you know if is there any problem from having certs with different issue dates on the different servers? I mean this pushing to the servers can take some time, or might even fail so one server might have the old cert while the other already has the renewed one for some time. Is this a problem?

---

<div class="post-metadata">

**Author:** ![danb35](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/danb35/32/70869_2.png) [@danb35](https://community.letsencrypt.org/u/danb35)\
**Post date:** [February 24, 2024, 6:07pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/6 "2024-02-24T18:07:40Z")

</div>

> [@hyperknot](#):
>
> Do you know if is there any problem from having certs with different issue dates on the different servers?

I wouldn't expect so.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [March 25, 2024, 6:07pm UTC](https://community.letsencrypt.org/t/how-to-issue-certificates-for-round-robin-dns-setup/213858/7 "2024-03-25T18:07:55Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
