Why can't revocation be limited to ALPN certificates which negotiated with wrong TLS version or OID?

Why isn't only the certificates for which authorizations using the "bad" OID's or were performed using less than TLS 1.2 revoked?

What I have understand, is that only certificates that WAS issued against the policy needs to be revoked. Not all certificates that used a validation method, were it was possible to break the policy.

The tricky part is if this information isn't logged, but for all unexpired authorizations that information should be available right, so no need to revoke all authorizations that used the method, provided they used it correctly right?

2 Likes

I think the issue is that the TLS version used in the ALPN negotiation isn't part of their audit logs (I also saw OID logging in relation with metrics only, not audits) so they probably can't say with certainty what TLS version or OID was used for a challenge validation. Hence all validations done before the fix have to be considered to be in non-compliance, as there is no explicit proof that they're not.

About cached authz: I don't see how that changes anything, you either have stuff in your audit logs or you don't. Additionally, all unexpired TLS-ALPN-01 authorizations were already revoked 2 days ago [see the timeline here], before the challenge was re-enabled in prod - they're long gone to prevent new certificates being issued with old, potentially non-compliant, authorizations.

9 Likes

Nummer's reply here is correct. You can read the details in the complete incident report: 1751984 - Let's Encrypt TLS Using ALPN TLS Version and OID

11 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.