> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised

This is true, but the machine doing DNS modifications doesn't need to be accessible to any outside initiated connections at all. So if someone has the capacity to compromise such a computer, what would stop them from compromising your desktop computer or your laptop instead?

But either way it would indeed be nice to have further limits on what the box could do. But I think LetsEncrypt does not need to change anything to make this possible.

https://letsencrypt.org/docs/challenge-types/

The DNS verification works by creating a DNS TXT record named "_acme-challenge" with a TXT value on the domain you are verifying.

So really what you want is for your DNS provider to implement into their API access keys that can be restricted so that the absolutely only thing the key is allowed to do is to create, change and delete the DNS TXT record named "_acme-challenge". Perhaps some DNS providers already make this possible? But the one I am using is only able to limit it to a ZONE, but not to a specific record type and not to a specific label.

In fact I wish CloudFlare would allow such specific fine-grained permissions. But even if they did they'd probably make it part of the Enterprise plan and I am still not an Enterprise customer so.

Edit: Meanwhile that I was writing this someone else posted a sibling comment about ACME DNS alias mode, which I had not heard of. https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... That's very close to good enough. Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.

I do the challenge verification using DNS and Route 53, and the process has permission to update the challenge record and nothing else. So what you are describing is definitely possible.

I looked into this previously and was unhappy to learn that Route53 doesn’t allow permissions based on specific records. The most granular permissions were for a full zone at the time.

> Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.

A handy CLI utility that can be used in hook scripts that can update dozens of APIs at different DNS providers:

* https://github.com/AnalogJ/lexicon

Yes, but what I am saying is that it’d be nice for the API access tokens issued by the DNS providers to be limited to specific record type and specific label.

For example, the access tokens that you generate for giving tools like that one access to act on your behalf, when using CloudFlare as your DNS provider.

CloudFlare at the moment does not to my knowledge offer such fine grained controls as what I am talking about, on the API access tokens.

With the DNS option the machine doing the request doesn't have to be the machine using the certificate though.

I have a separate machine doing the DNS challenge and the cert is then distributed to the machine needing it.

Technically true for the regular web challenge, but easier with DNS I think.

I'm doing the same for my personal/home lab stuff. I've been using https://github.com/joohoi/acme-dns for the dns server running on a small vps for all my internal certificates and I haven't had any issues with it.

This is what I do as well. I have set up acme.sh[1] on a Raspberry Pi on my home network, which isn't accessible from the outside. It is triggered every night by a systemd timer and renews (using the DNS challenge) and deploys all expiring certificates.

[1] https://github.com/acmesh-official/acme.sh

> If you want to use the www auth you need to allow outbound connections to any IP

Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions:

* https://github.com/dehydrated-io/dehydrated/blob/master/docs...

> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.

Are you aware of LE/ACME's "DNS alias" mode?

* https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth.

People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition):

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

There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider:

* https://github.com/AnalogJ/lexicon

And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.