SwissSign: CRL/OCSP revocation time mismatch

SwissSign reported a compliance incident involving a mismatch between revocation times shown in CRLs versus OCSP responses. While implementing a change to improve backdating of certificate revocation in key-compromise cases, a developer discovered that the OLD CA platform determines the revocation timestamp differently for CRL and OCSP. The OCSP responder reads a database field updated via a trigger when status changes to “revoked,” while the CRL generator reads a separate database field set by the CA backend; latencies or rare connection issues could cause the two fields to differ by more than 1 second. SwissSign’s investigation found 1,446 revoked certificate database entries where the fields differed by more than 1 second, and it stated that certificate content was correct and compliant while only CRL revocation times were affected. SwissSign decided to continue serving the incorrect CRL times until a fix could be deployed, to avoid a larger regulatory violation and ecosystem risk from stopping CRL service. The hotfix was implemented, tested, and deployed on 2023-02-13, after which the listed certificates showed the same revocation time on CRL and OCSP. The bug was later closed as RESOLVED with resolution FIXED.

1. 2023-02-07 Developer detected a discrepancy in how the OLD CA platform determines CRL vs OCSP revocation timestamps.
2. 2023-02-13 SwissSign implemented, tested, and deployed a hotfix to align CRL and OCSP revocation times.

1. 2023-02-07 Community commenter — Created the bug and described how CRL/OCSP revocation timestamps could diverge due to different database fields, including investigation results and the decision to continue serving incorrect CRL times temporarily.
2. 2023-02-07 Community commenter — Noted a formatting correction for the incident report sub-points.
3. 2023-02-14 Community commenter — Reported that the hotfix was implemented, tested, and deployed, and that the listed certificates now show matching revocation times on CRL and OCSP.
4. 2023-04-13 Mozilla representative — Indicated intent to close the bug on or about 19-Apr-2023 if no further concerns were raised.