Expiring on a specific date is dumb. What's the best alternative? Logging to a file somewhere? Warning messages to user? I like this idea: increasing delays.
So just use 20 year expiration? I'm not sure this is a good idea because (a) why have them expire at all then? and (b) that just means in 20 years the failure will be really catastrophic as there's nobody around who remembers what the thing does
So, why is expiring HTTPS worse than HTTP? The answer is that an HTTP site doesn't want encryption, but an HTTPS site does. Thus, if HTTPS fails for whatever reason, backing off to HTTP would be bad.
We saw that in the early days of "sidejacking" back in 2007: HTTPS failed for a lot of reasons, such as on slow satellite links, so Google would backoff and try the connections with HTTP, allowing us to intercept cookies. They had to fix that.
Now I'm a big fan of "opportunistic encryption" going the other way, that all links with "HTTP" should maybe try "HTTPS" first, and if available, use that, even if the certificate is self-signed. Buf if HTTP should go forward, still HTTPS should never go backward.
By the way, we should remember that LetsEncrypt takes the opposite approach with expiration: fixing the problem by making expiration really short. This means you automate the process. Instead of doing it manually every 5 years, you do it automatically and stop worrying about it.
As this tweet points out, trust on first use works really well for SSH. In many ways, SSH and SSL are two alternatives for the same protocol.
