[davidkhess]

Here's an approach I've used before successfully. It's not perfect but it's better than nothing.

1. Create your own root Certificate Authority.

2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't be repeated between devices.

3. Add to your product support for ZeroConf/mDNS/DNS Service Discovery and advertise an https web server at myiotdevice-AABBCCDD.local.

4. Provide instructions to your users on how to download and install the certificate for your root CA (this only needs to be done once).

5. Print the name "myiotdevice-AABBCCDD.local" on the device and instruct users to type that in to a browser's address bar.

I'm doing this from memory so I may have missed an intricacy here or there (like DNS SD is a weird story on Windows 10) but this approach should basically work well enough.

EDIT - good commentary in replies about the dangers of the CA being compromised. Also, good mention of X.509 Name Constraints and how they can be used to mitigate that danger somewhat. More info here: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...

[oarsinsync]

> 1. Create your own root Certificate Authority.

2. Ensure that the security around your new root CA is watertight, so that if your environment ever gets compromised, someone can't generate a new *.google.com or *.yourbank.com certificate signed by your CA and then MITM your connection.

[merb]

3. use cross signing with name constraints to not have this problem

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

[Sebb767]

4. Find out that name constraints are either not supported or ignore by basically all major libraries.

[fomine3]

Issuing CA cert with Name Constraints is good, but end user should recognize the certificate is constrained to their domains or not.

[midasuni]

The end user should be able to choose the domains the root is valid for - regardless of x509 name constraints.

[jaywalk]

So then I have to install a root CA for every random IoT product I buy? Which also entails handing them the keys to my machine, since being a root CA means any certificate they generate will be trusted.

[mikeiz404]

That should work but trusting a root cert from a third party makes be a bit wary depending on how it is done.

If the certificate is scoped to only that domain or to only domains used by that user then I suppose it's OK but there is currently no way to enforce this, that I am aware of, without the user understanding and inspecting the certificate.

Thinking out loud here: It would be neat if browsers supported some form of addresses which are public key hashes like is done in many distributed systems. Maybe, out of caution, it would only be supported on local networks. For ease of use this address could be discovered via QR code or a simpler local dns name.

[varispeed]

I think there is the solution - to support scopes for certificates, but I am afraid big companies won't be keen on donating resources to implement that.

[Spivak]

Any device manufacturer that does this should not be allowed to touch anything related to security. It's one thing to have a little article about why they get the big scary security warning and how to add their device's cert as a one-off exception but "let this random IoT manufacturer vouch for any website" is nuts.

[yunohn]

I was looking into a similar approach, but wasn’t sure how to fix it for mobile devices and things like chrome cast. Any ideas?