Dear m.d.s.policy,

Several incidents have come to our attention involving the CA "WoSign".
Mozilla is considering what action it should take in response to these
incidents. This email sets out our understanding of the situation.

Before we begin, we note that Section 1 of the Mozilla CA Certificate
Enforcement Policy[0] 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." It is clear to us, and appears to be clear to
other CAs based on their actions, that misissuances where domain control
checks have failed fall into the category of "serious security concern".

Incident 0

On or around 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 (see above).

* This misissuance incident did not turn up on WoSign's subsequent BR

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 certificate for and
mistakenly also applied for, which was approved. They then
confirmed the problem by using their control of to get a cert for,, and

They reported this to WoSign, giving only the Github certificate as an
example. That cert was revoked and the vulnerability was fixed. However
recently, they got in touch with Google to note that the cert
still had not been revoked almost a year later.

* The lack of revocation of the certificate (still unrevoked at
time of writing, although it may have been by time of posting) 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.

* This misissuance incident was not reported to Mozilla by WoSign as it
should have been (see above).

* This misissuance incident did not turn up on WoSign's subsequent BR

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. As well as other problems it had, which are outside the scope
of this discussion, 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.

* The issuance of certificates using SHA-1 has been banned by the
Baseline Requirements since January 1st, 2016. Browsers, including
Firefox, planned to enforce this[2] by not trusting certs with a
notBefore date after that date, but in the case of Firefox the fix had
to be backed out due to web compatibility issues. However, we are
considering how/when to reintroduce it, and CAs presumably know this.

* The issuance of backdated certificates is not forbidden, but is listed
in Mozilla's list of Problematic Practices[3]. 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"[4]. 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.

* This misissuance incident was not reported to Mozilla by WoSign as it
should have been.

Taking into account all these incidents and the actions of this CA,
Mozilla is considering what action to take. Your input is welcomed.

Gerv, Kathleen and Richard

dev-security-policy mailing list

Reply via email to