[Crinus]

As a user i really dislike this because more often than not certs are broken because the server is temporarily badly configured (instead of some malicious reason) and i do not even care about it (or even if it was compromised really) as all i care about is read some page's content, connect to some messaging server (Pidgin often had issues with -IIRC- MSN servers), etc.

Of course if it is about, e.g., downloading some application (like an auto-upgrade mechanism) then sure treat it like that. But in other cases let the user decide, even if such sort of decision is made opt-in.

[_visgean]

but if there was no easy way to circumvent it, the website admin is much more inclined to fix it up...

[Eun]

What about local management software listening on some ip address? (e.g. routers?) There will never be a valid certificate for a local ip address.

[tialaramex]

The device doesn't _need_ a certificate for a "local" (presumably RFC1918) IP address.

It needs a certificate for its name, and arranging to have a valid (by which I'm assuming you mean trusted in browsers) certificate for a name isn't hard. Sectigo and DigiCert both offer vendors a suitable product for that purpose last I checked. If you're making a short run hobby product you could just use Let's Encrypt.

[Eun]

In a typical consumer network every device is getting a (more/less) random ip address by dhcp. So there is no guarantee that the dns name will always point to the right ip address, therefore it is impossible to use a fixed dns name. This fact makes it impossible to get a valid certificate. Especially not from let’s encrypt.

In easy words: You use example.com for your IoT device. Where should example.com point to? To all possible ip addresses? I don’t think so...

Besides that you need a private key on the iot device for decrypting the tls traffic, imagine somebody gets access to the device and now can basically mitm all other devices...