▲ | fiddlerwoaroof 3 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||
It makes systems more reliable and secure for system runners that can leverage automation for whatever reason. For the same reason, it adds a lot of barriers to things like embedded devices, learners, etc. who might not be able to automate TLS checks. | ||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | thayne 3 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
Putting a manually generated cert on an embedded device is inherently insecure, unless you have complete physical control over the device. And as mentioned in other comments, the revocation system doesn't really work, and reducing the validity time of certs reduces the risks there. Unfortunately, there isn't really a good solution for many embedded and local network cases. I think ideally there would be an easy way to add a CA that is trusted for a specific domain, or local ip address, then the device can generate its own certs from a local ca. And/or add trust for a self-signed cert with a longer lifetime. | ||||||||||||||||||||||||||||||||||||||||||||||||||
|