- 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 aware of the issue on 2018-07-18, 17:11 HKT (09:11 UTC) after following a topic discussion in mozilla.dev.security.policy.
- 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.
2018-07-16, 17:01 HKT (09:01 UTC) On a regular review of discussions in mozilla.dev.security.policy, we became aware that a number of interoperability concerns were raised for certificate with length of OU more than 64 chars https://crt.sh/?id=336874396 .
2018-07-17, 09:30 HKT (01:30 UTC) We searched in our CA database for certificates with similar problems and double checked against that in crt.sh (X.509 lint).
2018-07-18, 17:11 HKT (09:11 UTC) A total 18 problematic certificates of 8 organisations were identified to have the same problem. The OU field contains either the organisation name or the organisation branch name, that could be longer than 64 chars.
2018-07-26, 10:40 HKT (02:40 UTC) Each subscriber was notified of the problem, and suggested a shorten organisation name or organisation branch name for confirmation.
2018-08-24, 17:00 HKT (08:00 UTC) It is confirmed that all subscribers had replaced their certificates for servers, and revoked their problematic 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.
We had stopped immediately issuing certificates with the problem by operational controls since we became aware of the problem. Our CA system was then fixed in Sep 2018 to disallow organization name or organization branch name being longer than 64 chars.
- 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.
A total 18 problematic certificates of 8 organisations were identified. The first certificate was issued on 13 Feb 2017, and the last certificate was issued 19 June 2018.
- 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.
For details, please refer to:-
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Our CA system uses subscribers' full organisation name and branch name in the Subject OU field of SSL certificate (“e-Cert (Server)”) to identify the subscriber organisation, and the full organisation name and branch name, as appeared in their government record of Business Registration certificates, could be longer than 64 characters respectively. However, the CA system didn’t validate the length of OU field must be less than or equal to 64 chars. Only a small number of certificates had this problem and we had not received any report of problem from any internet user or the subscriber. Therefore, they are not detected until now.
- 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.
The CA system had been fixed on 12 Sep 2018 to disallow organization name or organization branch name being longer than 64 chars. Moreover, we had adopted a name abbreviation rule for long organisation name and branch name so that all names remain meaningful using commonly understood semantics to determine the identity of the subscriber.
During this incident was discovered, we had to maintain communication with the affected subscribers and support them for replacement of their certificates without interruption to their services. While control has been put in place on the system side since Sep 2018 to safeguard against future recurrence of the case, we are keep communicating with our subscribers and potential subscribers advising them of the requirements and its importance. I wish that I could have filed this incident report earlier or at least sought some advice from Mozilla community, but certainly I cannot be excused for my negligence in not timely filing this report.