Closed Bug 1542302 Opened 6 months ago Closed 5 months ago

E-Tugra: Insufficient serial number entropy

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dtokgoz, Assigned: dtokgoz)

Details

(Whiteboard: [ca-compliance] - Next Update)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

Steps to reproduce:

1 How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
E-Tugra:
• We were aware of the problem from both EJBCA 63 bit Entropy bit problem reporting in community and internal monitoring after searching our certificates for this entropy problem

2 A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
E-Tugra:

  • March 3; We get an announcement from EJBCA that is our CA software vendor
  • March 4,5; We investigate our system and started the fixing other software’s that uses CA data such as RA systems. The size serial number fields were increased.
  • March 13,14; All software’s are updated and the serial number length parameter in CA (EJBCA) is set to 16 bytes (128 bits) from 8 bytes
  • March 14; We started tı reissue all certificates that are not revoked before or not expired. After reissuing and delivering to the owners new certificates. All existing certificates were revoked.

3 Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
E-Tugra:
• As of March 13, the reasons of the problems are fixed. No more certificates will be produced with these problems.

4 A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
E-Tugra:
14 certificates affected from this problem. All of them were revoked or is being revoked. Min and Max issue Dates: 2016.12.16 15:35 - 2019.03.12 23:21

5 The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
E-Tugra:
An Excel spreadsheet was prepared. https://www.e-tugra.com.tr/portals/6/download/report/CertificatesWith63Entropy.xlsx

6 Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
E-Tugra:
We didn't detect the issue with the linting tools. Cablint does not discover the problem. We realized that only zlint gives this problem as a warning.
7 List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
E-Tugra
All Actions are taken. All certificates were revoked and CA settings in EJBCA was fixed.

Davut: thank you for this incident report. In addition, please explain why it took E-Tugra over one month to report this incident?

Assignee: wthayer → dtokgoz
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(dtokgoz)
Summary: E-Tugra: 63 bit serial number entropy → E-Tugra: Insufficient serial number entropy
Whiteboard: [ca-compliance]

Hi
We waited to complete all revocation process and all re-control of the our system again before posting the incident report.

Flags: needinfo?(dtokgoz)

Given that many CAs responded to this incident proactively, as is standard practice for the past years and captured in https://wiki.mozilla.org/CA/Responding_To_An_Incident - could you explain more about why the decision was made to defer until revocation was complete?

Will steps be taken to ensure more proactive notification - e.g. the moment the issue is reported?

Based on the timeline provided, the steps were completed by March 14. That doesn't explain why it took until April 5 to report.

Flags: needinfo?(dtokgoz)

Hi
We accept that the gap between date that the solution found and implemented and that date that was reported is not negligible. After March 14th, we recontroled our systems many times with more checks. This was the first incident report that was created with self-decision. We wanted to be sure we completed all the needed tasks and actions are completed after many check. But, we understood that we happened to misunderstand the expectations, so that we couldn't send to report in time.
To ensure more proactive notification to Mozilla and other root programs, we will develop our internal incident reporting procedures and instructions completely covering Mozilla and other root programs expectations within this month. New revised procedures will cover creating and updating incident reports as expected format within times that’s expected by Mozilla. We will also review and extend our risk analysis and risk management and internal audits details to avoid this kind of delays and misunderstandings.

Flags: needinfo?(dtokgoz)

Davut: Please update this bug when the actions described in comment #4 have been completed.

Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-May 2019

The priority flag is not set for this bug.
:kwilson, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(kwilson)

(In reply to Release mgmt bot [:sylvestre / :calixte] from comment #6)

The priority flag is not set for this bug.
:kwilson, could you have a look please?

For more information, please visit auto_nag documentation.

Changed the bug type to Task, so it will not be part of Mozilla's regular bug triage process.

Type: defect → task
Flags: needinfo?(kwilson)

As we noted in "comment 4"; at the end of March, we completed to enhance our internal incident reporting procedures covering Mozilla and other root programs expectations. Updated procedures cover creating and updating incident reports as expected format within times that’s expected by Mozilla. As we planned we reviewed risk analysis and internal audits details to avoid this kind of delays and misunderstandings. With these, we ensure that we will be more proactive notification to Mozilla and other root programs.

It appears that remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next Update - 01-May 2019 → [ca-compliance] - Next Update
You need to log in before you can comment on or make changes to this bug.