Please help me understand and understand whether LetEncrypt can help.
It very cost-effective to add a hardware trust platform - microchip's ATECC608A seems pretty popular - to an IOT system.
My understanding is that this should provide a level of trust in that system at least equal to the DNS-based trust mechanism. With that, is there any way to get a LetEncrypt certificate for these systems?
The IP address of these IOT systems will not usually be Internet routable, indeed in Industrial Environments (my interest) they are usually not Internet connected. However, information from these (web-displays,information sent to remote systems, etc.) needs security - trusted certificates.
Guidance, ideas, education, etc. gratefully accepted. Thanks,
Which means that the basic answer is that LetEncrypt can't help here. It's a pity. The number of non-routable IOT device (even if we allow that they must be Internet connected) is huge and growing rapidly - along with the security problems associated with them.
The lack of Root CA support seems to add to the massive disorganized fragmentation of solutions provided by, particularly the large Cloud vendors, proposing proprietary, vendor-locked, solutions to a problem that's already been solved, robustly and at scale for routable devices. "essential infrastructure for the Internet" now includes IOT devices and some of these control critical physical infrastructure, such as water distribution and the power grid.
Trusted certificates at that level would seem to be an essential step. It's possible I totally misunderstand what should be possible, or perhaps this is just a feature request...
You can use Letsencrypt certificates. But you have to use dns validation, not http validation. That's all.
PS: There are a lot of other IOT systems with Letsencrypt. Same with routers (like FritzBox) without public access, but with a vendor specific subdomain, so dns validation is always possible.
Depends how you define IOT. Imagine an embedded system in, say a water treatment plant. It's on an internal network, suitable segmented but has a 192.168.x.x address. For the sake of argument, lets imagine that it can access the Internet, eg to push data to a Cloud provider. Typically you'd want a PKI infrastructure to secure that data and you want to anchor that security.
As to the second paragraph. AWS, Google, Azure ,etc. all have some unique way to add this security that's unique to them (as far as I can tell).
In that case your IoT device is actually the client, not a server requiring a valid certificate.
Also, I think that for many IoT devices (and certainly critical devices) it's often more logical to use your own custom PKI and not use the public PKI.
I feel like you really need to ask yourself: "At what point in time will my IoT devices actually be taking public requests?"
I, for one, don't want a chip responsible for determining the cleanliness of the public water supply to EVER be taking public requests from the internet.
This seems like the ideal circumstance for a reverse proxy server.
It can be both a client and a server, but even clients can benefit from certificates eg MQTT. The system might serve a web-HMI viewable by someone on that network or it might not be 100% segmented.
There are many use cases that don't necessarily imply access from the public Internet. If you consider that the entire facility is behind a NAT but the IOT devices are serving web-HMIs, you still (ideally) don't want self-signed certificates.
In SCADA the systems are often remote - lift stations, distribution, etc. etc. - in which case you want no access into the system, but to push signed/encrypted data to the 'net. @ Osiris considers that a "client" which may decrease the need for a trusted certificate, but I don't think it eliminates it.
It should be no more difficult to issue a cert from an internal/private PKI system that a public one.
If you really care about keeping off the Internet, then you should really consider not relying on it at all, nor interacting with it either.
Is it really that easy? If I create a Fargate container on AWS it has a 10.10.a.b address (or something). If I assign mycontainer.mydomain.com to that IP can I really get a certificate for the container?
Fair comment but sometimes I just need someone to expose the scope of my ignorance so I know where I should be starting to back-fill. Thanks (and genuinely, not facetiously).
