RE: Incidents involving the CA WoSign

[Richard Wang]

We revoked this certificate, and we know this certificate is for test only.

For transparency, WoSign announced full transparency for all SSL certificate 
from July 5th that post all issued SSL certificate to Google log server, 
browsers can distrust WoSign issued SSL certificate after that day if no SCT 
embedded data in the certificate.

And WoSign even plan to post the code signing certificate and client 
certificate to log server for full transparency for all certificates.

See this news if you missed: 
https://www.wosign.com/english/News/2016_wosign_CT.htm. 

And we plan to setup an free alert service for worldwide users that if any SSL 
certificate for domain you care is issued from any CA, then you can get the 
alert email, this will benfit the ecosystem.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of s...@gmx.ch
Sent: Thursday, August 25, 2016 8:18 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Of course, adding the affected certs to OneCRL should be done immediately.

WoSign also has to be transparent about all (mis) issued certs in the past and 
have to provide this info in the future.
If they can't, I think we may consider if the current certs that are valid for 
3 years should be restricted to a shorter period.

Regards,
Jonas


> For the thread's reference, here's the crt.sh link for the misissued 
> GitHub
> certificate:
>
> https://crt.sh/?id=29647048
>
> Valid for 3 years, for github.com. It's not in OneCRL, CRLset, or 
> Microsoft's disallowedcert.stl.
>
>
>
> On Wed, Aug 24, 2016 at 9:08 AM, Gervase Markham  wrote:
>
>> Taking into account all these incidents and the actions of this CA, 
>> Mozilla is considering what action to take. Your input is welcomed.



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.

 

 

Best Regards,

 

Richard

 

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] 
Sent: Thursday, August 25, 2016 3:50 AM
To: Jeremy Rowley ; Peter Bowen 
; Gervase Markham 
Cc: Richard Wang ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

 

Also, I think the biggest concern is the mis issuance issues were not reported 

to Mozilla but were reported to Google. A failure to report a problem in 

domain validation creates a question of whether the CA can be trusted in the 

future.  Could we boil these incidents down to the following concerns?

 

1) WoSign missued certificates by failing to have adequate security that the 
domain validation could be bypassed using a high level port

 

R: we are searching if we mis-issued any certificate for this case since Google 
just told us to forbid the higher port, not told us any cert mis-issued.

 

2) WoSign should provide clarity on whether the issuance of a StartCom and 
WoSign cert through the same portal should be considered a mis-issuance 

 

R: As we clarified that this port issue is not related StartCom, just the API 
case that we declared, please refer to the previous emails.

 

3) WoSign was permitting higher level domain verification to enable issuance at 
lower level domains (which is now clearly impermissible)

 

R: yes, but we fixed this bug.

 

4) WoSign appears to be backdating certificates to avoid BR compliance and

 

R: AS I said in the Bugzilla, this is not the case, this is API bug that found 
and used by Computest only for two test certificate, not for any normal case. 
We don’t have old equipment customer to require SHA1 certificate.

 

5) WoSign failed to report mis-issuance to Mozilla

 

R: Yes, I agree this is our mistake and never happen again in the future.

 

Jeremy

 

-Original Message-

From: dev-security-policy

[ 

 
mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]

On Behalf Of Jeremy Rowley

Sent: Wednesday, August 24, 2016 1:41 PM

To: Peter Bowen <  pzbo...@gmail.com>; Gervase 
Markham <  g...@mozilla.org>

Cc: Richard Wang <  rich...@wosign.com>;

  
mozilla-dev-security-pol...@lists.mozilla.org

Subject: RE: Incidents involving the CA WoSign

 

That's true. I think WoSign should chime in and provide clarity about what

happened. There's far too many innocent explanations to start crying foul.

 

However, the fact a researcher was able to obtain a cert without proper domain

validation is pretty serious. I'd like to hear more details about how this was

accomplished. Ports 8080 and 8443 aren't that uncommon so penalizing someone

merely for port use seems harsh when there wasn't a policy against it.

 

-Original Message-

From: Peter Bowen [  mailto:pzbo...@gmail.com]

Sent: Wednesday, August 24, 2016 10:45 AM

To: Gervase Markham <  g...@mozilla.org>

Cc: Jeremy Rowley <  
jeremy.row...@digicert.com>;

  
mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang

<  rich...@wosign.com>

Subject: Re: Incidents involving the CA WoSign

 

On Wed, Aug 24, 2016 at 9:30 AM, Gervase Markham <  
g...@mozilla.org> wrote:

> On 24/08/16 17:12, Jeremy Rowley wrote:

>> On incident 2, it sounds like they are both using the same

>> auto-generation script.

> 

> It seems like a bit more than that, doesn't it? Let's presume that

> WoSign did not ship a copy of their intermediate cert's private key to

> StartCom. Therefore, this cert must have been issued on the back end

> by some sort of WoSign system. So either WoSign's back-end issuing

> service has some form of authentication and the StartCom system had

> those credentials (why?), or the WoSign system does not have any form

> of authentication (concerning).

 

I think you are missing the most likely option: CA hosting.  My understanding

is that it is not uncommon that one CA operator contracts with another CA

operator to run a CA on behalf of the first operator.  I don't think it has

been clear what disclosure of this practice is required.  Given that I believe

this is widespread, I assumed that all of the issuing CAs in this case were

operated by the same entity.

 

Thanks,

Peter



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

See previous reply, thanks.


Best Regards,

Richard

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Thursday, August 25, 2016 3:41 AM
To: Peter Bowen ; Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang 

Subject: RE: Incidents involving the CA WoSign

That's true. I think WoSign should chime in and provide clarity about what
happened. There's far too many innocent explanations to start crying foul.

However, the fact a researcher was able to obtain a cert without proper domain
validation is pretty serious. I'd like to hear more details about how this was
accomplished. Ports 8080 and 8443 aren't that uncommon so penalizing someone
merely for port use seems harsh when there wasn't a policy against it.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Wednesday, August 24, 2016 10:45 AM
To: Gervase Markham 
Cc: Jeremy Rowley ;
mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang

Subject: Re: Incidents involving the CA WoSign

On Wed, Aug 24, 2016 at 9:30 AM, Gervase Markham  wrote:
> On 24/08/16 17:12, Jeremy Rowley wrote:
>> On incident 2, it sounds like they are both using the same
>> auto-generation script.
>
> It seems like a bit more than that, doesn't it? Let's presume that
> WoSign did not ship a copy of their intermediate cert's private key to
> StartCom. Therefore, this cert must have been issued on the back end
> by some sort of WoSign system. So either WoSign's back-end issuing
> service has some form of authentication and the StartCom system had
> those credentials (why?), or the WoSign system does not have any form
> of authentication (concerning).

I think you are missing the most likely option: CA hosting.  My understanding
is that it is not uncommon that one CA operator contracts with another CA
operator to run a CA on behalf of the first operator.  I don't think it has
been clear what disclosure of this practice is required.  Given that I believe
this is widespread, I assumed that all of the issuing CAs in this case were
operated by the same entity.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

Yes, correct.

Due to root inclusion problem, WoSign root is cross signed by StartCom since 
2011. And we shared some facility with StartCom like CRL and OCSP distribution 
etc. But not this case, as I declared in the previous email, this is a API 
parameter option that can post data to any server located in any place.

Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, August 25, 2016 12:45 AM
To: Gervase Markham 
Cc: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang 
Subject: Re: Incidents involving the CA WoSign

On Wed, Aug 24, 2016 at 9:30 AM, Gervase Markham  wrote:
> On 24/08/16 17:12, Jeremy Rowley wrote:
>> On incident 2, it sounds like they are both using the same 
>> auto-generation script.
>
> It seems like a bit more than that, doesn't it? Let's presume that 
> WoSign did not ship a copy of their intermediate cert's private key to 
> StartCom. Therefore, this cert must have been issued on the back end 
> by some sort of WoSign system. So either WoSign's back-end issuing 
> service has some form of authentication and the StartCom system had 
> those credentials (why?), or the WoSign system does not have any form 
> of authentication (concerning).

I think you are missing the most likely option: CA hosting.  My understanding 
is that it is not uncommon that one CA operator contracts with another CA 
operator to run a CA on behalf of the first operator.  I don't think it has 
been clear what disclosure of this practice is required.  Given that I believe 
this is widespread, I assumed that all of the issuing CAs in this case were 
operated by the same entity.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

this cert is revoked in the same once it is issued.
Thanks for posting to CT.


Best Regards,

Richard

From: Eric Mill [mailto:e...@konklone.com]
Sent: Thursday, August 25, 2016 12:08 AM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang 

Subject: Re: Incidents involving the CA WoSign

For the thread's reference, here's the crt.sh link for the misissued GitHub 
certificate:

https://crt.sh/?id=29647048

Valid for 3 years, for github.com. It's not in OneCRL, 
CRLset, or Microsoft's disallowedcert.stl.



On Wed, Aug 24, 2016 at 9:08 AM, Gervase Markham 
> wrote:
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 
med.ucf.edu and
mistakenly also applied for www.ucf.edu, which was 
approved. They then
confirmed the problem by using their control of
theiraccount.github.com/theiraccount.github.io
 to get a cert for
github.com, github.io, and 
www.github.io.

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 
ucf.edu cert
still had not been revoked almost a year later.

* The lack of revocation of the ucf.edu 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 

Re: Incidents involving the CA WoSign

[sjw]

Of course, adding the affected certs to OneCRL should be done immediately.

WoSign also has to be transparent about all (mis) issued certs in the
past and have to provide this info in the future.
If they can't, I think we may consider if the current certs that are
valid for 3 years should be restricted to a shorter period.

Regards,
Jonas


> For the thread's reference, here's the crt.sh link for the misissued GitHub
> certificate:
>
> https://crt.sh/?id=29647048
>
> Valid for 3 years, for github.com. It's not in OneCRL, CRLset, or
> Microsoft's disallowedcert.stl.
>
>
>
> On Wed, Aug 24, 2016 at 9:08 AM, Gervase Markham  wrote:
>
>> Taking into account all these incidents and the actions of this CA,
>> Mozilla is considering what action to take. Your input is welcomed.





signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

On Wed, Aug 24, 2016 at 12:40 PM, Jeremy Rowley
 wrote:
> However, the fact a researcher was able to obtain a cert without proper domain
> validation is pretty serious. I'd like to hear more details about how this was
> accomplished. Ports 8080 and 8443 aren't that uncommon so penalizing someone
> merely for port use seems harsh when there wasn't a policy against it.

There was no restriction on ports at all. Any client-specified port
was accepted, and any HTTP-like response it gave back was accepted.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Jeremy Rowley]

Also, I think the biggest concern is the mis issuance issues were not reported 
to Mozilla but were reported to Google. A failure to report a problem in 
domain validation creates a question of whether the CA can be trusted in the 
future.  Could we boil these incidents down to the following concerns?

1) WoSign missued certificates by failing to have adequate security that the 
domain validation could be bypassed using a high level port
2) WoSign should provide clarity on whether the issuance of a StartCom and 
WoSign cert through the same portal should be considered a mis-issuance
3) WoSign was permitting higher level domain verification to enable issuance 
at lower level domains (which is now clearly impermissible)
4) WoSign appears to be backdating certificates to avoid BR compliance and
5) WoSign failed to report mis-issuance to Mozilla

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of Jeremy Rowley
Sent: Wednesday, August 24, 2016 1:41 PM
To: Peter Bowen ; Gervase Markham 
Cc: Richard Wang ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

That's true. I think WoSign should chime in and provide clarity about what
happened. There's far too many innocent explanations to start crying foul.

However, the fact a researcher was able to obtain a cert without proper domain
validation is pretty serious. I'd like to hear more details about how this was
accomplished. Ports 8080 and 8443 aren't that uncommon so penalizing someone
merely for port use seems harsh when there wasn't a policy against it.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Wednesday, August 24, 2016 10:45 AM
To: Gervase Markham 
Cc: Jeremy Rowley ;
mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang

Subject: Re: Incidents involving the CA WoSign

On Wed, Aug 24, 2016 at 9:30 AM, Gervase Markham  wrote:
> On 24/08/16 17:12, Jeremy Rowley wrote:
>> On incident 2, it sounds like they are both using the same
>> auto-generation script.
>
> It seems like a bit more than that, doesn't it? Let's presume that
> WoSign did not ship a copy of their intermediate cert's private key to
> StartCom. Therefore, this cert must have been issued on the back end
> by some sort of WoSign system. So either WoSign's back-end issuing
> service has some form of authentication and the StartCom system had
> those credentials (why?), or the WoSign system does not have any form
> of authentication (concerning).

I think you are missing the most likely option: CA hosting.  My understanding
is that it is not uncommon that one CA operator contracts with another CA
operator to run a CA on behalf of the first operator.  I don't think it has
been clear what disclosure of this practice is required.  Given that I believe
this is widespread, I assumed that all of the issuing CAs in this case were
operated by the same entity.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Jeremy Rowley]

That's true. I think WoSign should chime in and provide clarity about what 
happened. There's far too many innocent explanations to start crying foul.

However, the fact a researcher was able to obtain a cert without proper domain 
validation is pretty serious. I'd like to hear more details about how this was 
accomplished. Ports 8080 and 8443 aren't that uncommon so penalizing someone 
merely for port use seems harsh when there wasn't a policy against it.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Wednesday, August 24, 2016 10:45 AM
To: Gervase Markham 
Cc: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang 

Subject: Re: Incidents involving the CA WoSign

On Wed, Aug 24, 2016 at 9:30 AM, Gervase Markham  wrote:
> On 24/08/16 17:12, Jeremy Rowley wrote:
>> On incident 2, it sounds like they are both using the same
>> auto-generation script.
>
> It seems like a bit more than that, doesn't it? Let's presume that
> WoSign did not ship a copy of their intermediate cert's private key to
> StartCom. Therefore, this cert must have been issued on the back end
> by some sort of WoSign system. So either WoSign's back-end issuing
> service has some form of authentication and the StartCom system had
> those credentials (why?), or the WoSign system does not have any form
> of authentication (concerning).

I think you are missing the most likely option: CA hosting.  My understanding 
is that it is not uncommon that one CA operator contracts with another CA 
operator to run a CA on behalf of the first operator.  I don't think it has 
been clear what disclosure of this practice is required.  Given that I believe 
this is widespread, I assumed that all of the issuing CAs in this case were 
operated by the same entity.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Jeremy,

On 24/08/16 17:12, Jeremy Rowley wrote:
> On incident 0, its unclear whether a cert was actually mis-issued.
> Although they used a higher level port, did the researcher
> successfully bypass WoSign's domain validation process? Is the only
> concern that WoSign permitted higher level ports?

The result of the incident was that a certificate was issued to someone
who did not, in the normally understood sense of the word, have control
of the domain in question. Mozilla feels that even without a specific
injunction in the BRs, CAs should have known that ports > 1024 are not
privileged and not done control checks using them.

The severity of the problem, of course, is a matter for discussion here.

> On incident 2, it sounds like they are both using the same
> auto-generation script. 

It seems like a bit more than that, doesn't it? Let's presume that
WoSign did not ship a copy of their intermediate cert's private key to
StartCom. Therefore, this cert must have been issued on the back end by
some sort of WoSign system. So either WoSign's back-end issuing service
has some form of authentication and the StartCom system had those
credentials (why?), or the WoSign system does not have any form of
authentication (concerning).

> Giving WoSign the benefit of the doubt, it
> sounds like maybe it was a bug in their software that permitted SHA1
> certs not an intentional back-dating issue. Is there any clarity
> around how this worked?

Perhaps WoSign would like to provide some :-)

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Jeremy Rowley]

Gerv, 

On incident 0, its unclear whether a cert was actually mis-issued. Although 
they used a higher level port, did the researcher successfully bypass WoSign's 
domain validation process? Is the only concern that WoSign permitted higher 
level ports?

On incident 1, I agree this was a bad practice and should have been reported. 
I'd love an incident report from WoSign on it. Perhaps it was a language 
barrier in interpreting requirements? 

On incident 2, it sounds like they are both using the same auto-generation 
script. This doesn't sound much different from what ACME is hoping to do. 
Backdating the cert seems sketchy but, as you pointed out, isn't expressly 
against the Mozilla policy or the Baseline Requirements.  Giving WoSign the 
benefit of the doubt, it sounds like maybe it was a bug in their software that 
permitted SHA1 certs not an intentional back-dating issue. Is there any clarity 
around how this worked?

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Gervase Markham
Sent: Wednesday, August 24, 2016 7:08 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
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 med.ucf.edu and mistakenly also applied 
for www.ucf.edu, which was approved. They then confirmed the problem by using 
their control of theiraccount.github.com/theiraccount.github.io to get a cert 
for github.com, github.io, and www.github.io.

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 ucf.edu cert still had not been 
revoked almost a year later.

* The lack of revocation of the ucf.edu 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