I wonder if there would be interest in an "IoT ACME certificate tool" that would run on a more programmable/user-controllable device and perform automated renewal and deployment onto IoT devices using a library of contributed rules for how to install a certificate of various specific devices.
For example, in the coffeemaker case, maybe someone would contribute a rule (based on some kind of web automation framework?) that would upload new certs and keys over a LAN.
I think this would be great for Internet security overall, although it would probably cause a further explosion of support challenges (like "my coffeemaker was working fine with this tool for years, but now it suddenly stopped working—it doesn't trust the ISRG root and refused to accept my new certificate", etc.).
Excellent thoughts. A systematic approach here could lead to a generic model to push in other systems too. Even distributed sensor devices, perhaps. Might be a way to design-around some of the dead-end situations we've seen.
I wonder though... If the certificate for my coffeemaker expires, does my blonde roast turn to dark roast? What happens if it expires mid-cycle? Does caffeine affect the renewal process?
@schoen I read your concept as 3 major components: an API driven ACME client, a ruleset marketplace + accounts system to correlate a user to devices+marketplace rules, and a "device" that could either be a web-based tool or an app/physical device that can interact with the above (possibly host the ACME client) and deploy onto the local network.
I see the utility of that for everything BUT IoT devices.
Are you talking about deploying root certificates, or issued certificates?
I've worked with a fair amount of microcontrollers in the IoT space, and generally speaking the root certificates are included at compile time and are not changeable without a recompile of the original source code. I don't know if there's any way around that because depending on the architecture and the program/library, there's no guarantee there would be any accessible rewriteable storage at runtime. This also depends on the ssl stack/library used as well. Whether it's something developed/supported by the manufacturer or an open source stack like bearssl.
The same goes for issued certificates, however in places you need this you would be picking a device which specifically can have these rewritten at runtime, or at least stored in ram.
The whole idea goes out the window though when talking about propietary devices like random smart kettles from amazon. Short of hoping they can be supported by an open firmware like tasmota/esphome, it's just not going to happen.
I think there would be a lot of value in a system like this, but the implementation would be incredibly difficult, if nigh on impossible. That said, there could be a lot of value in exploring the different open source solutions to see what could be supported from a library and platform perspective, and drive the change to make it possible.
But everyone knows the S in IoT stands for security
I've mentioned it before a few times but Certify The Web (for instance) has deployment tasks that include things like SSH/SFTP or scripting to get a certificate onto virtually anything it can communicate with. If you can script it, it can do it.
So yes, I would say there is a demand for tools that can look after your certificates and distribute them as required (both push and pull distribution). The broad spectrum of things you can apply certs to (and methods by which you can achieve that) is absolutely huge though. The biggest obstacle is non standard ways to talk to the devices in order to do the deployment (e.g. some have no API and require authenticated posting to web forms etc).
I'd say DNS validation is the only practical solution so far, http/tls validation is great but it's not that practical if the ACME client isn't on the device.
Regarding the script library idea it reminds a lot of DNS validation because it also has the pain of thousand different providers with a thousand different update mechanisms.
If your IoT devices could all be taught to regularly download (and self-deploy) their cert from a given URL (presenting an auth token of some kind), then that would solve the problem or at least move it around a little towards a more manageable direction.
I've previously thought about whether it would be useful to have some sort of DNS API proxy service in the vein of acme-dns, but without actually needing to delegate zones or records to it. It knows how to talk to the various DNS provider APIs that exist and provides a common API for clients to use that would work with any of them. You pre-register some sort of connection profile for a particular provider with credentials and such and then you give your client the details to authenticate and publish against the proxy.
From a client perspective, it's just another DNS provider. So anything that already supports DNS plugins could use it. DNS credentials are centrally stored/protected and clients don't need direct network access to the real DNS provider.
Yes, I'd thought about that as well but my version was a hosted/managed API - the disadvantage was that they'd technically have to share their credentials with a third party (my company) but the advantage would be (almost) universal DNS validation support.