- 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.
This was first reported to Microsoft by DigiCert at 02:36 pm Pacific time on Wednesday, 2021-03-24 via email informing us that two of our new Issuing CAs were reported in the “Unconstrained Trust: Disclosure is required!” report: https://crt.sh/mozilla-disclosures.
- 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.
Note: Times are listed in Pacific time zone
• 24 March 2021 02:36 PM – Issue reported by DigiCert as an email
• 24 March 2021 02:39 PM – Internal investigation started
• 24 March 2021 03:30 PM – Confirmed that this is related to a recent deployment of new Issuing CAs
• 24 March 2021 05:15 PM – CCADB updated with the 8 newly created CA certificates (attached to this bug)
- 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.
No subscriber certificates have been issued and there are no plans to issue subscriber certificates until an audit seal has been obtained. However, we have issued OCSP and Sample Certs off of the Microsoft RSA TLS Issuing AOC CA 01 and Microsoft ECC TLS Issuing CA 01. This was a process problem for a new Issuing CA certificate and we did not meet the disclosure timeline requirement from Section 5.3.2 of the Mozilla Root Store Policy. These 8 CA's were created on March 11 and added to CCADB on March 24 (13 days).
- 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.
The 8 new TLS issuing CA's are all attached to this bug.
Two of them are in CRT.SH already:
The Other 6 are:
- 03/11/2021 Microsoft RSA TLS Issuing AOC CA 02 563c935011b3aa7638da69817a964245f8a6ba7c
- 03/11/2021 Microsoft RSA TLS Issuing EOC CA 01 0ee6aa1f759e18509f1edd02da49f1f212cbf8b2
- 03/11/2021 Microsoft RSA TLS Issuing EOC CA 02 a922d91efa12a71b7aeddb9665e80da6f846d875
- 03/11/2021 Microsoft ECC TLS Issuing AOC CA 02 f1cb1990f32697e1e90cb05975224ba78f191132
- 03/11/2021 Microsoft ECC TLS Issuing EOC CA 01 aec01b8bf645cad77f3be39ad1f01d928d52ceb8
- 03/11/2021 Microsoft ECC TLS Issuing EOC CA 02 f9593f17cade86c383e92ba9f38302018bf26724
- 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.
See above and or attached for the list of new Issuing CA details.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
This was a process issue. It was the first time that we have deployed new Issuing CAs since being added to the Mozilla root programs and we mistakenly had the disclosure task set later in the project, which didn’t allow us to meet the 7 day disclosure requirement.
- 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 have been unable to determine an automated way to solve this problem. We have updated our ceremony documentation and moved the CCADB update (disclosure) immediately after the key generation ceremony with a note that it must be updated within 7 days.