devcert-cli VS acme-dns

> That looks like a viable solution since it requires a one-time setup on the main domain and ongoing access to the second (validation) domain.

At my last job we deployed a special sub-domain for that purpose: dnsauth.example.com

We deployed a single (no-HA) externally exposed BIND server with a bunch of scripts that folks could connect to (we had deploy script to users/developrs). Nowadays there even purpose-build DNS servers for this purpose:

* https://github.com/acme-dns/acme-dns

I am pretty sure the main purpose is for people who use a DNS provider that does not have integrated support with certbot or cert-manager (basically this is a hosted acme dns (https://github.com/joohoi/acme-dns)

I used the acme-dns server (https://github.com/joohoi/acme-dns) for this. It's basically a mini DNS server with a very basic API backed with sqlite. All of my acme.sh instances talk to it to publish TXT records, and accepts queries from the internet for those TXT records.

There's a NS record so *.acme-dns.example.com delegates requests to it, so each of my hosts that need a cert have a public CNAME like _acme-challenge.www.example.com CNAME asdfasf.acme-dns.example.com which points back to the acme-dns server.

When setting up a new hostname/certificate, a REST request is sent to acme-dns to register a new username/password/subdomain which is fed to acme.sh. Then every time acme.sh needs to issue/renew the certificate it sends the TXT info to the internal acme-dns server, which in turn makes it available to the world.

Great question. My first pass at the project was looking to conform to the ACME DNS API [1]. There are some tools for cert management that use that API, so it gave me broad tool support with very little effort. The getlocalcert subdomains don't permit user modification of A, MX, or CNAME records on the public DNS; you've got to do that with a private DNS server you provide.

I may consider extending the service to allow A/AAAA records to private IP ranges, and then I'd need a more full featured API, but this far there hasn't been demand for the feature.

Hit me up on email if you want to chat more (in profile), we're solving some similar problems.

[1] https://github.com/joohoi/acme-dns

there is also https://github.com/joohoi/acme-dns and LE clients like lego supporting it.

Getting a wildcard certificate from LE might be a better option, depending on how easy the extra bit of if plumbing is with your lab setup.

You need to use DNS based domain identification, and once you have a cert distribute it to all your services. The former can be automated using various common tools (look at https://github.com/joohoi/acme-dns, self-hosted unless you are only securing toys you don't really care about, if you self host DNS or your registrar doesn't have useful API access) or you can leave that as an every ~ten weeks manual job, the latter involves scripts to update you various services when a new certificate is available (either pushing from where you receive the certificate or picking up from elsewhere). I have a little VM that holds the couple of wildcard certificates (renewing them via DNS01 and acmedns on a separate machine so this one is impossible to see from the outside world), it pushes the new key and certificate out to other hosts (simple SSH to copy over then restart nginx/Apache/other).

Of course you may decide that the shin if your own CA is easier than setting all this up, as you can sign long lived certificates for yourself. I prefer this because I don't need to switch to something else if I decide to give friends/others access to something.

As someone else said, it’s a huge pain to run your own dns services. However, if you want some separation, I recently saw https://github.com/joohoi/acme-dns

v0.9.1 is out and natively supports both https://github.com/joohoi/acme-dns and any dns provider available in https://github.com/acmesh-official/acme.sh

I have set up an acme-dns server to answer ACME DNS Challenges: https://github.com/joohoi/acme-dns