CA/Symantec Issues - Revision history

Kathleen Wilson: Kathleen Wilson moved page CA:Symantec Issues to CA/Symantec Issues: Moved from CA: to CA/

2021-12-30T22:06:38Z

Kathleen Wilson moved page CA:Symantec Issues to CA/Symantec Issues: Moved from CA: to CA/

← Older revision	Revision as of 22:06, 30 December 2021
(No difference)

Wthayer: Change contact info to Wayne

2018-10-10T14:50:14Z

Change contact info to Wayne

← Older revision		Revision as of 14:50, 10 October 2018
Line 11:		Line 11:


	This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:~~gerv~~@mozilla.org ~~Gerv~~]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.		This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:wthayer@mozilla.org Wayne]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.

	The issues are in broadly chronological order by end date.		The issues are in broadly chronological order by end date.

Kathleen Wilson: Updated timeline to remove specific dates and add note that Mozilla release content and schedules being subject to change.

2017-10-16T15:59:14Z

Updated timeline to remove specific dates and add note that Mozilla release content and schedules being subject to change.

← Older revision		Revision as of 15:59, 16 October 2017
Line 2:		Line 2:

	* December 1st, 2017: Symantec to implement "Managed CA" proposal		* December 1st, 2017: Symantec to implement "Managed CA" proposal
	* ~~April 17th,~~ 2018: ~~Dis-trust of all~~ Symantec certificates issued before 2016-06-01 ~~(in practice~~, to ~~be implemented in~~ Firefox 60 ~~on May 1st~~)		* January 2018 (Firefox 58): Notices in the Developer Console will warn about Symantec certificates issued before 2016-06-01, to encourage site owners to migrate their TLS certs.
	* October ~~23rd,~~ 2018: ~~Final dis-trust~~ of Symantec roots ~~(in practice~~, ~~to be implemented either in Firefox 63 on October 16th or Firefox 64 on November 27th)~~		* May 2018 (Firefox 60): Websites will show an untrusted connection error if they have a TLS cert issued before 2016-06-01 that chains up to a Symantec root.
			* October 2018 (Firefox 63): Removal/distrust of Symantec roots, with caveats described below.

	~~It is~~ planned ~~for Firefox 58 (January 16th, 2018)~~ to ~~also feature a console warning for Symantec certificates issued before 2016-06-01 to help sites notice they need to migrate~~.		Note: Mozilla's planned release content and schedules are subject to change.

	-----		-----

Gerv: Add dates for Symantec

2017-10-11T10:47:01Z

Add dates for Symantec

← Older revision		Revision as of 10:47, 11 October 2017
Line 1:		Line 1:
			Following the investigation documented below, a [https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ consensus proposal] was reached among multiple browser makers for a graduated distrust of Symantec roots. The dates in that proposal and how they apply to Mozilla's Root Program and Firefox are as follows:

			* December 1st, 2017: Symantec to implement "Managed CA" proposal
			* April 17th, 2018: Dis-trust of all Symantec certificates issued before 2016-06-01 (in practice, to be implemented in Firefox 60 on May 1st)
			* October 23rd, 2018: Final dis-trust of Symantec roots (in practice, to be implemented either in Firefox 63 on October 16th or Firefox 64 on November 27th)

			It is planned for Firefox 58 (January 16th, 2018) to also feature a console warning for Symantec certificates issued before 2016-06-01 to help sites notice they need to migrate.

			-----


	This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.		This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.

Gerv: Add info from latest Symantec communication

2017-05-19T15:20:29Z

Add info from latest Symantec communication

Show changes

Gerv: Update list of problems and dates

2017-04-27T13:38:46Z

Update list of problems and dates

← Older revision		Revision as of 13:38, 27 April 2017
Line 215:		Line 215:
	* Test certs to registered domains: Discovered and fixed in Sep 2015, but "while inappropriate use of registered domains for testing stopped during the course of our 2014-2015 audits, we did not complete the ID and revocation of all certificates until Mar 2016, and so the finding remained in our first-half Dec 1, 2015-Jun 15, 2016 audits."		* Test certs to registered domains: Discovered and fixed in Sep 2015, but "while inappropriate use of registered domains for testing stopped during the course of our 2014-2015 audits, we did not complete the ID and revocation of all certificates until Mar 2016, and so the finding remained in our first-half Dec 1, 2015-Jun 15, 2016 audits."
	* Test certs to un-registered domains: Discovered and fixed in October 2015, but there was a "discovery of additional instance involving approved domains in a test account resulting in 6 additional issued certificates in Approximately Mar 2016." (Mozilla isn't aware that Symantec has previously made disclosure of this mis-issuance.)		* Test certs to un-registered domains: Discovered and fixed in October 2015, but there was a "discovery of additional instance involving approved domains in a test account resulting in 6 additional issued certificates in Approximately Mar 2016." (Mozilla isn't aware that Symantec has previously made disclosure of this mis-issuance.)
			* Unauthorized employees with access to certificate issuance capability: discovered in September 2015, last problem of this type remediated in June 2016 after extensive security review.
	* Failure to maintain physical security records for 7 years: discovered and fixed in January 2016.		* Failure to maintain physical security records for 7 years: discovered and fixed in January 2016.
	* Failure to review application and system logs: discovered and fixed in January 2016.		* Failure to review application and system logs: discovered and fixed in January 2016.
	* The failure to refresh background checks every 5 years: discovered in February 2016, fixed in June 2016 (required an internal reorganization).		* The failure to refresh background checks every 5 years: discovered in February 2016, fixed in June 2016 (required an internal reorganization).

	In regard to the lack of qualifications related to GeoRoot and the RA program, Symantec said: "We acknowledge there were deficiencies in audits for both the GeoRoot and RA programs. The plan for the GeoRoot deficiencies was communicated in the cover letter accompanying our Point in Time audit (see issue V) and for the RA program, in the cover letter to browsers with our 2015-2016 audits."		In regard to the lack of qualifications related to GeoRoot and the RA program, Symantec said: "We acknowledge there were deficiencies in audits for both the GeoRoot and RA programs. The plan for the GeoRoot deficiencies was communicated in the cover letter accompanying our Point in Time audit (see issue V) and for the RA program, in the cover letter to browsers with our 2015-2016 audits."

	===Additional Comments and Conclusion===		===Additional Comments and Conclusion===

Gerv: Rename Issue Y

2017-04-27T11:01:51Z

Rename Issue Y

← Older revision		Revision as of 11:01, 27 April 2017
Line 367:		Line 367:
	In the absence of evidence that these organizations have the ability to issue SSL/TLS certificates, we must accept Symantec's assertion.		In the absence of evidence that these organizations have the ability to issue SSL/TLS certificates, we must accept Symantec's assertion.

	==Issue Y: Unaudited Unconstrained Intermediates (December 2015 - April 2017)==		==Issue Y: Under-audited or Unaudited Unconstrained Intermediates (December 2015 - April 2017)==

	Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, have audit and control problems:		Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, have audit and control problems:

Gerv: Update URL

2017-04-27T10:22:44Z

Update URL

← Older revision		Revision as of 10:22, 27 April 2017
Line 266:		Line 266:
	===Symantec Response===		===Symantec Response===

	Symantec made a number of comments on this issue - [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 0], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 1], [https://bug1334377.bmoattachments.org/attachment.cgi?id=~~8831933~~ 2], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825 3], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8843448 4].		Symantec made a number of comments on this issue - [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 0], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 1], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487 2], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825 3], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8843448 4].

	The Baseline Requirements, in section 4.9.1.1 item 9, state that the CA SHALL revoke a certificate if "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". However, Symantec did not revoke all the certificates.		The Baseline Requirements, in section 4.9.1.1 item 9, state that the CA SHALL revoke a certificate if "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". However, Symantec did not revoke all the certificates.

Gerv: Update Issue V to include feedback from Kathleen

2017-04-25T14:01:51Z

Update Issue V to include feedback from Kathleen

← Older revision		Revision as of 14:01, 25 April 2017
Line 296:		Line 296:
	===Symantec Response===		===Symantec Response===

	* Symantec state: "Intel's subordinate CA, which expired in 2016, was not subject to audits either contractually or by previous agreements with both Mozilla and Microsoft given its limited use." ~~-- Need~~ to ~~check with Kathleen~~.		* Symantec state: "Intel's subordinate CA, which expired in 2016, was not subject to audits either contractually or by previous agreements with both Mozilla and Microsoft given its limited use." This is true; the CA is mothballed and got out of storage only once a quarter to issue a CRL. Symantec agreed privately with Mozilla that audits were not necessary for a CA in such a state.
	* Symantec ~~state: "Symantec provided the letter quoted below to Google,~~ Mozilla~~, Microsoft, and Apple when we shared the Point~~ in Time Audits on September 6, 2016 to specifically address the GeoRoot audit status and remediation plan. That cover letter outlined the plan to wind down the Aetna and UniCredit subordinate CAs." -- Need to check with Kathleen.

	If Symantec ~~did indeed notify us of this situation~~ and we ~~made no comment~~, ~~that~~ is ~~a relevant fact~~.		* Symantec state: "Symantec provided the letter quoted below to Google, Mozilla, Microsoft, and Apple when we shared the Point in Time Audits on September 6, 2016 to specifically address the GeoRoot audit status and remediation plan. That cover letter outlined the plan to wind down the Aetna and UniCredit subordinate CAs." This is true, although Aetna and UniCredit are not mentioned by name in the letter.

	Symantec have also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 stated] that, as of April 21st, 2017, the "Intel, Aetna, and Unicredit CAs have all expired or been revoked." This leaves Google and Apple as the only participants in the GeoRoot program. They also say that: "We agree that getting audits for Aetna and Unicredit took too long. After many discussions, requests, and delays, they finally produced the reports that they did. This experience informed our decision to transition them to alternative solutions."		Symantec have also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 stated] that, as of April 21st, 2017, the "Intel, Aetna, and Unicredit CAs have all expired or been revoked." This leaves Google and Apple as the only participants in the GeoRoot program. They also say that: "We agree that getting audits for Aetna and Unicredit took too long. After many discussions, requests, and delays, they finally produced the reports that they did. This experience informed our decision to transition them to alternative solutions."
Line 306:		Line 305:

	===Further Comments and Conclusion===		===Further Comments and Conclusion===

	~~I am following up on the open questions above with Kathleen.~~

	It seems that the NTT DoCoMo infrastructure did fall through the cracks audit-wise until 2015-2016.		It seems that the NTT DoCoMo infrastructure did fall through the cracks audit-wise until 2015-2016.

	Given the power which those organizations held, Symantec did not pursue Aetna and UniCredit for proper audits and appropriate compliance with sufficient alacrity (on UniCredit, see Issue P).		Given the power which those organizations held, Symantec did not pursue Aetna and UniCredit for proper audits and appropriate compliance with sufficient alacrity (on UniCredit, see Issue P). However, to a degree, Symantec did keep Mozilla somewhat informed of what was going on, and Mozilla made no comment. It is our understanding that at least one other root program was applying more pressure to remediate this situation than Mozilla was.

	==Issue W: RA Program Audit Issues (2013 or earlier - January 2017)==		==Issue W: RA Program Audit Issues (2013 or earlier - January 2017)==

Gerv: Unstrike and update Issue Y

2017-04-25T13:29:30Z

Unstrike and update Issue Y

← Older revision		Revision as of 13:29, 25 April 2017
Line 370:		Line 370:
	In the absence of evidence that these organizations have the ability to issue SSL/TLS certificates, we must accept Symantec's assertion.		In the absence of evidence that these organizations have the ability to issue SSL/TLS certificates, we must accept Symantec's assertion.

	==~~STRUCK: <strike>~~Issue Y: Unaudited Unconstrained Intermediates (December 2015 - April 2017)~~</strike>~~==		==Issue Y: Unaudited Unconstrained Intermediates (December 2015 - April 2017)==

	Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, ~~appear not to be covered by any of Symantec's audits as listed in their document repository~~:		Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, have audit and control problems:

	* [https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired VeriSign Class 3 SSP Intermediate CA - G2]		* [https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired VeriSign Class 3 SSP Intermediate CA - G2]
	* [https://crt.sh/?Identity=%25&iCAID=12352&exclude=expired Symantec Class 3 SSP Intermediate CA - G3]		* [https://crt.sh/?Identity=%25&iCAID=12352&exclude=expired Symantec Class 3 SSP Intermediate CA - G3]

	Both intermediates are disclosed in Salesforce, and both have 15 or so also-disclosed sub-CAs which seem to be specific to particular companies. The audit associated with both of them in Salesforce is [https://www.symantec.com/content/en/us/about/media/repository/symantec_nfssp_wtca_5_13_2016.pdf this one] from May 2016, ~~but that audit document does not list the intermediate CAs that it covers~~. ~~It's~~ from Symantec's 2015 set of audits (i.e. the set before the current one)~~. The most recent~~ audit ~~which~~ covers ~~the VeriSign Universal Root Certification Authority is~~ [https://www.symantec.com/content/en/us/about/media/repository/~~18_Symantec_STN_WTCA_period_end_11~~-30-2016.pdf ~~this one~~], but ~~these certificates are~~ not on the ~~accompanying list of intermediates~~. ~~There seems to be no 2016 version of~~ the ~~"Symantec Non-Federal Shared Service Provider WTCA"~~ audit ~~in the list for 2016 in the Symantec [https://www.symantec.com/about/legal/repository.jsp?tab=Tab3 document repository]~~.		Both intermediates are disclosed in Salesforce, and both have 15 or so also-disclosed sub-CAs which seem to be specific to particular companies. The audit associated with both of them in Salesforce is [https://www.symantec.com/content/en/us/about/media/repository/symantec_nfssp_wtca_5_13_2016.pdf this one] from May 2016, i.e. from Symantec's 2015 set of audits (i.e. the set before the current one), but that audit document does not list the intermediate CAs that it covers. Symantec has produced a [https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf more recent audit] but not yet updated Salesforce. This one does list the intermediate CAs covered. However, like that from the previous year, this is a WebTrust for CAs audit, and does not include a BR audit.

	As far as we can tell, ~~these intermediates~~ are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers. ~~They appear~~ to ~~be related~~ to the ~~US Federal Bridge PKI (see Issue L)~~.		These intermediates appear to be related to the US Federal Bridge PKI (see Issue L) As far as we can tell, they are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers. Mozilla policy is based on capability, not intent - if a sub-CA is capable of issuing SSL certs we trust, it must be appropriately constrained or audited. These intermediates have deficient audits and, as far as we can tell, sub-CAs of them are effectively controlled by entities without any audits at all. Specifically:

			* The CP/CPS does not state adherence to the Baseline Requirements.
			* The audit is only a WebTrust for CAs audit, not a BR audit.
			* A number of sub-CAs seem excluded from even the scope of that audit, as they are not listed in it: [https://crt.sh/?id=19602740 1], [https://crt.sh/?id=19602709 2], [https://crt.sh/?id=19602733 3], [https://crt.sh/?id=19602720 4], [https://crt.sh/?id=19602670 5], [https://crt.sh/?id=19602679 6], [https://crt.sh/?id=19602705 7], [https://crt.sh/?id=19602730 8].
			* The CP/CPS has a profile which includes issuing certificates with dNSName and iPAddress SANs, and Symantec states that Windows domain controller certs are within scope for the program. Such certs are fully TLS server certificates.
			* [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 A Symantec statement] suggests that customers of their NF SSP program can perform RA duties for the issuance of certs for Windows domain controllers and, according to the audit report, those RA activities are outside the scope of the audit entirely.

	===Symantec Response===		===Symantec Response===

	Symantec ~~say that these intermediates "are covered under Symantec’s Non-Fed SSP audits, and~~ the latest unqualified audits that we just received are being published." And indeed such an audit [https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf has now appeared], albeit significantly late.		Symantec has not yet responded to the updated allegations here.

	===Further Comments and Conclusions===		===Further Comments and Conclusions===

	~~These~~ intermediates ~~do appear to be covered by audits, albeit tardily-submitted ones. They~~ are ~~constrained by policy OID, although such constrains are not recognised by the Web PKI~~, and ~~so they remain~~ capable of issuing ~~SSL certs~~ trusted by Mozilla ~~and need to continue to be under appropriate control and audit~~.		All evidence still points to it being the case that these intermediates are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers, yet they have deficient or missing audits.