Changes

WoSign has since updated their system to use better locking.

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 is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. They explain that there were two bugs which led to the same result - one involving a system which did not understand serial numbers with leading zeroes, and the other a race condition.

This last auditor statement ("follow up action was also conducted to prevent the recurrence of the incident") is relevant given later issues involving duplicate serial numbers.

This issue was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report].

WoSign acted quickly to resolve the issues, but this issue perhaps demonstrates that their CPS was not a definition of their practice, but more a document to be updated post-hoc to match changes made to their operations.

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

It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report.

Looking at their list of misissued domains in the report, this really does mean "any domain". For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. This effectively bypasses domain validation for any attacker who owns a domain of their own.

* An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw, particularly if it's available in a normal workflow.

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

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.

This issue 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".

Mozilla is seeking further information on the details in WoSign's report and will make further comment at a later date.

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].

* This issue does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice.