Re:Validating SSL Certificates in Non-Browser Software (2012...
by _visgean on Friday August 23, 2019 @11:29AM
(#20778626)
but if there was no easy way to circumvent it, the website admin is much more inclined to fix it up...
Re:Validating SSL Certificates in Non-Browser Software (2012...
by Eun on Friday August 23, 2019 @12:32PM
(#20779257)
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.
Re:Validating SSL Certificates in Non-Browser Software (2012...
by tialaramex on Friday August 23, 2019 @01:22PM
(#20779993)
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.
Re:Validating SSL Certificates in Non-Browser Software (2012...
by Eun on Friday August 23, 2019 @04:21PM
(#20782172)
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...
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.