1 measly second is going to break WebPKI?!
> If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that:
> The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.
However, letsencrypt's report neglected to do any of this, so he queried them on this
LetsEncrypt automated the certificate creation, which resulted in very large number of certificate issued. But at the same time, it should be possible to revoke them all.
If the revocation mechanism doesn't scale as much as the creation, this is a huge problem.
This time, the misissued certificates probably won't cause large issues. But they are misissued nevertheless and should be revoked.
If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ?
As here, the severity of the issue should be weighed against the severity of revocation.
"Half the internet needs to manually renew some certs early" is a reasonable approach if there's something risking exposure of sensitive data. It's not for "the certificate is valid for an extra second".
Of course, those sites are a minority and possibly not even a plurality, but in theory revocation can be made a smaller burden over time as more sites are using automation successfully.
I also know there are tons of Let's Encrypt users who are still using a completely manual workflow. Some of them just don't understand some part of the automation concept, while others have devices and/or operating systems where they simply can't automate certificate renewal, because they couldn't install any software that would facilitate it.
For this specific reason, Certbot is recommended to run twice per day, and that is the default behavior in OS Certbot packages as well as the more recent official snap package.
Further to mholt's point, not all clients will enforce OCSP at all, while if you're using stapling, the client is being told about the last-valid OCSP response, so the outage would probably be a fairly small minority of clients in either case.
Of course, clients can ignore that and use their own revocation lists/logic, which sometimes get pushed faster than OCSP responses. (Or clients can just block any certificates/CAs they want to, really.)
If anything mainstream actually checked OCSP, this seems like you'd still be effectively making the old cert unusable before the new cert was issued, which is unfortunate.
On the plus side, I don't think OSCP ever went mainstream.
Of course, clients can do whatever they want to enforce OCSP, including pushing their own revocation lists and ignoring OCSP staples. Sigh.
"Mozilla recognizes that in some exceptional circumstances, revoking the affected certificates within the prescribed deadline may cause significant harm, such as...when the volume of revocations in a short period of time would result in a large cumulative impact to the web."
He does have a good point that something quite similar happened a month ago[1], and should have trigged a deeper dive that would have exposed this as well. You could interpret that as LE needing some better discipline around process.