Dear all,

This email is the formal reply from WoSign for this 3 incidents.

First, thank you all very much to help WoSign to improve our system security 
that helped the global Internet security.  And I am very sorry deeply for the 
related 33 misissuance certificates subscribers that we like to offer a free EV 
SSL certificates upgrade as compensation after finishing the EV validation.

Second, we are very sorry to all browsers that we don't notify you after the 
incident, this is a mis-understanding problem of the bug report policy. And we 
never do this way again in the future. Now we are very clear that all 
misissuance case and other security incident must revoke the certificate 
instantly and report to all browsers and related parties. We guarantee we will 
do this well in the future.

Third, due to the English language limit, we know we can't understand all 
related international standard that it may have some bugs in the system in the 
past and maybe in the future, so we have logged all issued SSL certificates to 
CT Log servers since July 5th, this is for full transparency, and for easy and 
quickly find out any problems. All browsers can distrust the SSL certificate 
issued by WoSign after July 5th that no SCT data embedded in the certificate. 
And we even plan to log all code signing certificate and all client certificate 
to CT log server for full transparency completely in the future. For current 
case, as promised in this email thread, we will post all issued SSL certificate 
in 2015 to CT log server soon.

For incident 0:
We start to use the higher port website control validation from Jan. 8th, 2015 
since some customer can't use the 80 and 443 port. And we have closed this 
function after getting report from Google at April 24, 2015. 
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. So we think no need to revoke those certificates. 
We posted all those certificates to CT log server for transparency and provided 
the link in this email thread.

For incident 1:
 We checked our system that the mis-issued certificate with un-validated 
subdomain, total 33 certificates. We have posted to CT log server and provided 
the link in this email thread. All certificates are revoked today after 
noticing each subscriber. 
This is a system bug for the rule of adding additional domains to SAN for free, 
the rule is if you validated the domain:, and you apply certificate 
for, then system will add a domain in SAN for free, 
this is for the subscriber convenience that no any problem if the site visitor 
visit and This is no any problem in 
domain control validation, but for website control validation method, it will 
have problem, the code engineer mis-understand this free add-domain policy, 
this is a code bug that we don't find even we revoked some misissuance 
certificate, this bug is fixed completely at Aug. 9th, 2015 system update. 
We classified this 33 misissuance certificate into two types: one type is we 
think this misissuance certificate is obviously not from the domain owner, we 
revoked this type certificates instantly after we know the misissuance; another 
type is, this certificate is a normal order that the subscriber own this 
domain, it is our system bug fault to add a wrong sub-domain to the 
certificate, in order to not interrupt those subscriber's website normal 
operation, we must notice those subscriber first, reissue a correct one for 
this subscriber, then revoke this certificate.     
Considering the website control validation method has potential risk, we have 
closed this method at Aug. 27 even the BR allow this method. There are many 
famous Internet service providers provide subdomain to its customer, we can't 
add all of their domains to our Flag-Block system. So we decided to close this 
validation method, only support domain control validation.
For incident 2:
We declared this big in Bugzilla [4], this is not the case that we want to 
issue backdated SAH1 certificate, this is a bug that used by the test company 
to issued two certificates only. StartCom and WoSign used the same 
auto-generation script, set different parameter to go to different CA API URL. 
Now StartCom and WoSign all decided to use Let Encrypted ACME protocol that it 
will support this case -- one same client software can be used to get 
certificate from different CA, just define the CA parameter.
We revoked this two wrong SHA1 certificate instantly after getting report. And 
we disabled this bug in API, and StartCom stopped StartEncrypt service. 

I wish I say this 3 case clearly, if not, please forgive my bad English, and 
please contact me if you still have any question, thanks a million.

Best Regards,

Richard Wang
WoSign CA Limited

-----Original Message-----
From: Gervase Markham [] 
Sent: Wednesday, August 24, 2016 9:08 PM
Cc: Richard Wang <>
Subject: Incidents involving the CA WoSign

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 audit[1].

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 audit[1].

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