Let's Encrypt: OCSP responses with no revocationReason

This case reports an issue where Let’s Encrypt OCSP responses for revoked certificates were served with revocationReason set to “unspecified” (0) after a short period, even though the certificates’ certStatus remained correctly set to revoked. Let’s Encrypt SRE noticed during routine maintenance on 2020-06-18 that an OCSP response for a certificate revoked with revocationReason = keyCompromise (1) was being served with revocationReason = unspecified (0). Let’s Encrypt identified the cause as a bug in code that updates OCSP responses: the initial OCSP response after revocation used the correct revocationReason, but updated responses used a default value instead of the value stored in the database. Let’s Encrypt stopped generating OCSP responses with the problem and fixed the code, with the fix merged and deployed on 2020-06-19. The bug was closed as RESOLVED with resolution FIXED, and Mozilla indicated it would be closed as Fixed rather than Invalid. Mozilla participants also stated they did not consider this a compliance incident, while acknowledging the usefulness of the proactive disclosure and explanation.

1. 2020-06-18 Let’s Encrypt SRE noticed during routine maintenance that OCSP responses for a revoked certificate were being served with revocationReason = unspecified despite certStatus remaining revoked.
2. 2020-06-19 Let’s Encrypt deployed a fix to correct OCSP response revocationReason handling and stopped generating OCSP responses with the problem.

1. 2020-06-26 Internet Security Research Group — Created the bug report describing that after ~three days post-revocation, OCSP responses for revoked certificates with non-zero revocationReason were served with revocationReason = 0, due to an OCSP update code bug.
2. 2020-06-26 Community commenter — Responded that it may not be a compliance bug under current policies, but praised the detailed proactive notification and asked if anything was missed.
3. 2020-06-26 Internet Security Research Group — Agreed it likely does not violate CPS, and explained the notification was for unexpected unintended behavior and that public root-cause analysis helped prevent similar bugs.
4. 2020-06-29 Mozilla representative — Stated Mozilla did not consider it a compliance incident and planned to close it as Fixed rather than Invalid, noting updates could still be posted after marking it fixed.