CA/Symantec Issues

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This page lists all confirmed or suspected issues involving the CA "Symantec". It will be updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email Gerv.

The issues are in broadly chronological order.

Issue XXX: Insecure Issuance API (2013 - November 2016)

According to reports and the press, for several years Symantec operated an issuance API which was insufficiently secure, such that URL parameter substitution attacks would allow one customer to view, reissue, revoke and otherwise control certificates (including non-server certs) belonging to another customer. When made aware of these issues, Symantec took a very long time to fix them, and they may not have been fully fixed at the time Symantec terminated its RA program entirely.

Symantec has not yet been formally asked by Mozilla to respond to this issue. However, they commented to the press:

"We have looked into Chris Byrne’s research claim and could not recreate the problem. We would welcome the proof of concept from the original research in 2015 as well as the most recent research. In addition, we are unaware of any real-world scenario of harm or evidence of the problem. However, we can confirm that no private keys were accessed, as that is not technically feasible.

Issue XXX: Issued Certificate Directly From Root (Dec 2013 - Jan 2014)

Symantec issued a cert to one of its customers, Pitney Bowes, that did not comply with at least one provision of the CA/Browser Forum Baseline Requirements, in that it was issued directly from a root.

This cert was a 1024-bit cert, but if it was issued in 2013, that was neither a BR nor a Mozilla policy violation, as the 1024-bit issuance deadline was 31st December 2013. It was also backdated, but that is not a BR or Mozilla policy violation either, as long as it was not done to evade a technical control. If it was in fact issued in early 2014, it would be a violation of all of these requirements, but there is no way for us to tell and so we must take Symantec's word for it. It also has a short serial number, but entropy in the serial number is a SHOULD in the relevant version of the BRs (1.1.6). It's a MUST in the Mozilla requirements (2.2), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time.

Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. However, they did not request permission to issue in advance, disclosed the issuance a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID.

Symantec disclosed this issue to Mozilla at the end of January 2014. The incident is recorded in bug 966350.

Issue XXX: SHA-1 Issuance After Deadline (January 2016)

Symantec issued five SHA-1 certificates after the SHA-1 issuance deadline. These were certificates requested (or enrolled) in 2015 but issued in 2016. Symantec reported this issue to the CAB Forum public mailing list. They were not the only CA to have similar issues with accidental SHA-1 issuance.

Issue XXX: SHA-1 Issuance After Deadline - 2 (February 2016)

Symantec issued a SHA-1 precertificate in February 2016. They seemed to claim, contrary to the CT RFC, that misissuance of a pre-certificate is not misissuance. (Mozilla considers that it is.) Their explanation for the incident was as follows:

Following discussions with the customer who initiated this order, we have identified a technical deficiency in our system that allowed for hash algorithm modifications by a subset of customers to existing enrollments in limited circumstances, and only when pending administrator review prior to issuance. We released a patch today to add this case to our system-wide SHA1 blocking mechanisms. In addition, as an added precaution, we are evaluating an update to actively change any SHA1 orders encountered in our system to SHA256.

It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem.

Issue XXX: UniCredit Sub CA Failing To Follow BRs (April - October 2016)

Symantec issued an unconstrained sub-CA to a company called UniCredit. This company persistently issued certificates which were BR-noncompliant (e.g. missing SANs, missing OCSP URIs). During this time, they did not have the appropriate audits and Symantec were aware of this. Symantec claimed, in response to the CA Communication of March 2016, that they had disclosed to Mozilla all their intermediate CAs along with audits, but this was not true in the case of UniCredit. The UniCredit CPS was also BR-noncompliant, in that it said that SANs were optional.

Several months after this problem was discovered by Mozilla, Symantec eventually ordered them to stop issuing, but they continued, in violation of that agreement. Symantec then finally revoked their intermediate.

This incident is recorded in bug 1261919.

Issue XXX: Cross-Signing the US Federal Bridge (July 2016)

The US Government has an extremely complicated PKI called the Federal PKI. It has applied for inclusion in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies.

Symantec cross-signed one of the root CAs in the FPKI, thereby making certificates below that root in the chain of trust be publicly trusted. This intermediate CA was not disclosed in the CCADB. When this was drawn to their attention, Symantec did not revoke the cross-sign, instead allowing it to expire (less than a month later).

Issue XXX: Accidental Manual Signing Using SHA-1 (July 2016)

Symantec applied to the root programs for leave to issue SHA-1 certificates for a customer. As part of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all the data except for the signature) for CAB Forum review. However, they accidentally issued real certificates - i.e. they signed the tbsCertificate data using SHA-1. Therefore they had to revoke all of those certificates, and issue new ones after permission was granted. This was supposedly a manual process but it seems like the relevant instructions were either deficient or not followed.

Issue XXX: RA Program Misissuances ()

For several years, Symantec operated an RA (Registration Authority) program. The companies in this program had independent authority to issue certificates under Symantec intermediates, and those certificates were not specifically marked to say that a particular RA had issued them instead of Symantec directly. This by itself is not against any policy.

However, In January 2017, it was discovered that a number of test certificates had been issued by Symantec intermediates. The investigation of these matters led to increasing further discoveries of misissuances and potential misissuances, together with poor CA practice, by companies in Symantec's RA network. Due to these discoveries, Symantec subsequently decided to shut down the program entirely and revalidate every certificate issued under it. This issue deals with the certificate misissuances; the following issue deals with the audit-related problems uncovered.

Issue XXX: Incomplete RA Program Remediation (March 2017)

At the time Symantec shut down their RA program, they had four RAs - CrossCert, Certisign, Certsuperior, and Certisur. Symantec committed to revalidating all certificates issued by those RAs. However, the program previously had additional RAs, and Symantec has as yet taken no action to revalidate the certificates that they issued, despite some still being valid. Those RAs include at least E-Sign (from at least March 1st 2014 to at least July 31st 2015).

Symantec has not yet been officially requested to respond to this issue.

Issue XXX: RA Program Audit Issues (XXX - March 2017)

Symantec's RAs appear to have had a history of poor compliance with the BRs and other audit requirements, facts which were known to Symantec but not disclosed to Mozilla or dealt with in appropriately comprehensive ways.

Over multiple years (2013-12-01 to 2014-11-30, 2014-12-01 to 2015-11-30), Symantec's "GeoTrust" audits were qualified to say that they did not have proper audit information for some of these RAs. This information was in their management assertions, and repeated in the audit findings. So the poor audit situation was ongoing and known. Also, other audit reports, despite being in hierarchies accessible for issuance by the same RAs, did not have similar qualifications (Symantec Trust Network, 2014-12-01 to 2015-11-30).

One Symantec RA, Certsuperior, had a particularly dreadful audit:

• There was no legible CPS;
• inadequately-trained personnel were doing issuance;
• the network was an insecure mess; and
• non-trusted staff had access to issuance.

Symantec required the issues to be fixed and a 90-day action plan was executed to fix them. However, until they decided to shut down the RA program, no certificates issued during the period of suspect operations were checked to see if the poor practice had caused misissuance.

Ryan wrote: "have you examined the most recent set of audits? Do you, in your capacity as CA Certificate policy peer, believe the audits were correct for their capability and role? Note that several of them were "WebTrust for CAs" - not "WebTrust for CAs - SSL BR and Network Security". Do you believe that complies with letter of the Baseline Requirements?"

Despite the clear warning signs shown on these audits, Symantec did not put in place any monitoring of their RAs, other than audit, to check that they were correctly performing the tasks delegated to them under the BRs. There were some - overridable - technical checks on certificate issuance.