Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
First set of updates from Symantec
{{draft}}
This page is having updates from Symantec integrated, and so is not currently complete. Check back tomorrow.
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 [mailto:gerv@mozilla.org Gerv].
===Symantec Response===
It took quite a while for the full scale of the problem to emerge, and Symantec had to publish numerous updates to their "Final Report". Symantec released a number of documents relating to this - [https://bugzilla.mozilla.org/attachment.cgi?id=8852861 Final Report], [https://bugzilla.mozilla.org/attachment.cgi?id=8852862 Final Report v2], [https://bugzilla.mozilla.org/attachment.cgi?id=8852863 Final Report v3], [https://bugzilla.mozilla.org/attachment.cgi?id=8852864 list of certs containing owned domains], [[Media:TestCertificateIncidentReportUnregisteredv2.pdf|list of certs containing unregistered domains]], [https://www.symantec.com/page.jsp?id=test-certs-update further update]. They also issued a blog post, "[http://archive.is/Ro70U A Tough Day As Leaders]", which is no longer on their website but has been archived. It indicates that 3 employees were fired as a result of the misissuance. They posted another page with "[https://www.symantec.com/page.jsp?id=test-certs-update# complete investigation results]".
In their report, Symantec wrote:
===Symantec Response===
Symantec fixed the issue within a week, audited their logs to make sure the flaw had not been abused, and issued a [https://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20160204_00 security advisory]. They have [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Jj9ZpMs-pWM said] they have no further comment.
===Further Comments and Conclusion===
===Symantec Response===
Each of the documents contains, in a following table, Symantec's comments on the qualifications and what they have done or are doing to remedy them. They have [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/8Z2uE1sGaO0 said] that they have no further comment.
===Further Comments and Conclusion===
===Symantec Response===
Symantec [https://cabforum.org/pipermail/public/2016-January/006519.html self-reported this issue] to the CAB Forum public mailing list, and recently [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ueV_q7Js4Sk stated] that they have no further comment.
===Further Comments and Conclusion===
==Issue J: SHA-1 Issuance After Deadline, Again (February 2016)==
Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 CT precertificate] in February 2016. They then seemed to claim that misissuance of a pre-certificate is not misissuance. (The CT RFC states that issuance of a pre-certificate is considered equivalent to issuance of the certificate, and so Mozilla considers that pre-certificate misissuance is misissuance) although they now acknowledge that it was.)
===Symantec Response===
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.
</blockquote>
They have also produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Jj9ZpMs-pWM more detailed explanation] of the events, including details of the remediation steps taken.
===Further Comments and Conclusion===
Symantec is not the only CA to have done this; IdenTrust [https://crt.sh/?id=9114292 also did it on multiple occasions] from 2011-01-14 onwards. I don't believe there are any unexpired unrevoked (by OneCRL) links between the FPKI and the Mozilla trust store any more, via any CA.
Symantec appear not to have been aware that this would lead to certificates from the FPKI being trusted in browsers until around the time it was [https://github.com/18F/fpki-testing/issues/1 drawn to their attention] by Eric Mill in February 2016.
===Symantec Response===
When this was drawn to their attention, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/OAJD-tWBAAAJ did not revoke] the cross-sign certificate under discussion, instead allowing it to expire (less than a month later).
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/KKqGmzQIOno claim] that the problem is with browsers not processing certificate policy extensions which are used within the FPKI. When they realised the problem, they negotiated with the FPKI to allow the relevant cross-cert to expire rather than renewing it.
==Issue N: Premature Manual Signing Using SHA-1 (July 2016)==
Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ self-reported] this issue to Mozilla. Their remediation was to revoke all of those certificates, and issue new ones after permission was granted.
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/UnTJ1AfCT7U state]:
<blockquote>
This matter represents the first time any CA attempted to follow the exception process which was developed over the course of weeks, beginning at the Bilbao CABF face-to-face meeting in May 2016, and with the input of our partners. Google initially proposed this exception process, which was later modified following input from other CABF members. Our internal process did not clearly specify to our PKI Operations team to stop at the point of TBS creation, which subsequently resulted in the creation of signed certificates instead of TBS Certificates. Importantly, our audit process promptly identified the error, and Symantec never released the certificates. We also promptly improved our internal process.
</blockquote>
==Issue P: UniCredit Sub CA Failing To Follow BRs (April - October 2016)==
Symantec's initial response was to get UniCredit to put in place controls to fix the violations found, and to review and replace any affected certificates. However, they continued to be without an audit. Symantec eventually asked them for one, and when they were unable to produce (presumably, pass) one, ordered them to stop issuing. However they continued, in violation of that agreement. Symantec then finally revoked their intermediate.
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/CkMpJbuTGOI admit] that the omission of UniCredit from their CA Communication response was an oversight. They further state:
<blockquote>
We worked with UniCredit over a long period of time to enforce their compliance with audit requirements. In July 2016, we received an assessment that did not meet WebTrust audit standards. We then took action, helping UniCredit transition to a managed PKI solution for their certificate needs that did not require an audit. In parallel, we notified them of termination of their subordinate CA.
Because our customers are our top priority, we attempted to minimize business disruption while they transitioned by permitting UniCredit to operate only its CRL service until November 30, 2016, at which point we would revoke the UniCredit subordinate CA. In October 2016, UniCredit issued one new certificate in violation of the terms of that transition plan. Following that, Symantec promptly revoked the UniCredit subordinate CA on October 18, 2016.
</blockquote>
==Issue Q: Symantec Audit Issues 2016 (December 2015 - November 2016)==
Each of the documents contains, in a following table, Symantec's comments on the qualifications and what they have done or are doing to remedy them.
Symantec recently [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0dOt9JDsE0k stated]: "In our 2014-2015 audits, certain issues were identified that we promptly took action on, including addressing the test certificate incident. We continued these efforts until the Point in Time audit was conducted." There are [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/aSkYsaiJ0M8 questions outstanding] regarding the timeline here.
==Issue R: Insecure Issuance API (2013 or earlier - November 2016)==
Instead, Symantec decided to shut down the RA program entirely and re-assess every certificate issued under it. Symantec committed to revalidating all of the CrossCert-issued certificates (10,000+) and any of the 20,000+ certificates issued by their other 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.
Symantec has produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/dVMxrUVygS0 further, long account] of the situation. It confirms that, while there were multiple systems designed to teach the RAs what to do, the only system which checked that they were actually doing it (and which Symantec paid attention to) were the WebTrust audits. They disagree that full revocation of all certs is a proportionate response.
===Further Comments and Conclusion===
There are five customers mentioned in the audits, and Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70 say] they are [https://crt.sh/?sha1=924b357fc7b9d8c9d26e41d4af4dc6c4babe90e5 Intel], [https://crt.sh/?id=Issue V33549 Aetna], [https: RA Program Audit Issues (2013 or earlier - January 2017)//crt.sh/?CN=UniCredit+Subordinate+External UniCredit], [https://crt.sh/?CN=Google+Internet+Authority+G2 Google] and [https://crt.sh/?CN=Apple+IST+CA%25 Apple]. They also say:
<blockquote>Separately, Symantec's RAs appear to have operates two subordinate CAs solely for NTT DoCoMo in an enterprise PKI application. These subordinate CAs had a history been considered part of poor compliance with the BRs "GeoRoot" program as well, and other audit requirements, facts which were known we had therefore excluded them (similar to the above externally operated ones) from the list of Symantec but not disclosed to Mozilla or dealt with CAs in our audits. After reviewing our approach, our compliance team determined that they should be included going forward. As such, for the 2016-2017 Period in Time, these subordinate CAs are included in appropriately comprehensive waysthe GeoTrust WebTrust for CA and BR audits.</blockquote>
We currently know of four RAs who were in Symantec's program - CrossCert, Certisign, Certsuperior, and Certisur.
===Symantec Response===
Symantec has not yet been officially requested [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/B3Pcag-afJI state]: <blockquote>The only Symantec RAs capable of authorizing and issuing publicly trusted SSL/TLS certificates are: CrossCert, Certisign, Certsuperior and Certisur. Symantec continues to respond to this issuemaintain a partner program for non-TLS certificates. E-Sign SA and MSC Trustgate are amongst these partners.</blockquote>
