I'm not helping things by conflating acme-dns with acme-dns-client.
The problem is I read the basics and then kept reading more threads trying to find a solution to my specific problem without fully understanding the basics and got turned around. But yes, going back to read the basic is needed.
It's been a few days, but I did read that thread, it was helpful. But I clearly I got turned around at some point and I'm due for another read. Still had a few missing pieces that I didn't quite grok.
I am trying to understand what your end goal is.
I think what you are trying to do is run an internal network with LetsEncrypt certificates?
If that is the case, you want to deploy a split horizon DNS system.
Your internal systems can all use the BIND server to route requests. You can handle that by configuring machines to prefer your BIND server, or route traffic on the firewall to your BIND server.
External systems, however, will look to the public DNS servers (i.e. the Dreamhost config). If using acme-dns, the public DNS servers will CNAME onto your public acme-dns setup.
So what should be happening here is as follows:
Bind has nothing to do with this. Your internal LAN configuration and DNS has nothing to do with this.
You're basically going to use Dreamhost to setup the acme-dns namespace, and cname any domains you need certificates for onto acme-dns. If you have other Fully Qualified Domain Names (FQDNs), they need to have public DNS records on their nameservers that CNAME onto the acme-dns server as well.
Your internal private systems/lan can have completely different DNS that is entirely unrelated to the public internet. This is very common.
The entire ACME protocol happens on the public internet, and the DNS-01 challenge requires the public nameservers to either have the challenge value or point to a public DNS server that has the challenge value. All of this can - and should - happen independently of your internal BIND configuration.
You have an "internal" DNS and are somehow thinking it needs to he be source of the TXT record that needs to be accessible from the Internet.
Well, that kinda defeats the point of making it "internal" (only) [with zero external access to it].
The TXT records are one-time use only, they are never considered private information, and should NOT be handled by any "super secure / internal only" DNS systems.
They should be placed directly on a public DNS system OR delegated from such to a dedicated [and also] publicly accessible DNS server/system [i.e. acme-dns] for that sole purpose.
Yes, internal network with LetsEncrypt Certificates with external hosts having no access to the network.
So can't you just change your nameservers at the registrar to a DNS provider that supports an API? Ideally one supported by Certbot. Although other ACME clients provide support for many more DNS providers (acme.sh and lego both support Dreamhost "out of the box")
Seems you got onto acme-dns because of an early misunderstanding. So, worth evaluating solutions back from the start.
No yeah, I totally can. Dreamhost even has a few articles on using Cloudfare specifically. Not expecting that to be an issue. And I agree with your earlier post, removing acme-dns from the equation, at least at this time. Is probably for the best.
I highly recommend against this. Most Registrar provided DNS systems do not have fine-grained permissions. I am fairly certain Dreamhost does not. This often means the API creds to manage the DNS can also be used to transfer the domain to another entity.
Which is why I suggested changing them to Cloudflare.
I am not familiar enough with Dreamhost but yes if their API security is poor they wouldn't be a good choice.
If you have a spare domain laying about, you could use it just for DNS-01 challenges using CNAMEs. That would provide some additional security against API misuse on records that dont need to be updated for certificate issuance.
As I understand it, there is no public access to their local network. So, any public DNS provider is only handling the TXT records. I don't see much exposure for abuse in that case but your CNAME idea is fair too.
The security is not poor, but it has the standard design flaws that all āmulti functionalā companies have when it comes to Certbot integration - it is not an exclusive DNS Settings API, but an account based API offering much control over numerous account functions.
For the new people here, while these types of APIs are perfect and necessary for writing tools to manage an account and services ā when dealing with Certbot integration it means you must stash your account credentials on a machine connected to the public internet. If that machine is compromised, your entire account is compromised.
AFAIK, the only company that offers hosting/registration and and an API that can be somewhat locked down is Namecheap. IIRC, on their platform you must create a second account, ask their customer service to enable that account for api access, then delegate DNS control for each domain in your first account to the second account. Certbot is then configured to use the second account with only the delegated dns control, instead of the first account with full control.
I like DreamHost. It was started in a dorm room at a college next to mine. Iāve known the founders, some friends were early employees. I use them for some web hosting and mail.
Imho, the Certbot use-case and requirements for dns-01 are unfortunately not compatible with what most host/registrar/dns APIs were created for, or the bulk of their current functionality. These APIs were all designed for building tools that fully manage accounts and services - no one expects, or should expect, users to stash these api credentials onto publicly connected machines for third-party scripts to manage frequent dns changes via cronjobs. The certbot use case is an outlier (and IMHO an abuse of these APIs), which is why acme-dns was invented.
End rant.
Whoops one more thingā¦
A backup plan that works is to have the credentials and certbot installed on your machine, or another desktop/laptop, and manually run certbot from that machine. I often use that pattern, with the credentials stored on an encrypted volume or encrypted in a blackbox managed file structure, and decrypt on demand when I need to renew. This gets around many security concerns I have,
In this case it looks like they would only use the public DNS provider to resolve the DNS Challenge TXT records. There are no other records or services to be compromised.
Even if the credentials are lost what is the exposure?
Sure, for someone using the public DNS for other types of records losing control of your DNS could be harmful.
This case is more like they are using the public DNS provider as an acme-dns substitute used for one and only one narrow purpose.
It looks like they have disabled most of the API commands that would have been problematic. I donāt know if this is permanent or not.
In the past, the API keys allowed you to transfer domains - so a compromise could result in losing control of the domain to a malicious actor.
Anyone using DreamHost as a registrar likely uses them for other services though - their domain pricing is not good. All domains and services on the account would be at risk, including databases and hosted websites.
No evidence of those other services used here yet but fair to ask.
Besides, the main suggestion was to use something like Cloudflare anyway which gives a layer of separation even if they were.
For what it's worth, AWS allows for pretty fine-grained DNS credentials, and Azure has custom roles with limited DNS permissions too. The big "cloud" providers are getting to be pretty good at allowing everything to be API-driven with fine-grained permissioning. I don't know as I'd move from a more straightforward hosting provider to something that complex just for handling this use case, though.
Your organisation probably already has a cloud vendor like Azure, AWS or Google, if so setup the public ecfinternal.net domain on one of their DNS hosting (they all have fine grained permissions), optionally keep your private ecfinteral.net internal and have internal clients use the internal zone for lookups etc.
Then acquire restricted credentials that can just do the minimum for the public zone, and use the corresponding DNS API plugin to get your certificate.
acme-dns is fine, but you'll need to register per domain/host identifier, so it's a bit more work to use and you have to host/maintain it on the public internet.
There are a few other ways to do it, but simply using public DNS with an API supported provider is the easiest (when you can't use HTTP validation).
Can't you host acme-dns somewhere where it's publicly accessible?
Yes, we are using Dreamhost for other services. Not for this domain in particular. Price wasn't actually bad, but the bigger benefit was to not have domains registered across various different registrars. But yes, as discussed with MikeMcQ using Cloudfare seems like a good idea and is totally ok with me.
Hey and look at that, Certbot with the Cloudflare plugin is working just fine. I'm able to generate certificates for any subdomain I want. Still a good bit of work to do, but this is very nice start. Thank you everyone for all your help and pointers.