CA/Maintenance and Enforcement - Revision history

Bwilson: /* Actively Distrusting a Certificate */ Removed link to TLS canary

2025-05-16T13:27:16Z

Actively Distrusting a Certificate: Removed link to TLS canary

← Older revision		Revision as of 13:27, 16 May 2025
Line 131:		Line 131:
	# Measure Impact of Change		# Measure Impact of Change
	#* Check Firefox telemetry for usage data of the affected root certificate		#* Check Firefox telemetry for usage data of the affected root certificate
	#* ~~Run [https://tlscanary.mozilla.org/~~ TLS Canary~~] in regression mode to determine which websites will be affected.~~		#* (TLS Canary deprecated)
	# Implement Code Change		# Implement Code Change
	#* Add the corresponding intermediate or end-entity certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].		#* Add the corresponding intermediate or end-entity certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].

Bwilson: Added links to blog posts

2025-05-07T15:50:39Z

Added links to blog posts

@@ Line 104: / Line 104: @@
 * https://wiki.mozilla.org/CA/Visa_Issues
 * https://wiki.mozilla.org/CA/Certinomis_Issues
 = Actively Distrusting a Certificate =

Bwilson: /* Concerns */ Obsoleted on May 7, 2025

2025-05-07T15:24:35Z

Concerns: Obsoleted on May 7, 2025

← Older revision		Revision as of 15:24, 7 May 2025
Line 141:		Line 141:
	= Concerns =		= Concerns =

	* Certs that have been mistakenly issued with insufficient key usage can be used maliciously until we implement {{Bug\|725351}}.		Obsoleted on 7-May-2025.
	* The code patch to distrust a cert should only disclose the necessary information; {{Bug\|826640}}.
	* If the certificate to be distrusted is cross-signed by another certificate in NSS, then the Serial Number and Issuer for that certificate chain also has to be distrusted. This is error-prone, even if we ask every CA in Mozilla's program if they have cross-signed with the certificate to be distrusted.
	** Possible Scenario: A cross-signing relationship is overlooked, so the malicious certificate continues to be trusted even after the security update.
	** Possible Solution: {{Bug\|808839}} - Ability to Actively Distrust all certs with a particular Subject.
	* The Certificate Manager does not recognize the "distrust" flag, so there is no distinction in the user interface between certificates that have been Actively Distrusted in NSS and all other certificates. The distrusted certificate(s) should also be added to OneCRL, so the certificate(s) will still be distrusted even if the user manually turns on the trust bits for Actively Distrusted certificates.
	** Possible Scenario: User confusion about Actively Distrusted certs listed in the Certificate Manager.
	** Possible Solutions: {{Bug\|470994}}, {{Bug\|733716}}. For Actively Distrusted certs, remove the cert entry from the NSS built-in cert list, and only keep the (dis)trust entry.
	* If the certificate to be Actively Distrusted is used by a large portion of the internet population, immediately distrusting the certificate could make many high-traffic websites no longer be reachable, giving the appearance of a large network outage, or users might take actions (such as permanently trusting the bad cert) to bypass error messages.
	** Possible Scenario: A root certificate that is chained to by many high-traffic websites is compromised and has to be Actively Distrusted. This is done and an update to Firefox pushed out. Then a large number of users can no longer browse to the high-traffic websites, giving the appearance of an outage, costing those high-traffic websites loss in money, causing frustration and confusion to end users who are regular customers of those websites. Many end-users are likely to manually-override the error, permanently trusting the certificate. Then if they later accidentally browse one of the corresponding malicious websites, they will not get an error.
	** Possible Solutions: Implement date-based distrust {{Bug\|712615}}, a whitelist of certificates to remain trusted {{Bug\|1151512}}, or make an announcement that the root will be distrusted on ~~such a date, allowing a small transition time for websites to update their TLS certificates before before the Firefox chemspill update is released.~~
	* Distrusting a certificate requires a release to the NSS root module, and users have to choose to upgrade to the new version. Firefox users are protected from distrusted certificates that are added to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-~~introducing~~-~~onecrl/ OneCRL]~~.

Bwilson: /* Issues Lists */ Added e-commerce monitoring link

2024-08-08T15:32:21Z

Issues Lists: Added e-commerce monitoring link

← Older revision		Revision as of 15:32, 8 August 2024
Line 97:		Line 97:
	= Issues Lists =		= Issues Lists =
	* https://wiki.mozilla.org/CA/Entrust_Issues		* https://wiki.mozilla.org/CA/Entrust_Issues
			* https://wiki.mozilla.org/CA/e-commerce-monitoring_Issues
	* https://wiki.mozilla.org/CA/Camerfirma_Issues		* https://wiki.mozilla.org/CA/Camerfirma_Issues
	* https://wiki.mozilla.org/CA/PROCERT_Issues		* https://wiki.mozilla.org/CA/PROCERT_Issues

Bwilson: /* Issues Lists */ Added Entrust issues link

2024-05-06T22:17:47Z

Issues Lists: Added Entrust issues link

← Older revision		Revision as of 22:17, 6 May 2024
Line 96:		Line 96:

	= Issues Lists =		= Issues Lists =
			* https://wiki.mozilla.org/CA/Entrust_Issues
	* https://wiki.mozilla.org/CA/Camerfirma_Issues		* https://wiki.mozilla.org/CA/Camerfirma_Issues
	* https://wiki.mozilla.org/CA/PROCERT_Issues		* https://wiki.mozilla.org/CA/PROCERT_Issues

Bwilson: /* Recurring Issues */ Created subheading for Issues List

2024-05-05T19:54:07Z

Recurring Issues: Created subheading for Issues List

← Older revision		Revision as of 19:54, 5 May 2024
Line 95:		Line 95:
	In addition to evaluating the severity of a specific incident, Mozilla considers the totality of known issues and patterns of behavior in a CA's response to those issues. When Mozilla believes that sufficient evidence is available to establish an ongoing pattern of neglect or incompetence, an Issues List may be created. Mozilla will compile the facts of known problems of a particular CA and create a wiki page listing them. Mozilla may then ask the community to consider a response to the combined set of issues based on the perceived risk to users. This response typically involves distrust of the CA's currently included roots, or requiring the CA to undergo more frequent audits until the Mozilla community’s trust in the CA has been adequately restored.		In addition to evaluating the severity of a specific incident, Mozilla considers the totality of known issues and patterns of behavior in a CA's response to those issues. When Mozilla believes that sufficient evidence is available to establish an ongoing pattern of neglect or incompetence, an Issues List may be created. Mozilla will compile the facts of known problems of a particular CA and create a wiki page listing them. Mozilla may then ask the community to consider a response to the combined set of issues based on the perceived risk to users. This response typically involves distrust of the CA's currently included roots, or requiring the CA to undergo more frequent audits until the Mozilla community’s trust in the CA has been adequately restored.

	~~'''~~Issues Lists~~'''~~		= Issues Lists =
	* https://wiki.mozilla.org/CA/Camerfirma_Issues		* https://wiki.mozilla.org/CA/Camerfirma_Issues
	* https://wiki.mozilla.org/CA/PROCERT_Issues		* https://wiki.mozilla.org/CA/PROCERT_Issues

Bwilson: Paragraph break

2023-05-22T15:37:48Z

Paragraph break

← Older revision		Revision as of 15:37, 22 May 2023
Line 4:		Line 4:
	# Carefully reviewing [[CA/Application_Process\|CA applications for root inclusion]].		# Carefully reviewing [[CA/Application_Process\|CA applications for root inclusion]].
	#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses		#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses
	#* A Mozilla representative reviews the CA's [https://wiki.mozilla.org/CA/Compliance_Self-Assessment Compliance Self-Assessment] and		#* A Mozilla representative reviews the CA's [https://wiki.mozilla.org/CA/Compliance_Self-Assessment Compliance Self-Assessment] and checks the CA's CP/CPS documentation for
	checks the CA's CP/CPS documentation for
	#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]		#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]
	#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Required Practices], and		#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Required Practices], and

Bwilson: Updated language to bring it current

2023-05-22T15:36:25Z

Updated language to bring it current

Kathleen Wilson: Changed Bugzilla Product from NSS to CA Program per Bugzilla Bug #1799573

2022-11-14T23:53:37Z

Changed Bugzilla Product from NSS to CA Program per Bugzilla Bug #1799573

Kathleen Wilson: Updated links from CA: to CA/

2021-12-30T22:08:11Z

Updated links from CA: to CA/

← Older revision		Revision as of 22:08, 30 December 2021
Line 97:		Line 97:

	'''Issues Lists'''		'''Issues Lists'''
	* https://wiki.mozilla.org/CA:Camerfirma_Issues		* https://wiki.mozilla.org/CA/Camerfirma_Issues
	* https://wiki.mozilla.org/CA:PROCERT_Issues		* https://wiki.mozilla.org/CA/PROCERT_Issues
	* https://wiki.mozilla.org/CA:Symantec_Issues		* https://wiki.mozilla.org/CA/Symantec_Issues
	* https://wiki.mozilla.org/CA:WoSign_Issues		* https://wiki.mozilla.org/CA/WoSign_Issues
	* https://wiki.mozilla.org/CA:Visa_Issues		* https://wiki.mozilla.org/CA/Visa_Issues
	* https://wiki.mozilla.org/CA/Certinomis_Issues		* https://wiki.mozilla.org/CA/Certinomis_Issues

← Older revision		Revision as of 15:36, 22 May 2023
Line 4:		Line 4:
	# Carefully reviewing [[CA/Application_Process\|CA applications for root inclusion]].		# Carefully reviewing [[CA/Application_Process\|CA applications for root inclusion]].
	#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses		#* A Mozilla representative reviews relevant [https://wiki.mozilla.org/CA/Incident_Dashboard incident reports] and the CA’s responses
	#* A Mozilla representative checks the CA's CP/CPS documentation for		#* A Mozilla representative reviews the CA's [https://wiki.mozilla.org/CA/Compliance_Self-Assessment Compliance Self-Assessment] and
			checks the CA's CP/CPS documentation for
	#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]		#** compliance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy,]
	#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Required Practices], and		#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Required Practices], and
Line 36:		Line 37:

	Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy]. Statements obtained from an auditor are assumed legitimate. Audit statements provided by a CA are verified for legitimacy with the auditor. The		Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy]. Statements obtained from an auditor are assumed legitimate. Audit statements provided by a CA are verified for legitimacy with the auditor. The
	qualifications of any auditors not previously approved by Mozilla are reviewed before an audit statement is accepted. Auditor qualifications are reviewed using the webtrust.org website or an appropriate government website. If the auditor claims to be AICPA~~/CICA/~~CISA ~~accredited~~, but the		qualifications of any auditors not previously approved by Mozilla are reviewed before an audit statement is accepted. Auditor qualifications are reviewed using the webtrust.org website or an appropriate government website. If the auditor claims to be accredited (e.g. AICPA, CPA Canada, ETSI, CISA, etc., but the auditor is not approved by Mozilla and not listed on a trusted website as accredited, then Mozilla will verify the auditor's qualifications with a representative of the accrediting organization.
	auditor is not approved by Mozilla and not listed on a trusted website as accredited, then Mozilla will verify the auditor's qualifications with a representative of ~~CICA or CISA, as appropriate~~.

	= Risks to Consumers =		= Risks to Consumers =
Line 43:		Line 43:
	Possession of a mis-issued certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (public WiFi, local network compromise) or very broad (governments). An attacker armed with a fraudulent certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. The end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) if they believe it’s coming from a trusted site.		Possession of a mis-issued certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (public WiFi, local network compromise) or very broad (governments). An attacker armed with a fraudulent certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. The end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) if they believe it’s coming from a trusted site.

	An attacker armed with a fraudulent ~~SSL~~ certificate and an ability to control their victim’s network can:		An attacker armed with a fraudulent TLS certificate and an ability to control their victim’s network can:
	* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the ~~SSL~~ certificate of the fake site is valid.		* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the TLS certificate of the fake site is valid.
	* Re-direct users to a fake site -- Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites.		* Re-direct users to a fake site -- Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites.
	** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.		** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.
Line 65:		Line 65:
	[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] describes the steps that Mozilla takes to evaluate and respond to security concerns related to certificate operation and issuance. The following list may be used as a guideline of what to expect when certain types of issues are found, but this list is non-binding because the necessary actions and responses will vary depending on the situation.		[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] describes the steps that Mozilla takes to evaluate and respond to security concerns related to certificate operation and issuance. The following list may be used as a guideline of what to expect when certain types of issues are found, but this list is non-binding because the necessary actions and responses will vary depending on the situation.

	'''Problem:''' CA mis-issued a small number of ~~SSL~~ certificates that they can enumerate		'''Problem:''' CA mis-issued a small number of TLS certificates that they can enumerate
	* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].		* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
	* Depending on the situation, also consider adding the certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].		* Depending on the situation, also consider adding the certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].
Line 150:		Line 150:
	* If the certificate to be Actively Distrusted is used by a large portion of the internet population, immediately distrusting the certificate could make many high-traffic websites no longer be reachable, giving the appearance of a large network outage, or users might take actions (such as permanently trusting the bad cert) to bypass error messages.		* If the certificate to be Actively Distrusted is used by a large portion of the internet population, immediately distrusting the certificate could make many high-traffic websites no longer be reachable, giving the appearance of a large network outage, or users might take actions (such as permanently trusting the bad cert) to bypass error messages.
	** Possible Scenario: A root certificate that is chained to by many high-traffic websites is compromised and has to be Actively Distrusted. This is done and an update to Firefox pushed out. Then a large number of users can no longer browse to the high-traffic websites, giving the appearance of an outage, costing those high-traffic websites loss in money, causing frustration and confusion to end users who are regular customers of those websites. Many end-users are likely to manually-override the error, permanently trusting the certificate. Then if they later accidentally browse one of the corresponding malicious websites, they will not get an error.		** Possible Scenario: A root certificate that is chained to by many high-traffic websites is compromised and has to be Actively Distrusted. This is done and an update to Firefox pushed out. Then a large number of users can no longer browse to the high-traffic websites, giving the appearance of an outage, costing those high-traffic websites loss in money, causing frustration and confusion to end users who are regular customers of those websites. Many end-users are likely to manually-override the error, permanently trusting the certificate. Then if they later accidentally browse one of the corresponding malicious websites, they will not get an error.
	** Possible Solutions: Implement date-based distrust {{Bug\|712615}}, a whitelist of ~~certs~~ to remain trusted {{Bug\|1151512}}, or make an announcement that the root will be distrusted on such a date, allowing a small transition time for websites to update their ~~SSL certs~~ before before the Firefox chemspill update is released.		** Possible Solutions: Implement date-based distrust {{Bug\|712615}}, a whitelist of certificates to remain trusted {{Bug\|1151512}}, or make an announcement that the root will be distrusted on such a date, allowing a small transition time for websites to update their TLS certificates before before the Firefox chemspill update is released.
	* Distrusting a certificate requires a release to the NSS root module, and users have to choose to upgrade to the new version. Firefox users are protected from distrusted certificates that are added to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].		* Distrusting a certificate requires a release to the NSS root module, and users have to choose to upgrade to the new version. Firefox users are protected from distrusted certificates that are added to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].

← Older revision		Revision as of 23:53, 14 November 2022
Line 16:		Line 16:
	#* [https://wiki.mozilla.org/CA/Communications CA Communications]		#* [https://wiki.mozilla.org/CA/Communications CA Communications]
	#* If a CA does not respond to Mozilla's communications within the timeframe specified in the communication or does not provide a copy of its annual audit statement within 15 months of the end of its previous annual audit period, then Mozilla may take action up to and including [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#73-removals removal of the root(s) from the program].		#* If a CA does not respond to Mozilla's communications within the timeframe specified in the communication or does not provide a copy of its annual audit statement within 15 months of the end of its previous annual audit period, then Mozilla may take action up to and including [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#73-removals removal of the root(s) from the program].
	# When a potential certificate mis-issuance is noticed by anyone, they should report it by [https://bugzilla.mozilla.org/enter_bug.cgi?product=~~NSS~~&component=CA%20Certificate%~~20Mis-Issuance~~ creating a bug in the CA Certificate ~~Mis-issuance~~ component]. More information on filing a security-sensitive bug can be found in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy.]		# When a potential certificate mis-issuance is noticed by anyone, they should report it by [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance creating a bug in the CA Certificate Compliance component]. More information on filing a security-sensitive bug can be found in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy.]

	When a security threat or potential certificate mis-issuance arises with a CA in Mozilla's program we consider the impact and risk to the end-users to decide on the action to take. The following considerations are taken into account:		When a security threat or potential certificate mis-issuance arises with a CA in Mozilla's program we consider the impact and risk to the end-users to decide on the action to take. The following considerations are taken into account:
Line 66:		Line 66:

	'''Problem:''' CA mis-issued a small number of SSL certificates that they can enumerate		'''Problem:''' CA mis-issued a small number of SSL certificates that they can enumerate
	* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=~~NSS~~&component=CA%20Certificate%~~20Mis-Issuance~~ CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].		* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
	* Depending on the situation, also consider adding the certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].		* Depending on the situation, also consider adding the certificates to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL].

Line 74:		Line 74:

	'''Problem:''' CA mis-issued a large number (e.g. hundreds) of end-entity certificates that they can enumerate		'''Problem:''' CA mis-issued a large number (e.g. hundreds) of end-entity certificates that they can enumerate
	* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=~~NSS~~&component=CA%20Certificate%~~20Mis-Issuance~~ CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].		* Immediate Minimum Response: Open a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance CA compliance] and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
	* Depending on the situation, also consider adding the intermediate CA certificate(s) to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], distrusting the root certificate that the mis-issued certificates chain up to, or all of the root certificates owned by that CA.		* Depending on the situation, also consider adding the intermediate CA certificate(s) to [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], distrusting the root certificate that the mis-issued certificates chain up to, or all of the root certificates owned by that CA.

Line 90:		Line 90:

	'''Problem:''' CA failed to supply proper audit documentation, or audit report contains numerous and/or serious qualifications		'''Problem:''' CA failed to supply proper audit documentation, or audit report contains numerous and/or serious qualifications
	* Immediate Minimum Response: File a [https://bugzilla.mozilla.org/enter_bug.cgi?product=~~NSS~~&component=CA%20Certificate%~~20Mis-Issuance~~ CA compliance] bug, request that the CA respond with remediation plans, and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report]		* Immediate Minimum Response: File a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance CA compliance] bug, request that the CA respond with remediation plans, and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report]
	* Depending on the situation, also consider requiring the CA to undergo new period-of-time audits as soon as the problems have been resolved. If the same problems are included on the new audit reports, they must state the dates on which the problems were resolved.		* Depending on the situation, also consider requiring the CA to undergo new period-of-time audits as soon as the problems have been resolved. If the same problems are included on the new audit reports, they must state the dates on which the problems were resolved.