Changes

According to [https://www.facebook.com/cbyrneiv/posts/10155129935452436 reportsa report] 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.

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 20 bits of entropy is a MUST in the Mozilla requirements policy (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 disclosed this issue issuance to Mozilla at the end of January 2014. The incident is recorded in {{bug|966350}}.

Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 CT precertificate] in February 2016. They then 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:

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 existing policy.

However, In January 2017, [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ it was discovered] that a small number of test certificates had been issued by misissued using Symantec intermediatesby an RA called CrossCert in Korea. The investigation of these matters led to increasing further discoveries of misissuances (totalling 127 confirmed cases) and potential misissuancesby CrossCert, together with poor CA practice, by them and other companies in Symantec's RA network. Due to these discoveries, Symantec subsequently decided to shut down the RA program entirely and revalidate re-assess every certificate issued under it. This issue deals with the certificate misissuances; the following issue deals with the audit-related problems uncovered. Types of misissuance by CrossCert: * Use of unvalidated domain names not owned by either Symantec or CrossCert* Typos in domain names* Bogus ST, L, O and OU fields: numbers, "test" or similar* Violation of CPS (use of non-KR country code) Some of these misissuance were caused by employees of the RA CrossCert overriding compliance flags in Symantec's issuance system. Symantec had no process in place to review the logs of overridden flags. For some of the certs, they contained domains neither Symantec nor CrossCert own or control, and CrossCert did not complete the appropriate domain validations for them. Upon deciding to close down the RA program, Symantec committed to revalidating all 30,000+ certificates issued by their RAs if deficient validation was discovered. However, the determination of deficient validation was made based on the RAs own logs of activity, which may themselves be suspect given some of the audit deficiencies found at these RAs and given Symantec's own investigations which discovered that CrossCert was not keeping adequate records of their issuance process. When Symantec put various controls and restrictions in place following the previous "test cert" incident, those controls, checks and restrictions did not extend to their RA network. Symantec say that this is because the test tool used in the previous incident was not available to RAs; however, it does not seem to be a great leap to have looked for similar capabilities and problems elsewhere in their issuance process. 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]. This incident is recorded in {{bug|1334377}}.