CA:WoSign Issues

This page lists all confirmed or suspected 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 Gerv.

The issues are in chronological order, and have been re-numbered from the original announcement to use letters with gaps in between, for possible future expansion.

Issue D: Long-Lived SHA-1 Certs (Jan - Mar 2015)

(a.k.a. "Issue -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 BR audit. Section 7.1.3 of the BRs says:

Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA‐1 algorithm with an Expiry Date greater than 1 January 2017.

So this requirement is a SHOULD NOT. RFC 2119 states:

4. SHOULD NOT 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.

This means that this issue 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:

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.

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.

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

WoSign Response

This issue has been raised with WoSign, and we await their response.

Issue H: Duplicate Serial Numbers (Apr 2015)

(a.k.a. "Issue X")

Between 9th April 2015 and 14th April 2015, WoSign issued 392 certificates with duplicate serial numbers, across a handful of different serial numbers. Here is one example. This is documented in their most recent BR audit.

WoSign Response

The audit report says:

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.

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.

Issue J: Various BR Violations (Apr 2015)

(a.k.a. "Issue -1")

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:

• Incorrect or missing policy OIDs in all or most subscriber certificates;
• CPS required use of obscure "Issuer Alternative Name" field which was not being used;
• Inclusion of information in the Subject of the certificate (an advert) which was not validated subscriber information, and which contained a domain name, violating section 7.1.4.2 of the BRs;
• The CPS documentation of validity periods did not match what was happening in practice;
• CPS required compliance only with RFC 2459 instead of the more restrictive RFC 5280.

Google noted that many of these issues should have been caught by a competent auditor. WoSign's auditors at the time were Ernst and Young (Hong Kong).

WoSign Response

WoSign resolved this promptly at the time by a mix of changes to practice and changes to their CPS (new versions 1.2.10 and 1.2.11).

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 in the ensuing discussion in m.d.s.policy but no additional formal response has been made. It is possible that WoSign's upcoming report will cover this.

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.

Mozilla documentation related to auditor errors states that:

When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. If the auditor fails to assure Mozilla that they have corrected the deficiencies in their auditing process, then their standing as a trusted auditor for the Mozilla root program may be jeopardized.

As Mozilla was not aware of this issue at the time, we were unable to make a judgement on whether these issues rose to an appropriate level of severity to require this response.

Issue L: Any Port (Jan - Apr 2015)

(a.k.a. "Issue 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 issue was not reported to Mozilla by WoSign as it should have been. Section 1 of the 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 issue did not turn up on WoSign's subsequent BR audit.

WoSign Response

2016-08-25: "We are searching our database to try to find if any mis-issued cert is issued."

2016-08-25: "For BR auditor, I think this issue is too technical that fewer auditor can find out this problem."

List of crt.sh links to certificates involved - total 72. Richard Wang 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."

2016-09-04: Official issue 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.

The completeness of WoSign's list of 72 certificates was called into question by a discussion participant who testified that his certificate was validated using port 8080 but does not appear in WoSign's list. In response, Richard 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.

Issue N: Additional Domain Errors (June 2015)

(a.k.a. "Issue 1")

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.

Bug N1 was an issue where someone proving control of <subdomain>.example.tld also was given a cert covering example.tld.

Bug N2 was an issue where arbitrary domains can be added to an existing request after validation.

The reporter proved that there was a problem in two ways. They accidentally discovered that there was a problem when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then used their control of schrauger.github.com/schrauger.github.io to get a cert for github.com, github.io, and www.github.io. They also obtained another github cert using a different subdomain of github.io. These are both, in fact, instances of bug N2.

They reported this to WoSign, giving only the Github certificates as an example. Those certs were revoked. However, no further investigation was performed, and several other certificates were misissued subsequently. The bugs were fixed two months later, on August 10th, in an unrelated major update.

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

• The misissuance issue was not reported to Mozilla by WoSign as it should have been. Section 1 of the 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 issue did not turn up on WoSign's subsequent BR audit.

WoSign Response

2016-08-25: "For BR auditor, I think this issue is too technical that fewer auditor can find out this problem."

List of crt.sh links to certificates involved - total 33.

2016-09-04: Official issue report. The report explains the two bugs, N1 and N2. WoSign classifies the misissuances as 21 N1 and 12 N2. However, they have misclassified at least one - line 2 of Figure 14 - so the actual split may be different.

Bug N1

N1 allowed an applicant to get a certificate for the base domain if they were able to prove control of any subdomain. According to WoSign, this was caused by an engineer misunderstanding the rule that if a base domain was validated, the "www" variant could be added for free. He instead applied the rule in the other direction.

Bug N2

Issue N2 is described in the report as follows:

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 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. It is not clear whether it was possible to do this in the standard workflow or if it required hacking form parameters. Given the number of misissued certs, the former seems more likely.

• 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 report 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 BRs, in particular, item 4 and item 9.

Issue P: Use of SM2 Algorithm (Nov 2015)

In November 2015, WoSign issued two certificates that have subject public keys which are for the 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.

Secondly, for the first pair of certs, the validity period is 4 years, which is 9 months longer than allowed by the BRs.

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

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.

Issue R: Purchase of StartCom (Nov 2015)

WoSign purchased the CA "StartCom" and did not disclose the transaction as a change of ownership, which may violate section 5 of the Mozilla CA Certificate Maintenance Policy. More details to be provided.

Issue S: Backdated SHA-1 Certs (January 2016)

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.

The three certificates below have notBefore dates in Dec 2015, have signatures over SHA-1 hashes and have embedded SCTs which are dated after January 1, 2016.

Because these SCTs are embedded, they must have been created before the final certificate was signed, and therefore the final certificate must have been signed in January - on or after January 18th, for the third one.

These are the only certs for which cryptographic proof of backdating is available. However, other strong circumstantial evidence suggests that backdating is more prevalent.

Firstly, note that the above certs all have the same notAfter date, which is not exactly 1 year (or any other standard time period) after the notBefore. And the notBefore date is some time between midnight and midnight on December 20th 2015, China time (+0800). (This pattern fits a system where code adjusted the date, but not the time, prior to issuance.) If we look for other certs matching this pattern, we find a total of 62 certificates in crt.sh and other sources. Here are five more examples: 1, 2, 3, 4, 5.

Secondly, the ID of certificates in WoSign's CT log can be used to show the logging sequence of a set of certificates even if they don't have embedded SCTs, because the IDs are sequential. If you order all certs in WoSign's log by ID, up to ID 109149, where the notBefore is on December 31st, the notBefore values are (approximately) chronologically ordered. Those which have embedded SCTs have timestamps which are about 2 hours later than the notBefore date. But after that follow 64 certificates which are all dated on December 20, 2015 (CST, UTC+8). This suggests that these were logged at the actual time of issuance but that time is not reflected in their notBefore date - i.e. they were backdated. And it further suggests that this behaviour only began after December 31st 2015, i.e. it was not a continuation of some previous behaviour.

Thirdly, some certificates which are suspected to be backdated were issued at the same time as SHA-256 certificates for the same domain; the timestamps on the SHA-256 certificates are more likely to be the accurate ones. One example is for congfubao.com, where there is a SHA-256 cert with a notBefore of 5th January and an SCT timestamp of 5th January, 17 seconds later than the SCT timestamp in the backdated SHA-1 cert. The simplest explanation is that both certs were issued together, on January 5th. Other pairs include for ebank.pcnkbank.com (SHA-1, SHA-256) and mail.gd.gov.cn (SHA-1, SHA-256).

Lastly, of the 62 suspect certs, are three more certs with embedded SCTs where the gap between the notBefore date and the SCT date is multiple days (i.e. they were backdated) but where the SCT date is nevertheless before 1st January 2016, which means the backdating does not have the effect of avoiding browser blocks.

The issuance of backdated certificates is not forbidden by Mozilla policy, but is included in 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."

The Baseline Requirements, section 7.1.3, say:

Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA‐1 hash algorithm.

(Thanks to Thijs Alkemade of Computest for much of the information in this section.)

WoSign Response

This issue has been raised with WoSign, and we await their response.

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

WoSign Response

This issue has been raised with WoSign, and we await their response.

Issue V: StartEncrypt (July 2016)

(a.k.a. "Issue 2")

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 intermediate/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.

A security investigator used the value "1", and acquired two certificates which had notBefore dates (usage start date) of 20th December 2015, and which were signed using the SHA-1 checksum algorithm. Cert 1, Cert 2.

• 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 Firefox 48, released on 1st August 2016.

• The issuance of backdated certificates is not forbidden, but is included in 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 "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.

• The misissuance issue was not reported to Mozilla by WoSign as it should have been. Section 1 of the 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: Official issue 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.

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

Cross Signing

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