[anonacct37]

The actual damage is that it's pretty common (my last team has this happen) for a team to setup a cert, verify it works, and then when they deploy the cert it works some of the time or "works on my machine" and so the failures seem really random and by definition hard to reproduce because you have to restart chrome to reproduce.

Probably the tl;Dr is that validating against a persistent cache like Firefox is fine. Validating against an ephemeral cache with chrome is likely to cause a lot of breaking.

[KAMSPioneer]

Sort of a corollary to your point: if an admin sets up a website and verifies with Firefox (or Chromium, whatever), and then later the server needs to communicate with...basically any tool that speaks HTTPS but isn't a web browser, then there will be many tears shed by that admin.

For instance, you stand up a server, and then a user complains their script using cURL, wget, etc. doesn't work, and if you aren't paying attention you'll have no idea why.

Inb4 why can't the OS certificate store just do the same thing: I suspect people will tend to install OS updates less frequently that browser updates, so it will tend to be less reliable.

[anon4242]

This is why you should do `openssl s_client -connect <your site>` to verify TLS when changing your server's TLS certs.

[remram]

This happens to me, every time IT renews that one certificate the API stops working. The website works fine and that's all some people check.