On 2021.10.14, Let’s Encrypt staff discovered a bug in our ACME implementation that made it possible to revoke certificates without sufficient demonstration of control over the corresponding domain(s). We are able to share details of this bug now that other ACME certificate authorities have had time to patch their implementations. This bug was reported to CA/B Forum management 2021.10.14 and the report was made public 2021.12.13.
In ACME, anyone can order revocation of a certificate by demonstrating control over either: 1) the private key used for that certificate, 2) the issuing ACME account key, or 3) all of the domains in the certificate. When a certificate is revoked with the reason “keyCompromise”, the CA is required to revoke all other certificates using the same key. The bug was that an ACME client could request that a certificate be revoked with reason “keyCompromise” by only demonstrating control over the domains in the certificate, not the private key used for the certificate. This would trigger the revocation of all other certificates sharing that key, even though no control over the key nor over those other certificates had been demonstrated. The fix was to ensure that the certificates can only be revoked with reason “keyCompromise” when the revoker has demonstrated control over the certificate’s private key directly.
We discovered this bug during an investigation when someone requested revocation of a certificate with the “keyCompromise” reason and proof of domain control. This triggered a revocation of all certificates associated with that key, and the subscriber who controlled the private key was rightfully unable to find the source of the key compromise. Within eight hours of confirming the bug, a patch was deployed to boulder. We will be making this change in our simplified ACME implementation, Pebble, that many in our community use for client integration testing.
This change may impact some ACME clients. If you maintain an ACME client, please ensure that your client always uses the correct revocation reason code, and only requests the “keyCompromise” revocation reason when revoking using the certificate private key. If you have questions, please post them in this forum thread: Question re: Change in Revocations Methods