Closed Bug 1391068 Opened 2 years ago Closed 9 months ago

Taiwan-CA: Non-BR-Compliant Certificate Issuance

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: robin.lin)

References

Details

(Whiteboard: [ca-compliance])

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) 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.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ
We are working on this issue:
1. Inform our customer to replace the certificate then revoke the miss-issued certificate.
2. Scan our certificate database again to find the miss-issued certificate. This had been done and found no other miss-issued certificate.
3. Review our verification function of RA/CA system to find the causes of this miss-issued event.
We have revoked the miss-issued certificate and published the revoke information to CRL and OCSP.

Thanks for the notification.
Thanks for responding. I think it's still necessary to provide additional detail.

That is, we can look at the problem from two dimensions: The problem itself, and the systemic issues that allowed the problem to manifest. Your description focuses on the resolution of the problem, but doesn't indicate any systemic changes have been made. As a consequence, it does not help the community feel that your CA has taken steps to reduce the risk of future violations (of any requirement) in the future. That is, one dimension is "Did you fix the bug", but another dimension is "How was the bug introduced, why was it not detected, and what steps are you taking to prevent future bugs"

To understand how you might approach this problem, consider https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were already in place (and with substantial detail), where there were controls missing or mistakes made, details about the steps being taken (e.g. "We fixed the bug" is not sufficient detail to understand), and a holistic, systemic awareness of how the CA is managed and the opportunities for errors.


For this specific case:
---
- Why was such a certificate issued?
- What controls exist to prevent such certificates issued?
- When was the timeline of implementation and deployment of those controls?
- What controls, if any, failed?
- If no controls failed, what controls have been introduced to prevent future issues?
- If no controls have been introduced, why not?
- Systemically, what steps does your CA have in place to ensure compliance with the Baseline Requirements?
- Were those procedures followed? Why or why not?
- What changes have been made to your procedures to ensure future changes to the Mozilla Policy or the Baseline Requirements are implemented in the necessary time?
I emailed a problem report about this certificate, can you please investigate and explain why it was not received?

Here are the relevant message headers:

  From: Jonathan Rudenberg <jonathan@titanous.com>
  Subject: Misissuance - invalid dnsNames 
  Message-Id: <63D4CDC4-3A8B-4821-93C7-F55B09F1F206@titanous.com>
  Date: Sun, 13 Aug 2017 00:40:38 -0400
  To: ca@twca.com.tw
(In reply to Jonathan Rudenberg from comment #4)
> I emailed a problem report about this certificate, can you please
> investigate and explain why it was not received?
> 
> Here are the relevant message headers:
> 
>   From: Jonathan Rudenberg <jonathan@titanous.com>
>   Subject: Misissuance - invalid dnsNames 
>   Message-Id: <63D4CDC4-3A8B-4821-93C7-F55B09F1F206@titanous.com>
>   Date: Sun, 13 Aug 2017 00:40:38 -0400
>   To: ca@twca.com.tw

We reviewed our mailbox setting and found there was only one person to watch "ca@twca.com.tw" mailbox with single user account, and the person did not forward the notification to related people.

To avoid missing the any problem report or any incident message, we re-configure the mailbox as a mailing list, which include CA system administrator, internal auditor and I.

This situation should not happened again.

Thanks and Regards,
(In reply to Ryan Sleevi from comment #3)
> Thanks for responding. I think it's still necessary to provide additional
> detail.
> 
> That is, we can look at the problem from two dimensions: The problem itself,
> and the systemic issues that allowed the problem to manifest. Your
> description focuses on the resolution of the problem, but doesn't indicate
> any systemic changes have been made. As a consequence, it does not help the
> community feel that your CA has taken steps to reduce the risk of future
> violations (of any requirement) in the future. That is, one dimension is
> "Did you fix the bug", but another dimension is "How was the bug introduced,
> why was it not detected, and what steps are you taking to prevent future
> bugs"
> 
> To understand how you might approach this problem, consider
> https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/
> W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were
> already in place (and with substantial detail), where there were controls
> missing or mistakes made, details about the steps being taken (e.g. "We
> fixed the bug" is not sufficient detail to understand), and a holistic,
> systemic awareness of how the CA is managed and the opportunities for errors.
> 
> 
> For this specific case:
> ---
> - Why was such a certificate issued?
> - What controls exist to prevent such certificates issued?
> - When was the timeline of implementation and deployment of those controls?
> - What controls, if any, failed?
> - If no controls failed, what controls have been introduced to prevent
> future issues?
> - If no controls have been introduced, why not?
> - Systemically, what steps does your CA have in place to ensure compliance
> with the Baseline Requirements?
> - Were those procedures followed? Why or why not?
> - What changes have been made to your procedures to ensure future changes to
> the Mozilla Policy or the Baseline Requirements are implemented in the
> necessary time?

We investigate this miss-issued event yesterday and found some problem with our current control. I will answered the question here.

> - Why was such a certificate issued?
1. We reviewed all domain names on the issued certificate and found only one certificate was miss-issued. Our OV certificate was verified manually, the verification process will be logged to RA system database as an operation record. We reviewed the record and sure there was someone approved the certificate issuance without proper verification.

> - What controls exist to prevent such certificates issued?
2. Every domain name must be verified the ownership before the certificate issuance. Currently, our RA operator verify domain name manually using WHOIS querying service provide by TWNIC or other Domain name service provider.
If the ownership of domain name could not be verified, the certificate should not be issued.

> - When was the timeline of implementation and deployment of those controls?
3. We use this control start from the time that we start SSL certificate business for about 17 years ago (start from year 2000).

> - What controls, if any, failed?
4. The control failed because that we relied the people to follow the SOP only. The internal auditor also did not find the reserved domain name was listed on the certificate. The auditor sampling the 20% certificate data to check, the miss-issued certificate was not included in the sampling data.

The operator do some mistake, the missed issued occurred and did not find by auditor reviewed.

> - If no controls failed, what controls have been introduced to prevent
> future issues?
5. Currently, we have system control to prevent the issuance of high ranking/risk domain to avoid issuing the certificate, such as google, Facebook or other domain name.
We plan to modify the system checking function to check the certificate issuing request with high risk, gTLD and reserved domain name, once the prohibited domain name was detected, the system will reject the issuing request.

In addition, we will establish the monitor function to watch the certificate database, scan the DNS name on the certificate, check to see if there is any prohibited domain name was listed on the certificate.

We also will change our internal audit procedure to add the review point on effectiveness of this control. The internal auditor will review the system process log every 3 months to ensure the control has operated properly.

> - If no controls have been introduced, why not?
Same as 5. We plan to change our system to avoid the same problem.

> - Systemically, what steps does your CA have in place to ensure compliance
> with the Baseline Requirements?
Same as 5. 

> - Were those procedures followed? Why or why not?
Same as 5.

> - What changes have been made to your procedures to ensure future changes to
> the Mozilla Policy or the Baseline Requirements are implemented in the
> necessary time?
6. We will use automatic checking function in CA/RA software to avoid the manual process error. We will introduce a working group to watch the policy change of Mozilla CA policy and CABForum BR and EV guideline, review our compliance status with policy change in the future.

Above are our answer to this miss-issued event and future work plan to keep compliance with Baseline Requirement. If you need more information please let me know.

Thanks and Regards,
Robin Lin
(In reply to Robin Lin from comment #6)
> > - What controls exist to prevent such certificates issued?
> 2. Every domain name must be verified the ownership before the certificate
> issuance. Currently, our RA operator verify domain name manually using WHOIS
> querying service provide by TWNIC or other Domain name service provider.
> If the ownership of domain name could not be verified, the certificate
> should not be issued.

Based on your description, it sounds like you are relying on manual verification. A number of CAs are able to successfully automate WHOIS data, or there exist a variety of automated methods of domain verification (e.g. TXT records) that do not require this form of error-prone process.

1) Have you considered using/supporting additional methods per Section 3.2.2.4 of the Baseline Requirements?
2) Do you have systems and controls in place to ensure that the domain names properly adhere to RFC5280's requirements (and the Baseline Requirements)? This includes, but is not limited to:
  - Ensuring domains observe the LDH rule of Section 3.5 of RFC 1034, and as modified by Section 2.1 of RFC1123, as documented in Section 4.2.1.6 of RFC 5280?
  - Ensuring domains properly observe the IDNA syntax and semantics, as documented in Section 7.2 of RFC 5280?
  - Ensuring that, by 8 September 2017, you've fully documented your CAA processing semantics (as per Section 2.2 of the Baseline Requirements) and you've implemented a system to check and process such records (as per Section 3.2.2.8 of the Baseline Requirements)?

> > - If no controls failed, what controls have been introduced to prevent
> > future issues?
> 5. Currently, we have system control to prevent the issuance of high
> ranking/risk domain to avoid issuing the certificate, such as google,
> Facebook or other domain name.
> We plan to modify the system checking function to check the certificate
> issuing request with high risk, gTLD and reserved domain name, once the
> prohibited domain name was detected, the system will reject the issuing
> request.

It sounds like you relied solely on policy to ensure technical compliance with RFC 5280. This suggests that there may be further risks in issuance, for things which might otherwise involve technical controls.

In addition to this proposed change, which is limited to this specific issue, have you considered integrating a holistic check over the tbsCertificate, before it is signed, to ensure all technically detectable non-compliance issues have been identified and prevent issuance? In addition to the aforementioned PKIoverheid, at least one other CA has integrated such changes ( https://groups.google.com/d/msg/mozilla.dev.security.policy/oTQ9OYgS8D4/KRFUWERDAgAJ )

> In addition, we will establish the monitor function to watch the certificate
> database, scan the DNS name on the certificate, check to see if there is any
> prohibited domain name was listed on the certificate.

As per the above, if you are scanning after issuance, then that is misissuance, and each detected certificate should be reported to both your auditors and to root stores as non-compliance. If you are detecting before you've signed such a certificate, however, then that is both accepted and expected.


> > - Systemically, what steps does your CA have in place to ensure compliance
> > with the Baseline Requirements?
> Same as 5. 

Based on the answer in 5, it appears your CA does not have a robust system in place to ensure compliance with the Baseline Requirements, largely relying on human factors. This has been repeatedly shown to be error prone, so I would strongly suggest you consider further investment in this space to detect and prevent misissuance.



Overall, while these replies are quite concerning to the potential security posture of Taiwan-CA, and the potential for future misissuance (among a variety of axis), the Baseline Requirements do not require you to implement further controls, merely that failure to ensure them is misissuance. I would encourage Taiwan-CA to read the reports and responses of other CAs on the associated bugs of https://bugzilla.mozilla.org/show_bug.cgi?id=1029147 to understand other places in which manual controls may fail, the ways in which CAs are remedying these with automated controls, and approaches to security response.

I would further encourage that, as part of #3, Taiwan-CA fully examine its set of valid certificates and run them through the available compliance testing tools, and immediately report any non-compliant certificates identified. Should further issues be detected by the community, rather than by Taiwan-CA, that will further undermine confidence.
(In reply to Ryan Sleevi from comment #7)
> (In reply to Robin Lin from comment #6)
> > > - What controls exist to prevent such certificates issued?
> > 2. Every domain name must be verified the ownership before the certificate
> > issuance. Currently, our RA operator verify domain name manually using WHOIS
> > querying service provide by TWNIC or other Domain name service provider.
> > If the ownership of domain name could not be verified, the certificate
> > should not be issued.
> 
> Based on your description, it sounds like you are relying on manual
> verification. A number of CAs are able to successfully automate WHOIS data,
> or there exist a variety of automated methods of domain verification (e.g.
> TXT records) that do not require this form of error-prone process.
> 
> 1) Have you considered using/supporting additional methods per Section
> 3.2.2.4 of the Baseline Requirements?
> 2) Do you have systems and controls in place to ensure that the domain names
> properly adhere to RFC5280's requirements (and the Baseline Requirements)?
> This includes, but is not limited to:
>   - Ensuring domains observe the LDH rule of Section 3.5 of RFC 1034, and as
> modified by Section 2.1 of RFC1123, as documented in Section 4.2.1.6 of RFC
> 5280?
>   - Ensuring domains properly observe the IDNA syntax and semantics, as
> documented in Section 7.2 of RFC 5280?
>   - Ensuring that, by 8 September 2017, you've fully documented your CAA
> processing semantics (as per Section 2.2 of the Baseline Requirements) and
> you've implemented a system to check and process such records (as per
> Section 3.2.2.8 of the Baseline Requirements)?
> 
> > > - If no controls failed, what controls have been introduced to prevent
> > > future issues?
> > 5. Currently, we have system control to prevent the issuance of high
> > ranking/risk domain to avoid issuing the certificate, such as google,
> > Facebook or other domain name.
> > We plan to modify the system checking function to check the certificate
> > issuing request with high risk, gTLD and reserved domain name, once the
> > prohibited domain name was detected, the system will reject the issuing
> > request.
> 
> It sounds like you relied solely on policy to ensure technical compliance
> with RFC 5280. This suggests that there may be further risks in issuance,
> for things which might otherwise involve technical controls.
> 
> In addition to this proposed change, which is limited to this specific
> issue, have you considered integrating a holistic check over the
> tbsCertificate, before it is signed, to ensure all technically detectable
> non-compliance issues have been identified and prevent issuance? In addition
> to the aforementioned PKIoverheid, at least one other CA has integrated such
> changes (
> https://groups.google.com/d/msg/mozilla.dev.security.policy/oTQ9OYgS8D4/
> KRFUWERDAgAJ )
> 
> > In addition, we will establish the monitor function to watch the certificate
> > database, scan the DNS name on the certificate, check to see if there is any
> > prohibited domain name was listed on the certificate.
> 
> As per the above, if you are scanning after issuance, then that is
> misissuance, and each detected certificate should be reported to both your
> auditors and to root stores as non-compliance. If you are detecting before
> you've signed such a certificate, however, then that is both accepted and
> expected.
> 
> 
> > > - Systemically, what steps does your CA have in place to ensure compliance
> > > with the Baseline Requirements?
> > Same as 5. 
> 
> Based on the answer in 5, it appears your CA does not have a robust system
> in place to ensure compliance with the Baseline Requirements, largely
> relying on human factors. This has been repeatedly shown to be error prone,
> so I would strongly suggest you consider further investment in this space to
> detect and prevent misissuance.
> 
> 
> 
> Overall, while these replies are quite concerning to the potential security
> posture of Taiwan-CA, and the potential for future misissuance (among a
> variety of axis), the Baseline Requirements do not require you to implement
> further controls, merely that failure to ensure them is misissuance. I would
> encourage Taiwan-CA to read the reports and responses of other CAs on the
> associated bugs of https://bugzilla.mozilla.org/show_bug.cgi?id=1029147 to
> understand other places in which manual controls may fail, the ways in which
> CAs are remedying these with automated controls, and approaches to security
> response.
> 
> I would further encourage that, as part of #3, Taiwan-CA fully examine its
> set of valid certificates and run them through the available compliance
> testing tools, and immediately report any non-compliant certificates
> identified. Should further issues be detected by the community, rather than
> by Taiwan-CA, that will further undermine confidence.
Hi Ryan,

Thanks for the reply.

1. We have scheduled a plan to modified RA front end software to check domain name and CAA records to avoid the manual process fail. 

2. We also consider to use API to access https://crt.sh/linttbscert to check TBSCertificate to avoid the miss issue, or develop our own software to check BE compliance in case of the API no longer exist.

3. Enable TLS certificate issuing CA to log all certificates to CT log server.

After checked certificate database, there are 31,208 TLS certificates are valid, 1 was miss-issued certificate reported by Mozilla Security Group, no more miss-issued certificate was found.

I think the non-compliance event will be avoid after the system change.
(In reply to Robin Lin from comment #8)
> Hi Ryan,
> 
> Thanks for the reply.
> 
> 1. We have scheduled a plan to modified RA front end software to check
> domain name and CAA records to avoid the manual process fail. 

Can you indicate when this is scheduled/

> 2. We also consider to use API to access https://crt.sh/linttbscert to check
> TBSCertificate to avoid the miss issue, or develop our own software to check
> BE compliance in case of the API no longer exist.

Can you indicate if/when this is scheduled?

> 
> 3. Enable TLS certificate issuing CA to log all certificates to CT log
> server.

Can you indicate if/when this is scheduled?
Flags: needinfo?(robin.lin)
Hello Ryan,

About your question"
1. Can you indicate when this is scheduled/
We have complete the SSL RA software modification. The testing and verification process are under going. We will change our production server in December of this year.

2. Can you indicate if/when this is scheduled?
About the integration with https://crt.sh/linttbscert API, we have to modify our certificate issuing software. We plan to modify the code in the 4th quarter of this year and change the production system to new version in the 1st quarter of 2018.

3. Can you indicate if/when this is scheduled?
About the turn on the CT logging function in OV SSL certificate issuing system, we plan to enable in 1st quarter of 2018 to make sure the compliance with Chrome browser.

Thanks,
Robin Lin

(In reply to Ryan Sleevi from comment #9)
> (In reply to Robin Lin from comment #8)
> > Hi Ryan,
> > 
> > Thanks for the reply.
> > 
> > 1. We have scheduled a plan to modified RA front end software to check
> > domain name and CAA records to avoid the manual process fail. 
> 
> Can you indicate when this is scheduled/
> 
> > 2. We also consider to use API to access https://crt.sh/linttbscert to check
> > TBSCertificate to avoid the miss issue, or develop our own software to check
> > BE compliance in case of the API no longer exist.
> 
> Can you indicate if/when this is scheduled?
> 
> > 
> > 3. Enable TLS certificate issuing CA to log all certificates to CT log
> > server.
> 
> Can you indicate if/when this is scheduled?
Flags: needinfo?(robin.lin)
(In reply to Robin Lin from comment #10)
> Hello Ryan,
> 
> About your question"
> 1. Can you indicate when this is scheduled/
> We have complete the SSL RA software modification. The testing and
> verification process are under going. We will change our production server
> in December of this year.
> 
> 2. Can you indicate if/when this is scheduled?
> About the integration with https://crt.sh/linttbscert API, we have to modify
> our certificate issuing software. We plan to modify the code in the 4th
> quarter of this year and change the production system to new version in the
> 1st quarter of 2018.
> 
> 3. Can you indicate if/when this is scheduled?
> About the turn on the CT logging function in OV SSL certificate issuing
> system, we plan to enable in 1st quarter of 2018 to make sure the compliance
> with Chrome browser.
> 
> Thanks,
> Robin Lin
> 
> (In reply to Ryan Sleevi from comment #9)
> > (In reply to Robin Lin from comment #8)
> > > Hi Ryan,
> > > 
> > > Thanks for the reply.
> > > 
> > > 1. We have scheduled a plan to modified RA front end software to check
> > > domain name and CAA records to avoid the manual process fail. 
> > 
> > Can you indicate when this is scheduled/
> > 
> > > 2. We also consider to use API to access https://crt.sh/linttbscert to check
> > > TBSCertificate to avoid the miss issue, or develop our own software to check
> > > BE compliance in case of the API no longer exist.
> > 
> > Can you indicate if/when this is scheduled?
> > 
> > > 
> > > 3. Enable TLS certificate issuing CA to log all certificates to CT log
> > > server.
> > 
> > Can you indicate if/when this is scheduled?

Robin: will you please provide an update on these action items?
Flags: needinfo?(robin.lin)
(In reply to Wayne Thayer [:wayne] from comment #11)
1. Our RA had go production with CAA records check on January 31.
2. About CA software upgrade date, we re-schedule it to 2nd quarter of this year.
3. About log all TLS certificate to CT log server, we start to log on February 6.

Thanks,
Robin

> (In reply to Robin Lin from comment #10)
> > Hello Ryan,
> > 
> > About your question"
> > 1. Can you indicate when this is scheduled/
> > We have complete the SSL RA software modification. The testing and
> > verification process are under going. We will change our production server
> > in December of this year.
> > 
> > 2. Can you indicate if/when this is scheduled?
> > About the integration with https://crt.sh/linttbscert API, we have to modify
> > our certificate issuing software. We plan to modify the code in the 4th
> > quarter of this year and change the production system to new version in the
> > 1st quarter of 2018.
> > 
> > 3. Can you indicate if/when this is scheduled?
> > About the turn on the CT logging function in OV SSL certificate issuing
> > system, we plan to enable in 1st quarter of 2018 to make sure the compliance
> > with Chrome browser.
> > 
> > Thanks,
> > Robin Lin
> > 
> > (In reply to Ryan Sleevi from comment #9)
> > > (In reply to Robin Lin from comment #8)
> > > > Hi Ryan,
> > > > 
> > > > Thanks for the reply.
> > > > 
> > > > 1. We have scheduled a plan to modified RA front end software to check
> > > > domain name and CAA records to avoid the manual process fail. 
> > > 
> > > Can you indicate when this is scheduled/
> > > 
> > > > 2. We also consider to use API to access https://crt.sh/linttbscert to check
> > > > TBSCertificate to avoid the miss issue, or develop our own software to check
> > > > BE compliance in case of the API no longer exist.
> > > 
> > > Can you indicate if/when this is scheduled?
> > > 
> > > > 
> > > > 3. Enable TLS certificate issuing CA to log all certificates to CT log
> > > > server.
> > > 
> > > Can you indicate if/when this is scheduled?
> 
> Robin: will you please provide an update on these action items?
Flags: needinfo?(robin.lin)
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 15-May 2018
Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254
QA Contact: gerv → wthayer
Robin: has the CA software upgrade referenced in comment #12 been completed? Please provide an update.
Flags: needinfo?(robin.lin)
We had upgrade the CA software with following mechanism:
1. Check the CAA record while subscriber upload their application request.
2. Log all pre-certificate to CT log server.

If the domain is not public or did not authorize TWCA to issue certificate, the CA software will stop the process of certificate application. 
This should be able to avoid to issue local domain SSL certificate.

Thanks,
Robin Lin
Flags: needinfo?(robin.lin)
Wayne: It sounds like all proposed remediation steps have been completed. Is there any further information to gather?
Flags: needinfo?(wthayer)
Resolving this incident.
Status: NEW → RESOLVED
Closed: 9 months ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next Update - 15-May 2018 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.