Asseco DS / Certum: Non-BR-Compliant Issuance - Debian Weak Keys
The case concerns two certificates issued by Certum that contained Debian weak keys. The issue was reported to Certum on 3-Feb-2018, and the CA stated that the BRs require such certificates to be revoked within 24 hours for key compromise, but they were not revoked as of 5-Feb-2018. Certum investigated the reported problem, confirmed that both affected certificates needed revocation, and revoked both certificates with revocation reason "Key Compromise" and invalidity date 03-Feb-2018. Certum also scanned its certificates database and reported that no additional active certificates with vulnerable keys were found. Certum identified the cause as incorrect calculation of the SHA1 fingerprint of the public key due to differences in how hashes were stored versus how CSR public key values were calculated, and it deployed a corrected weak-keys validation system on 8-Feb-2018 so that certification requests based on Debian weak keys would be rejected. The bug was marked RESOLVED with resolution FIXED after Certum provided an incident report and responded to questions about prevention; the reporter accepted a follow-up reminder about testing the full system.
- Certum received a report requesting revocation of two certificates containing Debian weak keys.
- Certum had not yet revoked the reported certificates as of this date.
- Certum revoked the two affected certificates and scanned its certificate database for weak keys.
- Certum deployed an updated weak-keys validation system to reject certification requests based on Debian weak keys.
- Fastly representative — Requested an incident report because two reported certificates with Debian weak keys had not been revoked as required within 24 hours.
- Fastly representative — Asked Certum to scan every active (non-expired, non-revoked) certificate issued for the reported problem.
- Assecods representative — Reported that Certum confirmed both certificates must be revoked, revoked them with reason "Key Compromise," scanned for additional weak keys, and stated it was treating the issue as a security incident.
- Asseco Data Systems S.A. — Stated the cause of incorrect weak-key validation was found, the fix was deployed on Feb 8, and a rescan found no other active vulnerable certificates.
- Mozilla representative — Changed QA contact per a referenced Bugzilla bug.
- Assecods representative — Provided the incident report including timeline, root cause (incorrect SHA1 fingerprint calculation), and steps to resolve and prevent recurrence.
- Fastly representative — Asked for more detail on how similar problems would be prevented and requested posting the incident report to the mozilla.dev.security.policy forum.
- Assecods representative — Explained that weak-keys verification tests were run, but the weak-keys database used for tests contained hashes in incorrect formats, leading to false positives.
- Fastly representative — Marked the bug resolved after a reminder about testing the full system even when unit tests pass.