SSL.com: Revocation due to keyCompromise while keeping other TLS certs with the same public key unrevoked
The bug was opened after a SSL.com subscriber revoked a certificate due to keyCompromise, while SSL.com left other TLS certificates sharing the same public key unrevoked. The reporter expected SSL.com to revoke all certificates with the same public key when a subscriber requests a keyCompromise revocation. Mozilla staff discussion noted that a CA is only required to revoke all certificates sharing a key when the CA obtains evidence that the subscriber’s private key suffered a key compromise, and that some revocation request mechanisms (including ACME) allow subscribers to request a revocation reason without providing evidence/proof of key compromise. The discussion referenced Mozilla’s Revocation Reasons guidance about how revocation scope depends on whether the subscriber has proven possession of the private key. The reporter indicated they would try to close the bug. The bug is currently marked RESOLVED with resolution INVALID.
- A SSL.com subscriber revoked a certificate due to keyCompromise, but SSL.com left other TLS certificates with the same public key unrevoked.
- Community commenter — Reported that a subscriber keyCompromise revocation occurred but SSL.com kept other TLS certificates with the same public key unrevoked, and expected all such certificates to be revoked.
- Internet Security Research Group — Explained that the CA’s obligation to revoke all certificates sharing a key depends on whether the CA has evidence of key compromise, and cited Mozilla guidance and ACME behavior regarding revocation reason requests.
- Community commenter — Acknowledged the explanation and said they would try to close the bug.