3 ms·
I think that's largely because "blow everything up" is arguably the correct thing to do on an expired certificate, at least compared to "silently do an insecure
by thraxil 5y ago
I think that's largely because "blow everything up" is arguably the correct thing to do on an expired certificate, at least compared to "silently do an insecure thing". If you visit a website with an expired certificate, most browsers do what you suggest and ask the user if they want to proceed at their own risk. All the software that doesn't have a direct user to ask, like basically anything running on a server, has to either fail with an error when something is wrong with the certificate, or open up a security hole that will probably eventually be exposed and exploited.
- withinboredom 5y agoAll software has a user, otherwise, what is the point of having the software in the first place? A server’s user is an operator, devops, or whatever the org calls it.
- thraxil 5y agoNot all software has a user present when it runs that can make decisions like that. Probably the vast majority doesn't. If an automated update process that runs on thousands of servers encounters an expired certificate, it's not like it can pause and pop up a prompt to ask me if it should continue or not. I do a lot of immutable infrastructure and don't even have shell access on those machines, so even if I wanted to, it wouldn't be possible.
- withinboredom 5y agoThis seems pretty easy to mitigate if someone created a IGNORE_EXPIRATION environment var where any matching cert fingerprint would ignore the expiration date. I have a feeling the more paranoid people would hate it, but it’s better than what we have now where it’s all-or-none ignoring cert validity.