Comment by blakesterz

That's the thing. We don't always know. Hence the need to reduce the attack lifetime.

An example I experienced was an employee accidentally shipping keys/certs to a vendor in a support dump of a network device.

I had to revoke the certs and in anticipation I pulled together customer support, engineering, legal, various security orgs in the event that revocation would cause outages from cached certs from middle boxes of which there were plenty or other weird b2b setups.

It turned out to be a nothing-burger. None of the browsers or MitM proxies actually did anything with revocation and happily used the revoked certs without even a single warning from tens of millions of end users and system. This was around 2014. Curious if that has changed and if anyone here has tested revocation in a staging environment that has devices that cache certs.

Impossible to say, as most people probably don't even know that their private key is stolen. I've personally seen it only once on a real certificate revocation. Yet another reason to have shorter lifespan.

Often enough a protocol was made to deal with it. The compromises have mostly been kept quiet though or at least didn’t get much news traction.

Hmmm. This solution still leaves quite a few days a compromised certificate can be used(!).. that's significant.. but I guess it's better than nothing?

I had to get certificates revoked for HeartBleed. :P