> lots of "internal" devices that neither need public access nor are capable of running an automated renewal job (routers, switches, IoT gizmos, etc).
How is that a CA's reponsibility? I wish vendors would setup an appropriate API for dealing with that on their devices. Quite often you need to enter strange web interfaces in order to setup a certificate.
Let's Encrypt needs to verify you're in control of the hostname. This can happen with either http or dns verification. DNS verification with certbot requires you to setup almost nothing (i.e. you don't need the machine running certbot to be exposed to the public internet) if you're using a supported DNS provider (there're many) for the zone.
So, the missing part is NOT in let's encrypt infrastructure. It's in the device API. You can launch the certificate renewal script just about anywhere (e.g. a small server or vm within your network that can access the internet); but then, how would you automatically deliver the certificate to the device? That's the missing link.
The request wasn't (only) asking for a solution by the CAs but by the '"SSL All The Things!" crusaders' which includes creators of browsers and mobile devices enforcing stricter rules and a request to take these things into more consideration.
In my words: We need solutions for non-technical individuals to run a somewhat secure environment locally without being confronted with security warnings everywhere. A CA can play a role in that, but probably not fully solve it.
Are you joking? The primary reason why one would want one certificate per device is because you are directly connecting to the device instead of letting the device connect to the vendor API which is already behind HTTPS. Your idea will just lead to a lot of bricked IoT devices once the vendor takes his certificate renewal API down.
I don't understand. The device should expose an API (instead of a webinterface) to generate csrs and upload certs (ideally the key should never leave the device). What is the vendor api?
How is that a CA's reponsibility? I wish vendors would setup an appropriate API for dealing with that on their devices. Quite often you need to enter strange web interfaces in order to setup a certificate.
Let's Encrypt needs to verify you're in control of the hostname. This can happen with either http or dns verification. DNS verification with certbot requires you to setup almost nothing (i.e. you don't need the machine running certbot to be exposed to the public internet) if you're using a supported DNS provider (there're many) for the zone.
So, the missing part is NOT in let's encrypt infrastructure. It's in the device API. You can launch the certificate renewal script just about anywhere (e.g. a small server or vm within your network that can access the internet); but then, how would you automatically deliver the certificate to the device? That's the missing link.