Changes

{{draft}}

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:

</i></blockquote>

===WoSign Response===

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.

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.

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.

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

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.

On April 3rd, 2015, WoSign was contacted by Google, who were concerned about Baseline Requirements violations in recently-issued certificates from WoSign. Instead of specifying the violations directly, Google asked WoSign to check their certificates against their CPS. The following list of problems is a combination of those found by WoSign themselves and those pointed out later by Google:

WoSign resolved this promptly at the time by a mix of changes to practice and changes to [https://www.wosign.com/policy/wosign-policy-1-2-11.pdf their CPS] (new versions 1.2.10 and 1.2.11).

===Further Comments===

Mozilla [https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes documentation related to auditor errors] states that:

</i></blockquote>

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.

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

===WoSign Response===

[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 72. Richard Wang [https://groups.google.com/d/msg/mozilla.dev.security.policy/yZaJh0KxFUc/6RYlFFQiDAAJ said]: "We checked our system, the certificates issued related using higher level port website control validation is totally 72 certificates. To be clear, those certificates are validated by website control validation method that using other port except 80 and 443."

===Further Comments===

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.

In June 2015, an applicant found some problems with WoSign's free certificate service. There were actually two bugs, which we will denote N1 and N2.

* Recently, the reporter of the issue 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.

===WoSign Response===

[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33.

====Bug N1====

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

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.

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.

WoSign purchased the CA "StartCom" and did not disclose the transaction as a change of ownership, which may violate 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 has issued certificates after January 1st 2016 but backdated the notBefore date to be in December 2015. This has the effect of avoiding the blocks in browsers regarding SHA-1 certs issued after January 1st 2016. The number of certs affected is unknown but probably at least 60.

===WoSign Response===

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.

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. It is possible that WoSign's upcoming report will cover this.

In July 2016, it became clear that there was some problems with the StartEncrypt automatic issuance service recently deployed by the CA StartCom. This was a StartCom-branded service and was not publicised as being able to issue certificates from WoSign. However, 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.

* 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 be able to call WoSign code that WoSign itself had abandoned.

===WoSign Response===

===Further Comments===

* The question of why StartCom was able to trigger certificate-issuance code which WoSign has stopped developing and maintaining is also still open.