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

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

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.

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.

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.

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.