I've got a certificate for example.com with DNS _acme-challenge.example.com:
letsencrypt certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d example.com
Everything works well. I also see that I have an account registered in /etc/letsencrypt/acmedns.json which is read by /etc/letsencrypt/acme-dns-auth.py.
I want to create SEPARATE certificates for a big number of sub domain sub-[0-999].example.com. Those certificates need to be separate. I would like to avoid different accounts with different _acme-challenge.sub-[0-999].example.com.
Is there a way to use my existing account with _acme-challenge.example.com for the sub domain certificates? (_acme-challenge.sub-[0-999].example.com would point to the same thing as _acme-challenge.example.com).
It's kind of possible but not quite how it's designed to work. With acme-dns (which is a DNS challenge delegation via CNAME to a service dedicated to answering acme challenges) the idea is that each subdomain gets it's own "registration" with the acme-dns service (either one you host yourself or one hosted for you). That registration creates a record name in the acme-dns service to point your CNAME to and generates a username/password for talking to that API scoped to just that record.
Typically the registration details will be saved to a file, one for each domain/subdomain, so it's technically possible to reuse that by copying the file and renaming it however the acme-dns client expects to find it.
That way you could bulk create your _acme-challenge records all pointing to the same CNAME value. You would not however be able to order more than a couple of the certs at a time as the TXT record the CNAME points to will only hold the two latest values.
You'd have to try it as an experiment.
However the best/easiest thing to do is have your domain DNS hosted with a DNS provider that has a supported API, and just use automated DNS challenges that way and skip the whole acme-dns option. Your DNS provider does not have to be your domain registrar (which is the usual reason people are stuck on outdated DNS providers).
If you're using acme-dns, then you're using a CNAME on your Primary DNS to point to a Secondary DNS. acme-dns creates a unique domain and set of credentials for each domain.
On your Primary DNS system, the ACME Spec requires you to have unique records for each domain:
So the spec requires 1000 CNAMEs (or a system designed to dynamically respond).
You could potentially edit the acme-dns-auth.py script to force everything onto a single acme-dns subdomain and account. I would not do that, because it's likely to create issues with race conditions and troubleshooting down the line. Having isolated credentials is also a security best practice.
If you really want to do this though, changing line 141 should probably work (preview may or may not render correctly here):
Your question suggests to me that you may be looking for ways to better onboard and configure 1000 domains onto acme-dns.
If that is the case, i do have some suggestions:
1- Pre-generate 1000 acme-dns accounts, use a script to set up the dns records and populate the acmedns.json file
2- The acme-dns default subdomain is a UUID but the data store is sqlite3. after generating the accounts, you can just replace the UUIDs with your own domain name. I will often create a template for converting a FQDN into a predictable acme-challege domain, so I can set up the primary dns in advance. Then I just run this script to concert UUID based acme-dns credentials into 'human readable domain' credentials.
I typically have primary DNS on cloudflare and use acme-dns for DNS-01 challenges. With a small amount of scripting, you can onboard hundreds of domains onto those two systems quickly and easily.
@gregoire can you share more about the scenario you are trying to implement? Why are you using DNS challenges over HTTP, and why are you using acmedns instead of updating DNS from your acme client etc (there are many possible reasons, just curious what your reasons are).