Comment by amluto | Hacker News Reader

Comment by amluto | Hacker News Reader

Parent Full thread

Maybe it’s time for an ACME extension or some other mechanism to make this sort of certificate renewal less absurdly complex and baroque.

Right now, for a device to get a certificate via ACME, it needs to do one of:

(a) Be reachable, from the public Internet, in accordance with its A and/or AAAA records. This is a nonstarter for, say, a printer or switch.

(b) Be able to change a DNS record. This is doable if the device has outgoing Internet access and appropriate keys, but safely issuing those keys is not cleanly and uniformly possible across authoritative DNS servers. And there is nothing resembling a standard protocol to actually ask for the DNS-01 magic record to be installed. Do you really want every appliance to implement every plugin in this list:

https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...

(c) Get some other agent to do (a) or (b) and issue the certificate to the device. Again, there is no standard here.

This could be SO much better if there was, for example:

(d) A complete, standard three-way protocol between the device that needs a certificate, the DNS provider, and the CA that would result, cleanly, in a certificate, and

(e) A fully standard way to do this with the help of a proxy that an communicate with the device, the DNS provider, and the CA, but without the device having any Internet access at all.

Then an administrator could set up a certificate proxy, enroll all their devices with the proxy, and get them certificates, with automatic renewal.

I think for (c), we have EPP: https://en.wikipedia.org/wiki/Extensible_Provisioning_Protoc... But I have never seen it in operation personally, having never worked for this kind of ISP.

For (b), I don't see why you couldn't install the required records using dynamic DNS, which is already widely implemented and deployed in other contexts. (It's the RFC 2136 item on the Certbot list.) It doesn't seem to be very commonly offered by DNS providers, though. It does work if you maintain the zone locally and use zone transfer (presumably with TSIG for authentication …) to publish to public DNS servers (if you don't want to run the public DNS servers yourself).

I think this space is a bit of a mess because no one is really expected to put this together themselves, rather they should get everything (mail hosting, web hosting, plus certificates) from a service provider. It's a wonder that grassroots participation is still possible at all.

Isn’t (a) solved by using an internal CA? I’m not seeing an immediate use case where something like an appliance is publicly addressable, but not at the A/AAA record.

(e) also sounds a lot like just running one of the existing certbot plugins on the proxy unless the appliance can’t be reverse proxied.

Running an internal CA is maybe a good way to deal with networking hardware managed by only a few people, but it’s entirely useless if the goal is to access a device from a client that won’t trust the CA. Also, name-constrained CAs are not widely deployed, and non-name-constrained CAs are asking for trouble.

As for a proxy, how exactly would you deploy certificates, via proxy, automatically renewing, to, say, a network switch, two different brands of printer, a camera, and a pile of containers and VMs, all from different vendors? Sure, you can hack something up, but it will be a kludge and it will not scale.

(a) Not everyone can afford to manage that (e) They key point is that it needs to be standardized to the point of the vendors supporting it. As long as there is a general API (for example) on the device that I can point a plug-in to, it's fine, but AFAIK such a thing does not exist at this point in time.

Internal CAs are a pain because enrolling new CAs is difficult, especially without device management. It can also interfere quite badly with product testing.

Technically, it's not required for anyone but you to validate ownership of names further down the DNS tree once you have shown control over the DNS tree further up. Maybe combine it with the public suffix list to discourage misuse by certain service providers.

Yeah, https for local network appliances has been basically a nonstarter for ages, with the browsers basically shouting down any proposal to enable it with "it's not secure enough", while the trivially-sniffable status quo trundles on just fine (and administering your own root CA is a non-trivial amount of work for those who are capable of it, as well as opens you up to further issues given most browsers ignore the scope of root certificates, so anything you trust on your machines you are trusting for all sites).

Reply on news.ycombinator.com