Short answer: because the CA/B forum requires this. See "Baseline Requirements
for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.7" section 13.1.5 point 3.
Certificate authorities provide assurance. In this instance, they received a request from someone asserting "I am localhost.ttconfig.xyz, I have this public key, and I sign this entire statement using my private key". The certificate authorities validated that the requester did in fact control localhost.ttconfig.xyz, then they took the request above, added "I am <Comodo/GeoTrust/thawte>, this certificate reflects the identity and intentions of <subject>, and I sign this entire statement using my private key".
Your browser trusts certificate authorities to make statements like these. This trust is not given blindly; it's instead driven by complex procedural machinery. Browser vendors require certificate authorities to do specific things in order to earn and keep the browser's trust. For example, see Mozilla's CA policies:
The certificate authorities have rules to follow, and they in turn require that their subscribers do certain things so the CA can comply with those rules. One of the requirements CAs make of their customers is that they protect their private key.
Why is this important? Well, remember that the CA made a statement that "this certificate reflects the identity and intentions of <subject>". Losing your private key means anyone else can use that certificate, even if they are not you – which makes the CA's statement a lie. CAs are built on trust, so they must revoke it.
Thank you for the detailed explanation. I was not aware that there were rules enforcing such actions.
The linked PDF answers the question why corrupted software stacks do not qualify for forced revocation. Section 10.2.4 (which is the lever for 13.1.5) requires (but not limited to that) a private key to be "communicated" to restricted parties before a revocation might be considered.
-->
For the small fee of some downvotes i learned that any cloud based service storing private keys for end users qualifies for a revocation - as long as the CA knows about it.
Perhaps this is a dumb question, but what should the torrent time developers have done differently to have local valid TLS without bundling a private key?
https://cabforum.org/wp-content/uploads/BRv1.1.7.pdf
Long answer:
Certificate authorities provide assurance. In this instance, they received a request from someone asserting "I am localhost.ttconfig.xyz, I have this public key, and I sign this entire statement using my private key". The certificate authorities validated that the requester did in fact control localhost.ttconfig.xyz, then they took the request above, added "I am <Comodo/GeoTrust/thawte>, this certificate reflects the identity and intentions of <subject>, and I sign this entire statement using my private key".
Your browser trusts certificate authorities to make statements like these. This trust is not given blindly; it's instead driven by complex procedural machinery. Browser vendors require certificate authorities to do specific things in order to earn and keep the browser's trust. For example, see Mozilla's CA policies:
https://www.mozilla.org/en-US/about/governance/policies/secu...
The certificate authorities have rules to follow, and they in turn require that their subscribers do certain things so the CA can comply with those rules. One of the requirements CAs make of their customers is that they protect their private key.
Why is this important? Well, remember that the CA made a statement that "this certificate reflects the identity and intentions of <subject>". Losing your private key means anyone else can use that certificate, even if they are not you – which makes the CA's statement a lie. CAs are built on trust, so they must revoke it.