4 ms·
Well, from my understanding, they have no idea of whether or not a given certificate was misissued as long as it meets the baseline criteria for triggering the
by thenewnewguy 7y ago
Well, from my understanding, they have no idea of whether or not a given certificate was misissued as long as it meets the baseline criteria for triggering the bug (which seems to be just "issued after X date with more than 1 domain").
So while the number of certificates that should not have been issued due to a blocking CAA record is likely small (or possibly even 0), they have to revoke every cert that could have triggered the bug, as they have no way to travel back in time and find out what the CAA records they didn't check would have been.
- tialaramex 7y agoThe criteria also require that the challenge answers used to validate control were old (more than eight hours old). If all proof-of-controls were fresh the CAA checks are also fresh for those proof-of-controls so there's no bug. That's why the big list is "only" about three million certificates. Suppose you own example.com, example.org and example.net and all you do is every 60 days or so you spin up Certbot once to get a certificate for six names, the three domains and the associated www FQDNs - that won't trigger this bug because each time your old proof of control have expired and new fresh ones will be used, triggering fresh CAA checks. You're right though that it's likely the number of truly mis-issued certificates may be zero because the most common way to have a CAA record deliberately changed to forbid Let's Encrypt after having successfully done a proof-of-control (the scenario that would trigger their bug) is researchers looking for bugs in CAA checking, and of course such researchers would have reported this to Let's Encrypt triggering exactly the same incident but probably at a more friendly time like a Monday morning.