Re: Public CA:certs with unregistered FQDN mis-issuance
lcche...@gmail.com於 2019年3月1日星期五 UTC+8上午12時48分27秒寫道： > 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. > The scheduling program that can periodically and automatically check the newly-issued certificates from our repository has been implemented on May 6th. To avoid the same problem happened in those previously-issued certificates, we scanned the whole repository and found that some FQDNs in the issued certificates are inaccurate due to a change to domain’s ownership, or a relevant licensing or services agreement between the Domain Name Registrar and our customers has terminated. For the former case, we have revoked the certs immediately according to the provisions in Section 4.9.1 of our CP/CPS. For the latter case, we have asked our customers who still want to have the certificate to renew their certificates; otherwise, we will revoke these certs within 5 days according to the provisions in Section 4.9.1 of our CP/CPS. Li-Chun Chen Chunghwa Telecom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public CA:certs with unregistered FQDN mis-issuance
lcche...@gmail.com於 2019年3月1日星期五 UTC+8上午12時48分27秒寫道： > > 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. > The automatic FQDN-checking function has been implemented and enforced in Public CA on March 15. The issuance of any cert with unregistered FQDN can no longer be carried out now. Thank you. Li-Chun ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public CA:certs with unregistered FQDN mis-issuance
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 < dev-security-policy@lists.mozilla.org> wrote: > On 28/02/2019 17:48, lcchen.ci...@gmail.com 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 > method
Re: Public CA:certs with unregistered FQDN mis-issuance
On 28/02/2019 17:48, lcchen.ci...@gmail.com 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 i
Public CA:certs with unregistered FQDN mis-issuance
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. Sincerely Yours, Li-Chun Chen Chunghwa Telecom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
