Hacker News Reader

Comment by nickf | Hacker News Reader

Sure, but in those examples - automation and short-lifetime certs are totally possible.

Except when it's not, because the system rarely (or never) touches the Internet.

It might never 'touch' the internet, but the certificates can be easily automated. They don't have to be reachable on the internet, they don't have to have access to modify DNS - but if you want any machine in the world to trust it by default, then yes - there'll need to be some effort to get a certificate there (which is an attestation that you control that FQDN at a point-in-time).

and we're back to: How do I create an API token that only enables a single record to be changed on any major cloud provider?

Or.. any registrar for that matter (Namecheap, Gandi, Godaddy)?

The answer seems to be: "Bro, you want security so the way you do that is to give every device that needs TLS entire access to modify any DNS record, or put it on the public internet; that's the secure way".

(PS: the way this was answered before was: "Well then don't use LE and just buy a certificate from a major provider", but, well, now that's over).

One answer I've seen to this (very legitimate) concern is using CNAME delegation to point _acme-challenge.$domain to another domain (or a subdomain) that has its own NS records and dedicated API credentials.

There are ways to do this as pointed out below - CNAME all your domains to one target domain and make the changes there. There’s also a new DCV method that only needs a single, static record. Expect CA support widely in the coming weeks and months. That might help?

Right now that’s an email to an address listed in whois, and I’m happy to go in and click that link annually.

I don’t need to create any new and operationally unnecessary attack surface to prove that I control the domain.

Reply on news.ycombinator.com