Closed Bug 1600158 Opened 3 years ago Closed 3 years ago

Asseco DS / Certum: Failure to revoke intermediate certificates within the BR time period


(CA Program :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: wtrapczynski, Assigned: wtrapczynski)


(Whiteboard: [ca-compliance] [ca-revocation-delay])

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

Steps to reproduce:

This incident report is connected to

Asseco DS / Certum: Failure to revoke intermediate certificates within the BR time period

This incident report is related to

  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, a Bugzilla bug, or internal self-audit), and the time and date.

We became fully aware of this problem from the discussion on m.d.s.p.!topic/ on November 21st. All affected certificates have been revoked on November 26th, 2019 so within 7 days required by BR counting from November 21st.

Nonetheless, the first post about potentially BR non-compliant certificates has been published by Mozilla on October 8th and we believe that lack of our insightful verification of the ALV test results could not excuse for postponing the revocations. Therefore, we decided to treat it as a BR violation and that why we created this Bug.

  1. 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.

08.10.2019 20:50 UTC – Mozilla informed on m.d.s.p.!topic/ that there is now an "Audit Letter Validation (ALV)" button on intermediate certificate records in the CCADB. We saw this information but we mistakenly assumed that the ALV test for our certificates has failed because of invalid format (spaces and lowercase letters) of SHA-256 Fingerprints we have in current audits statements. Then, we did not perform an insightful verification.
21.11.2019 15:00 UTC – As the discussion on m.d.s.p. was continuing we decided to perform a detailed inspection.
22.11.2019 13:00 UTC – We finished a review of all the affected certificates. We identified and prepared a description of all of these certificates.
26.11.2019 17:00 UTC – We finished an analysis of the impact of revocation of these certificates. We decided to revoke 15 certificates.
27.11.2019 13:00 UTC – We revoked 15 certificates.

  1. 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.

This incident concerns certificates that were issued between 2008 and 2014. All our remain certificates listed in CCADB are included in our current audit reports so they do not require to be revoked.

  1. 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.

All affected certificates were used by Certum many years ago for issuing SHA1 SSL, S/MIME, and Code Signing. The first certificate was issued in 2008, and the last one in 2014. There are no valid end-entity certs issued by these issuers.

  1. 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 IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We are aware that the main reason for failure to timely revocation was lack of deep analysis after the first Mozilla post on m.d.s.p. on October 8th.

  1. 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.

At Certum we have Compliance Team engage with the watching and collecting the changes related to the CA/Browser Forum, browsers, and other software vendors' policies. We meet at least once every two weeks to analyze all changes related to the Web PKI ecosystem which we as the Certification Authority should follow up to be fully compliant with them.

To date, our meetings had no strictly defined agenda. After internal discussion, we indicated it as a place for the potential of missing something. Therefore, we decided to write down a list of all topics (including regular review of CCADB cases) we should discuss on a regular basis and we created a detailed agenda for our meetings. We believe that this step will help us manage all it even better and allows us to avoids such non-compliances issues in the future.

We also decided to assign the owners to each topic we should follow. As a result of this, we have are clearly defined responsibilities for every area. We believe that this move will improve our ability to respond faster to changes.

Assignee: wthayer → wtrapczynski
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance]
Whiteboard: [ca-compliance] → [ca-compliance] [delayed-revocation-ca]

Wayne: I don't think I have any further questions here. I think this is a good proactive disclosure by Certum, and while not ideal that they missed the m.d.s.p. discussion (as required by Mozilla policy), better that they did revoke within 7 days of noticing.

Flags: needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

Closed: 3 years ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] [delayed-revocation-ca] → [ca-compliance] [ca-revocation-delay]
You need to log in before you can comment on or make changes to this bug.