Re: Public CA:certs with unregistered FQDN mis-issuance

2019-05-31 Thread lcchen.cissp--- via dev-security-policy
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

2019-03-30 Thread lcchen.cissp--- via dev-security-policy
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

2019-03-04 Thread Wayne Thayer via dev-security-policy
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

2019-03-01 Thread Jakob Bohm via dev-security-policy

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

2019-02-28 Thread lcchen.cissp--- via dev-security-policy
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