Hi there community,
I want to have two instances of caddy running with the same Redis storage plugin and configuration.
But I want one instance to take care of keeping the certificates up to date in Redis and the other one should just load and use those certificates without having the configuration to renew or obtain them.
Then I set “automatic_https” disable true certificates don’t get even loaded even if their there.
Thanks in advance!
Hey Michael,
Why? This seems like an odd requirement.
Thanks for your reply!
I am sure this sounds a bit odd but let me try to explain my usecase a bit better.
I would like to have one server that is responsible for all the certificates I need and has all the credentials needed for the DNS challenges. The caddy instance on that won’t be even exposed to the outside of my network.
Then I would like to have different instances of caddy on different server which all read and load a subset of certificates from that distributed storage (redis) and just use it. These are also exposed to the outside and get traffic. This way the instances on the exposed servers don’t have any credentials needed for the DNS part.
It might still sound like a uncommon usecase but I feel like it would make sense in our usecase.
This should just work out of the box without any extra configuration. If one instance initiates the ACME challenge via making a request to Let’s Encrypt, the other can solve it by reading from storage.
But since it seems like you want to use the DNS challenge, this might be trickier. I think if you just start the one that manages the certs first, you should be okay. The other one may emit errors when attempting to renew them, but your instance with the DNS credentials should be able to renew them.
Running Caddy instances in a cluster with different configurations is definitely something I’d classify as untreated territory, so your mileage may vary.
That is unusual, indeed. I’d be inclined to try what Francis suggested: just set up all your Caddy instances to use the same storage, but only give one the DNS credentials – Caddy’s probably smarter than you think: the instances without DNS creds should err, but before Caddy tries to renew a cert it always checks in storage first to see if it was renewed in the meantime; if so it will use the new certificate. So it might work?
@matt a related idea I wanted to toss out there - we have the tls <cert> <key> syntax to specify a specific pair, but this only works for filesystem storage. Maybe we could have a tls from_storage preset that would just use whatever matches in the configured storage without trying to issue/renew the certs? Is that a dumb idea?
Not dumb, but I think it’s more akin to a “read-only” management mode… I dunno, will give it some thought though!
Thanks @francislavoie and @matt for your answers. I got it working as you described with all same storage but different configs. The issue I ran into was that the instances without the dns config just tried http challenge and failed because things were not yet setup.
So basically what I think I am asking for is a read only mode for https with the strategy to always try to load until there is a valid cert to load. I know that it doesn’t quite the idea that Caddy tries to promote, but I think it could be a valid thing in such setup with shared storage and basically a “master” Caddy.
To clarify, I am suggesting that you enable the DNS challenge on all instances, but only with credentials on one of them. Then it won’t try the http challenge.
This topic was automatically closed after 30 days. New replies are no longer allowed.