- 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.
We became fully aware of this problem from a discussion on m.d.s.p. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI on November 21th, 2019.
- 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. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI 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 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:51 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 (see point 4 this Incident Report).
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 12:00 UTC – We revoked 15 certificates.
27.11.2019 18:00 UTC – We added an appropriate comment in CCADB for the other 3 certificates.
- 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 active certificates are included in our current audit reports.
- 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.
We have 18 certificates with ALV test failed but we believe that 15 certificates should be considered as non-compliance.
The details explanation of each certificate (Common Name and SHA256 Fingerprints). We may divide them into several groups:
(1) Cross certificates with different Audit Information than all Certum’s CA certificates. SHA256 Fingerprints of these certificates are included in Certum’s audit statements but according to this Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1567062 we have changed the Audit Information section in CCADB and we have pointed out subject audit statements (SSL.com). I have added an appropriate comment in CCADB. In total, 2 certificates.
SSL.com Root Certification Authority RSA
SSL.com EV Root Certification Authority RSA R2
(2) Invalid Self-signed root. Note from CCADB for this certificate: “This is the first version of the certificate which had been submitted to Mozilla but the submission was rejected because this root certificate has a 21-byte serial number - not compliance with RFC 5280. See https://bugzilla.mozilla.org/show_bug.cgi?id=99937. Since different versions of the same root cert have the same Issuer Name and are both signed by the same key, they both chain to each other. Therefore, the not-included self-signed root must also be disclosed to Salesforce as an intermediate cert.” I have added an appropriate comment in CCADB. In total, 1 certificate.
Certum Trusted Network CA 2
(3) Old Certum CA certificates that we do not use anymore. All of these certificates were used for issuing SHA1 SSL, S/MIME, and Code Signing. There are no valid end entity certs issued by these certificates. We have revoked them all. In total, 15 certificates.
Certum Partners CA
Certum Class I CA
Certum Global Services CA
Certum Level II CA
Certum Level I CA
Certum Level III CA
Certum Level IV CA
Certum Trusted Network CA
Certum Extended Validation CA
- 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.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
As we no longer use these 15 certificates in production and there are no valid end-entity certificates issued by these certificates we did not include them in audit scope.
- 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.
We revoked all 15 certificates not listed in current audit reports.
For all certificates that should be in audit scope, we follow the earlier established procedure to be sure that any certificate will not be omitted in audit statements.
We will create another Bugzilla Bug to explain the lack of timely revocation no later than December 2, 2019.