E-Tugra: Insufficient serial number entropy

This case is a self-disclosure by E-Tugra about an issue involving insufficient serial number entropy in certificates. E-Tugra said it became aware of the problem through EJBCA 63-bit entropy problem reporting and internal monitoring after searching its certificates. E-Tugra investigated and increased the size of serial number fields, updating EJBCA settings to set the serial number length parameter to 16 bytes (128 bits) from 8 bytes. E-Tugra also reissued certificates that were not revoked or expired, then revoked existing certificates, stating that as of March 13 the reasons for the problem were fixed and no more certificates would be produced with these problems. In the thread, Mozilla participants asked why reporting was deferred for over one month; E-Tugra responded that it waited to complete revocation and re-control of its systems before posting the incident report. E-Tugra stated it would develop and update internal incident reporting procedures and risk analysis/audits to ensure more proactive notification, and later indicated that remediation was complete.

1. 2016-12-16 E-Tugra issued certificates later identified as affected by the serial number entropy problem (min issue date stated).
2. 2019-03-03 E-Tugra received an announcement from its CA software vendor (EJBCA) about the entropy problem.
3. 2019-03-04 E-Tugra investigated its systems and began fixes, including increasing serial number field sizes.
4. 2019-03-13 E-Tugra updated systems and set EJBCA serial number length to 16 bytes (128 bits) from 8 bytes, and began reissuing certificates.
5. 2019-03-14 E-Tugra completed updates and started reissuing certificates and revoking existing certificates.
6. 2019-04-05 E-Tugra posted the incident report in this bug after completing revocation and re-control.
7. 2019-05-01 E-Tugra reported completion of enhanced internal incident reporting procedures and risk/audit review.

1. 2019-04-05 E-Tugra — Opened the incident report describing insufficient serial number entropy, the timeline of investigation/fixes, reissuance and revocation, and provided a spreadsheet link for affected certificates.
2. 2019-04-06 Fastly representative — Asked why it took E-Tugra over one month to report the incident.
3. 2019-04-08 E-Tugra — Explained the delay by stating E-Tugra waited to complete revocation and re-control of its systems before posting the incident report.
4. 2019-04-08 Community commenter — Asked for more detail on deferring reporting until revocation was complete and whether steps would be taken for more proactive notification.
5. 2019-04-09 E-Tugra — Acknowledged the reporting gap and stated it would develop internal incident reporting procedures and improve risk analysis/audits to avoid delays and misunderstandings.
6. 2019-04-10 Fastly representative — Requested an update to the bug once the actions described in comment #4 were completed.
7. 2019-04-30 Mozilla representative — Noted the priority flag was not set and asked for review.
8. 2019-04-30 Mozilla representative — Changed the bug type to Task so it would not be part of Mozilla's regular bug triage process.
9. 2019-05-01 E-Tugra — Reported that enhanced internal incident reporting procedures and risk/audit review were completed to enable more proactive notification.
10. 2019-05-01 Fastly representative — Indicated it appears remediation is complete.