1. Caddy version (
2. How I run Caddy:
Would run on Ubuntu servers via
a. System environment:
systemd, Ubuntu 20.04.
No command setup yet
c. Service/unit/compose file:
No config yet
d. My complete Caddyfile or JSON config:
No config yet
3. The problem I’m having:
I’m not having a specific problem but am more trying to see if something is possible. I’m looking at rolling Caddy out to replace Nginx servers and a custom Let’s Encrypt wildcard setup where a control server manages the certificate then pushes it out to other servers. I use DNS proof for the wildcard certificate via Cloudflare.
I’d like to replace this setup with Caddy (still using a wildcard cert!) and am looking at using Consul or Redis to store the certificates. I’m open to other solutions as well if that matters, but cannot use shared FS. I’m aware that Caddy is cluster aware in this situation so will only renew the certificate once which is great.
What I’m wondering is if its possible to decrease my exposure footprint and only give Cloudflare credentials to a single Caddy instance and force it to manage the renewal of the certificate whilst still letting the others in the “fleet” use and access the certificate. My use case is I don’t trust some of the servers as much and would really prefer not to have to distribute DNS API keys to every server that runs Caddy.
Basically; have one server renew and manage, the others just use to the serve traffic. Does that make sense?
4. Error messages and/or full log output:
5. What I already tried:
6. Links to relevant resources:
Hm, yeah, interesting request.
There might be some clever config setting/combination that disables an instance from obtaining/renewing certs and still uses existing ones from the automation storage, but I’m not sure what it would be off-hand.
One thing you could try is simply not setting the Cloudflare credentials and let the instances fail. Although I’m not sure if that would relinquish the lock on the name and let other instances try, or hold it and prevent the instance with credentials from trying… hmm.
Anyway I suppose we could look into this as a feature. Want to open an issue on GitHub?
PS. If you don’t trust those servers then why are you letting them use your private keys? I am not sure that your worry over DNS credentials is nearly as concerning as other aspects of this premise… and so it’s less compelling to implement this feature.
Yep, will do!
I trust the servers, its just limiting exposure I guess? Losing a private key is bad, obviously. But without DNS control its a step harder to do anything with it. Theres also the limitation in the current DNS plugin that write access must be given to all zones under the Cloudflare account. This means putting the API key everywhere goes from exposing configured certs to exposing all domains in the Cloudflare account.
This topic was automatically closed after 30 days. New replies are no longer allowed.