Li-Chun: thank you for this incident report. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1532436 to track this issue.
On Fri, Mar 1, 2019 at 5:59 AM Jakob Bohm via dev-security-policy < [email protected]> wrote: > On 28/02/2019 17:48, [email protected] wrote: > > 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. > > > > Ans: > > One of our staffs in PKI group was taking samples of the issued > certificates from crt.sh database for some reasons and found a mis-issued > certificate which has a test (unregistered) FQDN on February 15, 2019 at > 1:55 (UTC). He then notified us (Public CA) of the incident. We decide to > make an initial investigation and found another mis-issued certificate > which also has a test FQDN on February 15, 2019 at 2:30 (UTC). > > > > 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. > > > > Ans: > > Timeline (all times are UTC): > > 15 February 2019 1:55: Find a mis-issued certificate with a FQDN > www.raotest.com.tw > > 15 February 2019 1:59: Revoke the first mis-issued certificate > > 15 February 2019 2:07: Public CA starts an action plan and initial > investigation > > 15 February 2019 2:17: Further certificate issuing suspended > > 15 February 2019 2:30: Find another mis-issued certificate with a FQDN > publicca.rao.com.tw > > 15 February 2019 4:10: Initial investigation completed > > 15 February 2019 4:25: Certificate issuing restarted > > 15 February 2019 4:40: Hold an investigation meeting > > > > 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. > > > > Ans: > > Yes, we had stopped issuing certificates before we investigated and > revoked any certificate with an unregistered FQDN. We have asked our CA > system vendor to include an automatic FQDN-checking function in the hotfix > which will be released not after 30 March 2019 to avoid making the same > mistakes. > > > > 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. > > > > Ans: > > Number of certs: 2 > > First cert: issued on Nov 12, 2018 at 11:53:02 (UTC) > > Last cert: issued on Jan 29, 2019 at 06:43:59 (UTC) > > > > 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. > > > > Ans: > > https://crt.sh/?id=1153958924 with FQDN www.raotest.com.tw > > https://crt.sh/?id=940459864 with FQDN publicca.rao.com.tw > > > > 6. Explanation about how and why the mistakes were made or bugs > introduced, and how they avoided detection until now. > > > > Ans: > > For the certificate with FQDN www.raotest.com.tw: > > One of our RAOs intended to take a screenshot of certificate application > process for training material in test environment, but she was not aware > that she is in the formal environment. After the certificate was issued, > the RAO forgot to revoke it. > > > > For the certificate with FQDN publicca.rao.com.tw: > > The same as the former cause, but the mis-issued certificate had been > revoked immediately without notifying Public CA. > > > > The mistakes have not been detected (even by our internal self-audit) > because the amount of mis-issued certificates is minor. The RAO involved in > this incident has been verbally warned and needs to undergo a retraining > process in accordance with our employment contract. > > > > 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. > > > > Ans: > > To avoid making the same mistakes, the following steps will newly be > introduced: > > > > Step 1. Implementation of a two-stage manual verification by different > RAOs. Effective 26/02/2019. > > > > Step 2. Implementation of an automatic FQDN-checking function prior to > issuing certificates. Effective 30/03/2019. > > > > Step 3. Implementation of a scheduling program to periodically and > automatically check the newly-issued certificates from our repository. > Effective 30/05/2019. > > > > > > How come your Public CA wasn't routinely using the blessed automatic > methods listed in the BRs? Manual domain ownership or control > validation is supposed to be an exception, not the routine standard > procedure for a general public CA (a private Sub-CA technically > constrained by the parent CA to only issue for domains already > validated as belonging to the Sub-CA owner may rely exclusively on > their internal processes to authorize certificates for any FQDNs > under their own domains, because a public CA can legitimately > validate the customer higher level domain control to issue for FQDNs > under the validated domain). > > FQDN existence is not a requirement, only validation that the > certificate applicant has the authority to create and change that > FQDN at will. For example, automated validation that raotest.com.tw is > a registered domain fully controlled by the applicant would be enough > to give that applicant a certificate for www.raotest.com.tw, even > before that applicant creates www.raotest.com.tw. Some applicants > may even prefer to obtain certificates before making their FQDN live. > > Of cause the fact that a registry such as the one for .com.tw can > create any non-existent domain does not count, because such domains > would generally belong to a 3rd party. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
