Changes

This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. ===Further Commentsand Conclusion=== WoSign say that they were aware that they were doing this, and that the cause was a delay in implementing the changes from CAB Forum ballot 118. Ballot 118 was passed on 16th October 2014, but WoSign were unable to update their systems until March 5th 2015, nearly five months later. This seems like a surprisingly long delay for a relatively simple change, given how quickly WoSign have been able to update their systems in other cases.

The fact that WoSign declared this on their audit strongly suggests that WoSign were unaware that they were issuing certificates against a SHOULD NOT (i.e. this was not done after carefully weighing and understanding the full implications) and decided to correct the situation when informed. If they had been doing this in full knowledge of the consequencesHowever, and the extension into 2017 was intentionalas noted above, they would not have agreed to revoke all the certificates before 31st December 2016. So while this is not a BR violation, it speaks to their control over their issuance process.

This issue has been raised is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. They explain that there are 16 examples, and it happens when their Certificate Management System loses contact with WoSigna signing server during a transaction, and so tries the other one, but both signing servers issue a certificate. One was sent to the subscriber, and the other was stored in their records, and we await then logged to CT when they logged all their responsecerts. WoSign has since updated their system to use better locking. ===Further Comments and Conclusions=== Issuing two different certs with the same serial number is a violation of the RFC, but the impact of this bug is minimal.

This issue was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. It has come up This issue is covered in the ensuing discussion in mWoSign's [https://www.dwosign.scom/report/WoSign_Incident_Final_Report_09162016.policy but no additional formal response has been made. It is possible that WoSign's upcoming pdf final incident report will cover this].

This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. ===Further Commentsand Conclusions===

The completeness of WoSign's list of 72 certificates was called into question by a discussion participant who testified that [https://crt.sh/?id=30335331 his certificate] was validated using port 8080 but does not appear in WoSign's list. In response, Richard [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/LVnZBHOGDgAJ said] that in fact their system did not directly record the port used for validation, and so he could not guarantee that the list was complete. However, the final incident report still gives the impression that WoSign was able to generate a complete list. WoSign has since stopped doing website validation; if they had continued, better logging of the process would have been necessary. The logs they were keeping while using this process were clearly inadequate.

===Further Commentsand Conclusions===

* An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw. It is not clear whether , particularly if it was possible to do this 's available in the standard a normal workflow or if it required hacking form parameters. Given the number of misissued certs, the former seems more likely.

There are plenty of ways of testing this scenario without using public roots- and, in fact, WoSign has updated their systems to avoid issuing test certificates from public roots in future.  We note that Symantec was penalised in late 2015 for issuing non-BR-compliant test certificates in their publicly-trusted certificate hierarchies. Their problems were first revealed in September, and one big discussion of these problems happened in m.d.s.policy starting on 13th October 2015. All of these dates are prior to WoSign's test certificate misissuances.

This issue has been raised with is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. Of the 64 certificates they consider, WoSign attribute 6 to a dual-issuance bug, 9 they say are not problematic because they were issued on December 31st 2015, 2 are the mis-issued certs relating to Issue V, and the other 47 are "normal SHA-1 orders". ===Further Comments and Conclusion=== Mozilla is seeking further information on the details in WoSign's report and we await their responsewill make further comment at a later date.

A certificate has been issued in June 2016 to alicdn.com which, it is claimed, was not requested by the owner of that domain. However, it has not yet been possible to confirm that this cert has been misissued because the owner of the private key has not been located. The domains in question currently use certificates from Symantec.

This issue has been raised with is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. WoSign, who are investigating assert that they completed the issue with Alibaba (owner domain control checks correctly. ===Further Comments and Conclusion=== The owners of the alicdn.com have confirmed directly to Mozilla that this incident was caused by an attacker being able to control content on their domain in question). This issuance used  We would have some concerns with how WoSign's systems validated website control validation. However, which they no longer support this method. This "misissuance" was possible only because alicdn.com was, for some period of time, controlled by an attacker. Therefore, no blame can be attributed to WoSign has since stopped doing. We await their fuller responsefor the misissuance itself.

2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report]. This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].

It is important background information to know which WoSign roots are cross-signed by other trusted or previously-trusted roots. The following unexpired and unrevoked cross-signatures are currently known: