Bonus points for client clock error. If I had a nickel for every time...

The best is when it's a timezone issue and the distant end responds with "I have 0 drift, must be a problem on your end". Crypto is hard, time is hard. Crypto which relies on time...

I mean, sure, there's more things that can go wrong once you add TLS to the stack. At the same time, there are so many other guns to shoot yourself in the foot with, so why is that we should draw the complexity trade-off line between HTTP and HTTPS? HTTPS seems to be good enough for 50% of all page loads nowadays. There's no active attack scenario here (which I agree would be a concern for critical services!), and for every possible TLS server or client issue, there are a multitude of other server, network or browser issues that could have a similar effect.

> You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.).

Well, that was the context of this thread. Both the OP and konklone are talking about attack surface. If you want to talk about how running a service via TLS and using HSTS makes HA harder, that's a different discussion.

> Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.

OCSP and CRL is soft-fail by default in all browser I'm aware of. The server is also in control of it via OCSP Stapling, so it has all the tools it needs to keep the server available, assuming proper configuration and monitoring (which is true for a HTTP service as well).