Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
Initial draft
{{draft}}
This page lists all confirmed or suspected incidents or issues involving the CA "WoSign". 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].
The incidents are in chronological order, and have been re-numbered from the original announcement to use letters with gaps in between, for possible future expansion.
==Incident D: Long-Lived SHA-1 Certs (Jan - Mar 2015)==
''(a.k.a. "Incident -2")''
Between 16th January 2015 and 5th March 2015, WoSign issued 1,132 SHA-1 certificates whose validity extended beyond 1st January 2017. This is documented in their [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit]. Section 7.1.3 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.3.pdf the BRs] says:
<blockquote><i>
Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA‐1 algorithm with an Expiry Date greater than 1 January 2017.
</i></blockquote>
So this requirement is a SHOULD NOT. [https://tools.ietf.org/html/rfc2119 RFC 2119] states:
<blockquote><i>
4. <b>SHOULD NOT</b> This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
</i></blockquote>
This means that this incident does '''not''' represent a violation of the BRs.
===WoSign Response===
WoSign chose to declare this to their auditors on their WebTrust audit. The auditors state:
<blockquote><i>
We understand that WoSign has established procedures and implemented controls to ensure that the aforementioned SSL subscriber certificates would be revoked on or before 31 December 2016.
</i></blockquote>
===Further Comments===
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 consequences, and the extension into 2017 was intentional, 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.
==Incident F: Certs Identical Except For NotBefore (Mar 2015)==
WoSign issued two certificates in March 2015. These certificates are identical in all ways (including their serial numbers) except for their notBefore dates, which are 37 seconds apart.
* [https://crt.sh/?id=30326062 Cert 1]
* [https://crt.sh/?id=30736090 Cert 2]
===WoSign Response===
WoSign have not yet been formally approached about this, and no response has been given yet in the thread where it was noted in m.d.s.policy.
==Incident H: Duplicate Serial Numbers (Apr 2015)==
''(a.k.a. "Incident X")''
Between 9th April 2015 and 14th April 2015, WoSign issued 392 certificates with duplicate serial numbers. (It is not clear if these were all the same number, or in pairs, or some other combination.) This is documented in their most recent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
===WoSign Response===
The audit report says:
<blockquote><i>
We understand that remediation action was taken by WoSign to revoke those certificates in a timely manner. Incident investigation with root cause analysis was conducted and relevant result was documented in relevant incident report. Follow up action was also conducted to prevent the recurrence of the incident.
</i></blockquote>
===Further Comments===
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.
==Incident J: Various BR Violations (Apr 2015)==
''(a.k.a. "Incident -1")''
On April 5th, 2015 (XXXcheck date), WoSign was contacted by Google about multiple Baseline Requirements violations.
* Their CPS documented one set of policies that their certificates were issued under, but none of their certificates matched their CPS.
* Their certificates included non-verified information unrelated to subscribers as part of the Subject information in the DN, violating section 7.1.4.2 of the BRs.
* Their CPS was inconsistent with the validity period of their certificates in a way that was BR non-compliant.
WoSign CPS is here, although it's not clear if this is pre-fix or post-fix (XXX clarifying with Ryan): https://www.wosign.com/policy/wosign-policy-1-2-10.pdf
===WoSign Response===
This incident was included in Google's report to Mozilla but not listed in the original public discussion. It has come up in the ensuing discussion in m.d.s.policy but no formal response has been made.
==Incident L: Any Port (Jan - Apr 2015)==
''(a.k.a. "Incident 0")''
From Jan 10th to to April 23rd 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.
This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.
* Before the recent passage of Ballot 169 in the CAB Forum, which limits the ports and paths which can be used, the Baseline Requirements said that one acceptable method of domain validation was "Having the Applicant demonstrate practical control over the FQDN by making an agreed‐upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN". This method therefore did not violate the letter of the BRs. However, Mozilla considers the basic security knowledge that ports over 1024 are unprivileged should have led all CAs not to accept validations of domain control on such ports, even when not documented in the BRs.
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed."
* This misissuance incident did not turn up on WoSign's subsequent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
===WoSign Response===
2016-08-25: "[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/kKb2-tKNCgAJ We are searching our database to try to find if any mis-issued cert is issued.]"
2016-08-25: "[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/vanzaHaZCgAJ For BR auditor, I think this issue is too technical that fewer auditor can find out this problem.]"
[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 72.
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report].
===Further Comments===
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.
==Incident N: Subdomain Errors (June 2015)==
''(a.k.a. "Incident 1")''
In June 2015, an applicant found a problem with WoSign's free certificate service, which allowed them to get a certificate for the base domain if they were able to prove control of a subdomain.
The reporter proved the problem in two ways. They accidentally discovered it when trying to get a [https://crt.sh/?id=29805563 certificate] for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of schrauger.github.com/schrauger.github.io to get [https://crt.sh/?id=29647048 a cert] for github.com, github.io, and www.github.io. They also obtained [https://crt.sh/?id=29805567 another github cert] using a different subdomain of github.io.
They reported this to WoSign, giving only the Github certificates as an example. Those certs were revoked and the vulnerability was fixed. However recently, the reporter got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.
* The lack of revocation of the ucf.edu certificate strongly suggests that WoSign either did not or could not search their issuance databases for other occurrences of the same problem. Mozilla considers such a search a basic part of the response to disclosure of a vulnerability which causes misissuance, and expects CAs to keep records detailed enough to make it possible.
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed."
* This misissuance incident did not turn up on WoSign's subsequent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
===WoSign Response===
2016-08-25: "[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/vanzaHaZCgAJ For BR auditor, I think this issue is too technical that fewer auditor can find out this problem.]"
[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33.
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report].
===Further Comments===
WoSign state that there were two bugs in play here.
* One root cause of the problem is given in the official report as: "This mis-issued certificate was a system vulnerability that when the subscriber finished the domain validation, they can add any domain before submitting this order to system." Looking at their list of misissued domains, 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!
* The second root cause is that if www.example.tld is validated, the code gave a cert covering example.tld as well, which is clearly incorrect.
* The report seems to suggest an "issue first, ask questions later" approach whereby a cert is issued to the subscriber even if it is flagged as questionable, and the remediation mechanism is revocation rather than lack of issuance. Furthermore, their validation team works 9-5, so an applicant could have many hours to abuse a misissued certificate before it was discovered.
* Although it seems like the system issued a certificate which did not match what was validated, this was not investigated further. The report says: "the employee treated it as an unusual case that did not reported it as a bug." This is amazing, if true. If WoSign's employees don't think that misissuing a certificate is a big deal, something is quite badly wrong.
* The response seems surprised that the applicant did not follow the WoSign Terms of Use. I would not expect an actual attacker to care about the WoSign Terms of Use.
* The certificate involved here were all clearly misissued; even if the person could have proved control of the parent domain, they did not do so during the process. Therefore, failure to revoke these certificates immediately (as WoSign argued it didn't need to during the public discussion) constitutes a further BR violation, as per Section 4.9.1.1 of the [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf BRs], in particular, item 4 and item 9.
==Incident P: Use of SM2 Algorithm (Nov 2015)==
In November 2015, WoSign issued two certificates that have subject public keys which are for the [https://tools.ietf.org/html/draft-shen-sm2-ecdsa-01 SM2 algorithm]. SM2 is an elliptic-curve-based algorithm but it does not use the US NIST P-256, P-384, or P-521 curves. The CA/Browser Forum Baseline Requirements section 6.1.5 requires that only these three curves be used for elliptic curve keys in certs covered by the BRs.
In addition to including subjects keys using unapproved parameters, it seems these each share their serial number with another certificate for the same subject.
* [https://crt.sh/?id=30773511 1st SM2 cert in crt.sh]; [https://crt.sh/?id=30613201 cert with same serial number in crt.sh]
* [https://crt.sh/?id=30773585 2nd SM2 cert in crt.sh]; [https://crt.sh/?id=30613200 cert with same serial number in crt.sh]
===WoSign Response===
Richard Wang: "This is another case that we will include it in our report. We issued two test cert using SM2 algorithm that used the same serial number as the RSA cert (same subject) to test if we can setup a gateway that install this two type cert, it can shake hand automatically using different cert based on the browser algorithm support." (Unable to find this message in the groups.google.com archive.)
===Further Comments===
There are plenty of ways of testing this scenario without using public roots. Symantec was penalised for issuing non-BR-compliant test certificates in their publicly-trusted certificate hierarchies.
==Incident R: Purchase of StartCom (Nov 2015)==
WoSign purchased the CA "StartCom" and did not disclose the transaction as a change of ownership, in violation of section 5 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla CA Certificate Maintenance Policy]. More details to be provided.
===WoSign Response===
Among other comments:
2016-09-02: [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/AXJoyh4KDQAJ Richard Wang]: "Please don't bind WoSign incident problem with StartCom, it is two independent company that one registered in China and one located in Israel."
===Further Comments===
As well as any issues there may be with the disclosure of the transfer of ownership, the relationship between WoSign and StartCom is also relevant when determining the scope of any sanctions.
==Incident T: alicdn.com Misissuance (June 2016)==
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.
* [https://gist.github.com/xiaohuilam/8589f2dfaac435bae4bf8dfe0984f69e Cert on Github Gist]
* [https://crt.sh/?id=29884704 Cert on crt.sh]
===WoSign Response===
WoSign have not yet been formally approached about this, and no response has been given yet in the thread where it was noted in m.d.s.policy.
==Incident V: StartEncrypt (July 2016)==
''(a.k.a. "Incident 2")''
In July 2016, it became clear that there was some problems with the StartEncrypt automatic issuance service recently deployed by the CA StartCom. In particular, changing a simple API parameter in the POST request on the submission page changed the root certificate to which the resulting certificate chained up. The value "2" made a certificate signed by "StartCom Class 1 DV Server CA", "1" selected "WoSign CA Free SSL Certificate G2" and "0" selected "CA 沃通根证书", another root certificate owned by WoSign and trusted by Firefox.
Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm. (XXX To investigate: did the chain contain some SHA-256 certs?)
* The issuance of certificates using SHA-1 has been banned by the Baseline Requirements since January 1st, 2016. Browsers, including Firefox, are enforcing this - in Firefox's case, for publicly-trusted CAs, since [https://bugzilla.mozilla.org/show_bug.cgi?id=1254667 Firefox 48].
* The issuance of backdated certificates is not forbidden, but is included in [https://wiki.mozilla.org/CA:Problematic_Practices#Backdating_the_notBefore_date Mozilla's list of Problematic Practices]. It says "Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not."
* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "[https://bugzilla.mozilla.org/show_bug.cgi?id=1293366#c3 this date is the day we stop to use this code]". If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.
* It seems clear from publicly available information that StartCom's issuance systems are linked to WoSign's issuance systems in some way. Nevertheless, it should not have been possible for an application for a cert from StartCom to produce a cert signed by WoSign.
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed."
===WoSign Response===
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report].
===Further Comments===
* This incident 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.
* The question of why StartCom was deploying certificate-issuance code which WoSign has stopped developing and maintaining is also still open.
==Other Points of Note==
* While not a violation of any Mozilla policy, WoSign has promised to log all certs to CT after a certain date, and yet has not yet managed to comply with the Chrome CT policy of logging to at least one Google and one non-Google log. Arguably, this speaks to competence.
This page lists all confirmed or suspected incidents or issues involving the CA "WoSign". 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].
The incidents are in chronological order, and have been re-numbered from the original announcement to use letters with gaps in between, for possible future expansion.
==Incident D: Long-Lived SHA-1 Certs (Jan - Mar 2015)==
''(a.k.a. "Incident -2")''
Between 16th January 2015 and 5th March 2015, WoSign issued 1,132 SHA-1 certificates whose validity extended beyond 1st January 2017. This is documented in their [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit]. Section 7.1.3 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.3.pdf the BRs] says:
<blockquote><i>
Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA‐1 algorithm with an Expiry Date greater than 1 January 2017.
</i></blockquote>
So this requirement is a SHOULD NOT. [https://tools.ietf.org/html/rfc2119 RFC 2119] states:
<blockquote><i>
4. <b>SHOULD NOT</b> This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
</i></blockquote>
This means that this incident does '''not''' represent a violation of the BRs.
===WoSign Response===
WoSign chose to declare this to their auditors on their WebTrust audit. The auditors state:
<blockquote><i>
We understand that WoSign has established procedures and implemented controls to ensure that the aforementioned SSL subscriber certificates would be revoked on or before 31 December 2016.
</i></blockquote>
===Further Comments===
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 consequences, and the extension into 2017 was intentional, 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.
==Incident F: Certs Identical Except For NotBefore (Mar 2015)==
WoSign issued two certificates in March 2015. These certificates are identical in all ways (including their serial numbers) except for their notBefore dates, which are 37 seconds apart.
* [https://crt.sh/?id=30326062 Cert 1]
* [https://crt.sh/?id=30736090 Cert 2]
===WoSign Response===
WoSign have not yet been formally approached about this, and no response has been given yet in the thread where it was noted in m.d.s.policy.
==Incident H: Duplicate Serial Numbers (Apr 2015)==
''(a.k.a. "Incident X")''
Between 9th April 2015 and 14th April 2015, WoSign issued 392 certificates with duplicate serial numbers. (It is not clear if these were all the same number, or in pairs, or some other combination.) This is documented in their most recent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
===WoSign Response===
The audit report says:
<blockquote><i>
We understand that remediation action was taken by WoSign to revoke those certificates in a timely manner. Incident investigation with root cause analysis was conducted and relevant result was documented in relevant incident report. Follow up action was also conducted to prevent the recurrence of the incident.
</i></blockquote>
===Further Comments===
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.
==Incident J: Various BR Violations (Apr 2015)==
''(a.k.a. "Incident -1")''
On April 5th, 2015 (XXXcheck date), WoSign was contacted by Google about multiple Baseline Requirements violations.
* Their CPS documented one set of policies that their certificates were issued under, but none of their certificates matched their CPS.
* Their certificates included non-verified information unrelated to subscribers as part of the Subject information in the DN, violating section 7.1.4.2 of the BRs.
* Their CPS was inconsistent with the validity period of their certificates in a way that was BR non-compliant.
WoSign CPS is here, although it's not clear if this is pre-fix or post-fix (XXX clarifying with Ryan): https://www.wosign.com/policy/wosign-policy-1-2-10.pdf
===WoSign Response===
This incident was included in Google's report to Mozilla but not listed in the original public discussion. It has come up in the ensuing discussion in m.d.s.policy but no formal response has been made.
==Incident L: Any Port (Jan - Apr 2015)==
''(a.k.a. "Incident 0")''
From Jan 10th to to April 23rd 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.
This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.
* Before the recent passage of Ballot 169 in the CAB Forum, which limits the ports and paths which can be used, the Baseline Requirements said that one acceptable method of domain validation was "Having the Applicant demonstrate practical control over the FQDN by making an agreed‐upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN". This method therefore did not violate the letter of the BRs. However, Mozilla considers the basic security knowledge that ports over 1024 are unprivileged should have led all CAs not to accept validations of domain control on such ports, even when not documented in the BRs.
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed."
* This misissuance incident did not turn up on WoSign's subsequent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
===WoSign Response===
2016-08-25: "[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/kKb2-tKNCgAJ We are searching our database to try to find if any mis-issued cert is issued.]"
2016-08-25: "[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/vanzaHaZCgAJ For BR auditor, I think this issue is too technical that fewer auditor can find out this problem.]"
[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 72.
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report].
===Further Comments===
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.
==Incident N: Subdomain Errors (June 2015)==
''(a.k.a. "Incident 1")''
In June 2015, an applicant found a problem with WoSign's free certificate service, which allowed them to get a certificate for the base domain if they were able to prove control of a subdomain.
The reporter proved the problem in two ways. They accidentally discovered it when trying to get a [https://crt.sh/?id=29805563 certificate] for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of schrauger.github.com/schrauger.github.io to get [https://crt.sh/?id=29647048 a cert] for github.com, github.io, and www.github.io. They also obtained [https://crt.sh/?id=29805567 another github cert] using a different subdomain of github.io.
They reported this to WoSign, giving only the Github certificates as an example. Those certs were revoked and the vulnerability was fixed. However recently, the reporter got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.
* The lack of revocation of the ucf.edu certificate strongly suggests that WoSign either did not or could not search their issuance databases for other occurrences of the same problem. Mozilla considers such a search a basic part of the response to disclosure of a vulnerability which causes misissuance, and expects CAs to keep records detailed enough to make it possible.
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed."
* This misissuance incident did not turn up on WoSign's subsequent [https://cert.webtrust.org/SealFile?seal=2019&file=pdf BR audit].
===WoSign Response===
2016-08-25: "[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/vanzaHaZCgAJ For BR auditor, I think this issue is too technical that fewer auditor can find out this problem.]"
[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33.
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report].
===Further Comments===
WoSign state that there were two bugs in play here.
* One root cause of the problem is given in the official report as: "This mis-issued certificate was a system vulnerability that when the subscriber finished the domain validation, they can add any domain before submitting this order to system." Looking at their list of misissued domains, 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!
* The second root cause is that if www.example.tld is validated, the code gave a cert covering example.tld as well, which is clearly incorrect.
* The report seems to suggest an "issue first, ask questions later" approach whereby a cert is issued to the subscriber even if it is flagged as questionable, and the remediation mechanism is revocation rather than lack of issuance. Furthermore, their validation team works 9-5, so an applicant could have many hours to abuse a misissued certificate before it was discovered.
* Although it seems like the system issued a certificate which did not match what was validated, this was not investigated further. The report says: "the employee treated it as an unusual case that did not reported it as a bug." This is amazing, if true. If WoSign's employees don't think that misissuing a certificate is a big deal, something is quite badly wrong.
* The response seems surprised that the applicant did not follow the WoSign Terms of Use. I would not expect an actual attacker to care about the WoSign Terms of Use.
* The certificate involved here were all clearly misissued; even if the person could have proved control of the parent domain, they did not do so during the process. Therefore, failure to revoke these certificates immediately (as WoSign argued it didn't need to during the public discussion) constitutes a further BR violation, as per Section 4.9.1.1 of the [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf BRs], in particular, item 4 and item 9.
==Incident P: Use of SM2 Algorithm (Nov 2015)==
In November 2015, WoSign issued two certificates that have subject public keys which are for the [https://tools.ietf.org/html/draft-shen-sm2-ecdsa-01 SM2 algorithm]. SM2 is an elliptic-curve-based algorithm but it does not use the US NIST P-256, P-384, or P-521 curves. The CA/Browser Forum Baseline Requirements section 6.1.5 requires that only these three curves be used for elliptic curve keys in certs covered by the BRs.
In addition to including subjects keys using unapproved parameters, it seems these each share their serial number with another certificate for the same subject.
* [https://crt.sh/?id=30773511 1st SM2 cert in crt.sh]; [https://crt.sh/?id=30613201 cert with same serial number in crt.sh]
* [https://crt.sh/?id=30773585 2nd SM2 cert in crt.sh]; [https://crt.sh/?id=30613200 cert with same serial number in crt.sh]
===WoSign Response===
Richard Wang: "This is another case that we will include it in our report. We issued two test cert using SM2 algorithm that used the same serial number as the RSA cert (same subject) to test if we can setup a gateway that install this two type cert, it can shake hand automatically using different cert based on the browser algorithm support." (Unable to find this message in the groups.google.com archive.)
===Further Comments===
There are plenty of ways of testing this scenario without using public roots. Symantec was penalised for issuing non-BR-compliant test certificates in their publicly-trusted certificate hierarchies.
==Incident R: Purchase of StartCom (Nov 2015)==
WoSign purchased the CA "StartCom" and did not disclose the transaction as a change of ownership, in violation of section 5 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla CA Certificate Maintenance Policy]. More details to be provided.
===WoSign Response===
Among other comments:
2016-09-02: [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/AXJoyh4KDQAJ Richard Wang]: "Please don't bind WoSign incident problem with StartCom, it is two independent company that one registered in China and one located in Israel."
===Further Comments===
As well as any issues there may be with the disclosure of the transfer of ownership, the relationship between WoSign and StartCom is also relevant when determining the scope of any sanctions.
==Incident T: alicdn.com Misissuance (June 2016)==
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.
* [https://gist.github.com/xiaohuilam/8589f2dfaac435bae4bf8dfe0984f69e Cert on Github Gist]
* [https://crt.sh/?id=29884704 Cert on crt.sh]
===WoSign Response===
WoSign have not yet been formally approached about this, and no response has been given yet in the thread where it was noted in m.d.s.policy.
==Incident V: StartEncrypt (July 2016)==
''(a.k.a. "Incident 2")''
In July 2016, it became clear that there was some problems with the StartEncrypt automatic issuance service recently deployed by the CA StartCom. In particular, changing a simple API parameter in the POST request on the submission page changed the root certificate to which the resulting certificate chained up. The value "2" made a certificate signed by "StartCom Class 1 DV Server CA", "1" selected "WoSign CA Free SSL Certificate G2" and "0" selected "CA 沃通根证书", another root certificate owned by WoSign and trusted by Firefox.
Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm. (XXX To investigate: did the chain contain some SHA-256 certs?)
* The issuance of certificates using SHA-1 has been banned by the Baseline Requirements since January 1st, 2016. Browsers, including Firefox, are enforcing this - in Firefox's case, for publicly-trusted CAs, since [https://bugzilla.mozilla.org/show_bug.cgi?id=1254667 Firefox 48].
* The issuance of backdated certificates is not forbidden, but is included in [https://wiki.mozilla.org/CA:Problematic_Practices#Backdating_the_notBefore_date Mozilla's list of Problematic Practices]. It says "Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not."
* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "[https://bugzilla.mozilla.org/show_bug.cgi?id=1293366#c3 this date is the day we stop to use this code]". If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.
* It seems clear from publicly available information that StartCom's issuance systems are linked to WoSign's issuance systems in some way. Nevertheless, it should not have been possible for an application for a cert from StartCom to produce a cert signed by WoSign.
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed."
===WoSign Response===
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report].
===Further Comments===
* This incident 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.
* The question of why StartCom was deploying certificate-issuance code which WoSign has stopped developing and maintaining is also still open.
==Other Points of Note==
* While not a violation of any Mozilla policy, WoSign has promised to log all certs to CT after a certain date, and yet has not yet managed to comply with the Chrome CT policy of logging to at least one Google and one non-Google log. Arguably, this speaks to competence.
