Google learning this the hard way with the recent chromecast outage[0]

[0]: https://www.googlenestcommunity.com/t5/Streaming/Regarding-a...

I think there is a strong argument to simply not checking certificate expiry dates in embedded hardware.

Just keep using the expired certificate forever.

Sure - that means if someone leaks the private key that everyone worldwide needs to do a firmware update to get security.

But that's probably less user harm than everyone worldwide needing to do a firmware update to replace an expired cert, and having a dead device otherwise.

1) You can't pass a PCI-DSS audit if you have expired certificates. 2) You can't always tell the CDN providers what to do with certs. 3) We've seen examples of new root certificates that mean devices don't know about things like LetsEncrypt

At the very least the user should be able to override the failing certificate check. So much "security" cargo culting is intentionally planned failure.

99% of consumers don't understand what that means and if we normalise the average consumer bypassing certificate checks that's definitely a bad thing.

So don't burn CA pubkeys into your binaries without means for user override. If the software can persist a user-specific analytics ID it can support user certs. This is a solved problem.

Yeah but how many people would do that? You, me, and maybe thousand other people here and similarly minded. That's sadly fart in the wind for such companies and not worth creating more friction and risk (ie folks hack their under-warranty tvs till they stop working and then come back asking for free replacements and tarnishing the brand).

I wish there was some trivial real-life applicable solution to this that big companies would be motivated to follow, but I don't see it. Asking for most users to be tinkering techies or outright hackers ain't realistic, many people these days often don't accept basic aspects of reality if it doesn't suit their current comfy view, don't expect much.

But we could do it for our friends and families. A repair shop could do it too. Instead of a full brick.

Here in South Korea, everyone who uses online banking has to renew and reissue banking certificates every year. While I'm not convinced the certificate process is 100% safe, using certificates is one good concept in the sh*t show of Korean online "security" malware users are required to install.

You can add as many user-defined, custom trust anchors as you want, they’re not going to make an expired server TLS certificate work.

Don’t get me wrong, allowing users to add their own trust anchors is absolutely a good thing. But it wouldn’t change anything if the vendor did what GP suggested, which is that the vendor "[does] not touch the backend service." Because one day, their TLS certificate would expire, and they would technically no longer be able to deliver security updates even if the user wanted them.

Not my problem as a buyer. Build the infrastructure to make certificates and everything else work for a reasonably long time. Service is part of the contract.

That's the point, there are no substantive contracts between you and the OS. If we want apps to be responsible for root certs that's interesting, but then the app needs some roof of trust with the OS anyway.

> Not my problem as a buyer.

Mentioning that certificates expire was directed against GP’s unreasonable demand that the vendor "do not touch the backend service." This doesn’t have to do anything with the buyer.