Difficult situation: Attempting to do embedded systems and was hoping the DNS-01 challenge would work. We are not in control of all the sites and their choice of DNS providers, so it will not be reliable to attempt this type of integration. Unfortunate. I’m assuming dynamic txt records are critical to the security model of it all and there is no facility for “manually” managing the post of the value…
I split your comment out into a new topic.
Could you please fill out the help topic template to give us more detail of what you’re running into?
Thanks for all your team’s innovation, this is more a discussion thread I think rather than issue that can be resolved.
Pardon the ignorance on our part regarding planning on the level of integration for DNS-01 type challenge across N locations. After doing a few more hours reading today; I do not think this will be something that can be resolved within Caddy’s implementation.
I found an interesting hack but the complexity is way to much to ask our disparate sites & domains to apply:
The only thing I can think of would be to have caddy somehow present a console prompt, log element, or some kind of management page to allow an admin to manually take the challenge presented by letsEncrypt and have the administrator update the DNS text record… which is completely opposite of what the intended integration is and as much overhead and requesting a CA cert.
Each location we are deploying into will have its own business rules on IT, DNS providers ,etc.
Reading further across all of the reference content on ACME, the Caddy server’s support. Its really dependant on the availability of DNS management API’s. It seems these are not being implemented consistently at DNS providers (our first two sites are google domains). There is no changing that, google domains has no API and has no visible plans for embracing it other than within its cloud services.
It looks like we’ll need to keep the code we already wrote (thankfully) for manually managing the private key and certificate that caddy uses and have customers install CA issued certificates until the zeroTLS/Letsencrypt ecosphere introduces a IOT/embedded systems friendly way of doing this.
I’m apprehensive on convincing users to import the ephemeral caddy root CA given the issues that come up when conflicting instances of the caddy local CA come up. The local CA should really generate UNIQUE cert subject DN strings to avoid CA collisions if you re-deploy caddy and it re-gen’s the CA. I will do more testing and validate what I’ve seen on Local CA collisions, and open an issue specific to that instead.
I would like to hear if anyone is doing internal network with any of the types of validation that has found creative work arounds too…
Ah, yeah what that acme-dns project is doing is called “challenge delegation”. Some people do this by using DuckDNS, a free dynamic DNS provider:
So my understanding is that you’re trying to do on-prem installations of your software at customers who may have locked down networks etc? You could make use of the DuckDNS plugin - have your customers set up a dummy DuckDNS domain, have them add a _acme-challenge.theirdomain.com CNAME record pointing to their DuckDNS domain, then everything should follow from that (see the duckdns plugin README).
Oh that is a great pointer, thank you very much. I’ll review this as a possible work around and comment as we progress.
1 Like
Ok one point I’m not getting reading through this is on the duck dns configuration side… Is the IP address being associated with our instance of the dynamic fqdn, like “example.duckdns.com” from the example, significant in any way? Or is the IP being referenced a throw away completely and can point off into whatever? (e.g. the public website IP of the domain in question that we are doing internal certs for)
So in our test, (the names are changed to protect the lab)
The internal “node” we want caddy TLS to protect is pi.int.example.com In this discussion, example.com being the domain that is managed through google domains.
I have gone into google domains and used the DNS Custom Resource Records configuration to set this entry
_acme-challenge.pi.int.example.com CNAME 10m examplepi.duckdns.org.
And I have the token for my configuration, but as I look at the duckdns.org web UI for the examplepi.duckdns.org entry, the initial IP it set was my home gateway IP address which is not the environment I’m working in. I feel this is a really dumb question, but going back and reading through things I’m not sure… Does that duckdns.org assigned IP address need to point to anything significant for the integration to work?
Nope, in this case the A record (IP address) of DuckDNS is insignificant. That’s DuckDNS’s usual usecase (being a dynamic DNS provider), but it just so happens to be useful in a different way for challenge delegation 
Just something to note - DuckDNS is limited in the sense that only one TXT record can be set at a time for the whole zone (i.e. your subdomain) so if you need to issue certificates for multiple Caddy instances at the same time for the same domain, you may run into some trouble. Hopefully that’s not the case.
1 Like
Thanks this worked! Yeah the IP is insignificant, thanks for confirming. Also- thanks for sharing the limitation, in our case its a single certificate deployment that we’re supporting so we are in luck! Thanks for your help!
1 Like
As luck would have it I have been notified we have a domain that will have dozens of deployments going in (good problem to have).
We’ll keep working on how to handle this. This approach provides a solid work around to get started, and once we show how simple the certificate management cycle becomes, IMHO we will be able to convince decision makers for a domain to split out and have a subdomain handled by a provider that can support API integration for automated TLS management. Especially after they go through a 1 year certificate cycle and have to scramble at renew time to get it replaced.
Sites that are already letsEncrypt/zeroTLS aware will have already aligned themselves with the appropriate DNS providers anyway…
I have such wonderful horror-show to share on large scale (100’s of nodes+) manual certificate management and renewal, let alone one continuously forgotten certificate over the years. This discussion has been a huge help. Thanks again.
1 Like
A longer-term solution might be to actually use GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely., i.e. have your company run your own instance, and give each of your customers access to register to it. Then you would just need a libdns + caddy-dns plugin which supports it (should be easy to implement with GitHub - cpu/goacmedns: Go library to handle acme-dns client communication and persistent account storage.).
I will grab a couple other team members and look at this possibility. Thanks for circling back on that joohoi one, when I read through it, it seemed to be a potentially viable solution as well, but I realized we just need to attach a go dev contractor to the project to finish a few “last mile” items like local user registration management UI template and plugin code over caddy_auth_portal, and potentially this now too and offer them up to the community…
Thanks again. I’ll work with folks from our team on a showcase posting once we get through our first couple of beta sites installs.
1 Like
I’d also like to point out that you could get a support plan for Caddy (a bit orthogonal to this discussion though): Caddy for Business
1 Like
Didn’t even know it existed… will check it out.
1 Like
This topic was automatically closed after 29 days. New replies are no longer allowed.