Re: Comodo issued a certificate for an extension

[Gervase Markham]

On 11/11/16 15:43, Nick Lamb wrote:
> My review (based on what I saw posted to CA/B mailing lists)
> suggested
> that there isn't active patent uncertainty at all for some Ballot 169
> methods. I would welcome more information if you have some.

Well, if previous IPR disclosures are, in fact, invalid, then we cannot
assume that they are complete.

> I saw documents citing patents which might be infringed by implementing 
> methods
> 3.2.2.4.1 through 4, plus numbers 7 and 8. This leaves, seemingly unpatented
> 
> 3.2.2.4.5 Domain Authorization Document
> 3.2.2.4.6 Agreed-Upon Change to Website
> 3.2.2.4.9 Test Certificate
> 3.2.2.4.10. TLS Using a Random Number

But even if they are complete, I believe this is incorrect - one CA
asked for method 9 to be moved from ballot 181 to ballot 182, implying
that they might perhaps have a patent that covered it.

Gerv


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

Re: Comodo issued a certificate for an extension

[Gervase Markham]

On 10/11/16 19:52, Robin Alden wrote:
> To avoid suggestions of weasel-words around the CA/B forum's struggle with
> their IP policy my understanding is that at least Microsoft, and I hope
> other browsers too, will incorporate the Ballot 169 wording into their
> policy regardless of whether the CA/B has ratified it by then.

If Microsoft are going to do this, maybe it's a moot point, but my
current feeling is that requiring CAs to implement exactly one of the
methods from ballot 169, at a time when all methods are under a greater
or smaller IPR uncertainty cloud, would put CAs who would need to make
changes at risk of an unknowing IPR infringement. So our current plan is
not to require this. However, comments on this viewpoint are welcomed.

Our preference is that CAs who are not using "any other method" don't
start using it, and CAs which are using it don't invent new "any other
method" schemes between now and when they stop using "any other method"
altogether. But this view is somewhat difficult to encode in policy.

Gerv

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

Re: Comodo issued a certificate for an extension

[Nick Lamb]

On Thursday, 10 November 2016 19:53:25 UTC, Robin Alden  wrote:
> I can't speak to your assumptions, but I concede that it is not explicit in
> the CPS.
> 
> It is now documented at
> https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
> and in the knowledgebase article at:
> https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
> rnative-methods-of-domain-control-validation-dcv

Thanks Robin. And also for your definitive statement in the other post.

A brief comment on the API document (the PDF):

In section 3, HTTP Based DCV, an example is given and the hexadecimal values 
shown are the same for both the MD5 and SHA-1 hashes. Of course this would 
never happen in a real system, not least because the hashes are of different 
lengths. It would probably be clearer as an example if this was corrected (I 
assume the actual implementation is correct).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Comodo issued a certificate for an extension

[Robin Alden]

Nick Lamb, on 02 October 2016 17:50, said..
> The first thing that jumps out at me from their report is that they
mistake .sb
> for a gTLD when it is actually a ccTLD.

That was a mistake in writing the report.
The point is that it is a TLD.

> The second thing obviously is that they do have exactly the "rule" Richard
> Wang described, and they believe this was justified under the BRs old
3.2.2.4
> method 7 (which isn't a method at all, it's basically a catch-all).
> 
> I examined the Comodo CPS and wasn't able to find any mention of this
rule.
> Indeed based on the CPS I would have assumed that control over a website
> www.example.com would under no circumstances be sufficient to get a
> certificate for the name example.com from Comodo and I would be grateful
> if anyone can point me to where they have written that it is.
> 

I can't speak to your assumptions, but I concede that it is not explicit in
the CPS.

It is now documented at
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
and in the knowledgebase article at:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
rnative-methods-of-domain-control-validation-dcv

Regards
Robin Alden
Comodo

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

RE: Comodo issued a certificate for an extension

[Robin Alden]

Eric Mill, on 03 October 2016 03:14, said..
> On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb  wrote:
> > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen  wrote:
> > > There is some good news.  The CA/Browser Forum has already addressed
> > > this, even prior to the current discussions. Ballot 169
> > > (https://cabforum.org/2016/08/05/ballot-169-revised-
> > validation-requirements/)
> > > revises 3.2.2.4 considerably.
> >
> > I'm aware of Ballot 169
> >
> > > Under the new rules, which should be in
> > > effect as of 1 March 2017, validating www. will not be a valid
> > > method of showing control of .  The name is true for any valid
> > > hostname under .  The only note is that names in the form
> > > _. (that is starting with an underscore) can be
> > > used to validate .
> >
> > I wish I shared your confidence. My expectation is that if we leave this
> > as it is, in April 2017 subscribers will still be able to get a
certificate
> > issued using this lackadaisical validation, and the issuing CA will say
> > they feel it's not "really" disobeying the rules, that it's just a
> > "technicality" and anyway what's the harm, it's so much more convenient
> for
> > their customers this way?
> >
> > Comodo's document never actually says that they're abolishing this
"rule"
> > as a result of Ballot 169. It lets you choose to draw that implication,
by
> > specifying that their current practices pre-date Ballot 169's changes,
but
> > it never says as much. Hence I think Mozilla's rep should take this to
> > CA/B, or it should go in one of the bulk CA communications, to find out
at
> > least how widespread the crazy is and whether it's even consistent in
how
> > it works from one CA to the next.
> >
> 
> It would be nice for Comodo to make it explicit that this practice will
> cease when Ballot 169 takes effect, and the lack of an explicit update
> jumped out at me immediately when I read it. But the BRs post-169 seem
> crystal clear on this, and I don't think CAs would be able to write off
> this practice as a technicality or misinterpretation.
> 
> -- Eric

I'm happy to state definitively that this practice will cease when Ballot
169 takes effect.

To avoid suggestions of weasel-words around the CA/B forum's struggle with
their IP policy my understanding is that at least Microsoft, and I hope
other browsers too, will incorporate the Ballot 169 wording into their
policy regardless of whether the CA/B has ratified it by then.

Comodo will have implemented some or all of the new validation methods
described in Ballot 169 before 1 March 2017.
Comodo will be withdrawing any and all validation methods which do not
conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7
'any-other-equivalent method' rule before 1 March 2017.

Regards
Robin Alden
Comodo

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

Re: Comodo issued a certificate for an extension

[Gervase Markham]

On 04/10/16 14:19, Nick Lamb wrote:
> That's why I proposed Mozilla might like to write this to CA/B or in
> a group CA communication, because I would be astonished if WoSign and
> Comodo are the only CAs to have such special "rules" that defeat the
> purpose of the validation step, or if this is the only such "rule" in
> use today.

The existence of such rules is due to the open-ended nature of the
pre-ballot-169 validation options. Once we get ballot 169 out from the
IPR quagmire, the opportunity to have such rules in this crucial area
will be gone.

Gerv

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

Re: Comodo issued a certificate for an extension

[Nick Lamb]

On Tuesday, 4 October 2016 12:21:47 UTC+1, Rob Stradling  wrote:
> When we are required (by CABForum and/or root program requirements) to
> do , we will of course undertake to do .
> 
> There are lots of s that we are already required to do.  We
> haven't tended to issue a separate announcement for each  just to
> say that we do it!

I don't want to single out Comodo in particular, but you're the example we 
have. It feels to me, even during CA application processes here on m.d.s.policy 
as if the s are most often seen as bureaucratic red tape that gets in 
the way of your job, rather than, from my point of view as a relying party, as 
the bare minimum low bar a CA should expect to sail over in your day-to-day 
operations.

The CA/B BRs didn't previously explicitly say "You can treat control of 
www.example.com as proof of control over example.com" and they don't (after 
Ballot 169) now say "You can't treat control of www.example.com as proof of 
control over example.com". It was obvious before that you shouldn't do this, 
it's still obvious now, and it will remain obvious in March 2017.

Comodo's special "rule" that they've decided allows them to do this exists only 
in some unseen Comodo documentation. It's not in the Baseline Requirements, 
it's not in Comodo's Certificate Practice Statement, how should any Relying 
Party know about this rule? Suppose I, as a relying party see a certificate 
issued by Comodo for example.net - how am I supposed to guess that this really 
means Comodo saw only proof of control for www.example.net ?

What, outside of Comodo's own judgement, makes the Comodo rule OK, while 
prohibiting a rule that says if you control two-words.example you must be 
entitled to two.words.example as well if that exists ?

That's why I proposed Mozilla might like to write this to CA/B or in a group CA 
communication, because I would be astonished if WoSign and Comodo are the only 
CAs to have such special "rules" that defeat the purpose of the validation 
step, or if this is the only such "rule" in use today.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Rob Stradling]

On 03/10/16 02:23, Nick Lamb wrote:

> Comodo's document never actually says that they're abolishing this "rule" as 
> a result of Ballot 169. It lets you choose to draw that implication, by 
> specifying that their current practices pre-date Ballot 169's changes, but it 
> never says as much.

Nick,

When we are required (by CABForum and/or root program requirements) to
do , we will of course undertake to do .

There are lots of s that we are already required to do.  We
haven't tended to issue a separate announcement for each  just to
say that we do it!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Comodo issued a certificate for an extension

[Rob Stradling]

On 02/10/16 17:49, Nick Lamb wrote:
> On Sunday, 2 October 2016 11:11:34 UTC+1, Patrick Figel  wrote:
>> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html
> 
> Thanks, I too could not find this in Google Groups. That is a little 
> concerning as I had assumed this was the authoritative source, since it's 
> linked from Mozilla's own pages.
> 
> The first thing that jumps out at me from their report is that they mistake 
> .sb for a gTLD when it is actually a ccTLD.

Nick, thanks for pointing out that silly error in our report.

Thankfully the type of TLD has no significance as far as certificate
issuance is concerned.



-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

RE: Comodo issued a certificate for an extension

[Jeremy Rowley]

No. The definition of Authorization Domain Name allows a CA to issue
www.example.com if the CA can prove control over example.com. However, the
reverse is not true. Proving control over www.example.com does not validate
example.com.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Man Ho (Certizen)
Sent: Monday, October 3, 2016 2:55 AM
To: Peter Bowen <pzbo...@gmail.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
<dev-security-policy@lists.mozilla.org>
Subject: Re: Comodo issued a certificate for an extension


On 10/3/2016 11:50 AM, Peter Bowen wrote:
> 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly 
> defined "Authorization Domain Name", which should avoid this in the 
> future.
Thank you for pointing me to those sections, but my confusion may be
starting from the definition of "Authorization Domain Name". Does it simply
mean one of the aliases of a FQDN that is specifically used to obtain
authorization for that FQDN? I think an example of "Authorization Domain
Name" could help me jump out from such abstraction of definition/term. Thank
you.

By simply reading the requirement, I feel that if I can create a CNAME
record to let "www." pointing to "", and I prove
to a CA that I control the "www.", then the CA should be able
to issue a certificate of "" according to those sections,
correct?

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


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: Comodo issued a certificate for an extension

[Man Ho (Certizen)]

On 10/3/2016 11:50 AM, Peter Bowen wrote:
> 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly
> defined "Authorization Domain Name", which should avoid this in the
> future.
Thank you for pointing me to those sections, but my confusion may be
starting from the definition of "Authorization Domain Name". Does it
simply mean one of the aliases of a FQDN that is specifically used to
obtain authorization for that FQDN? I think an example of "Authorization
Domain Name" could help me jump out from such abstraction of
definition/term. Thank you.

By simply reading the requirement, I feel that if I can create a CNAME
record to let "www." pointing to "", and I
prove to a CA that I control the "www.", then the CA should
be able to issue a certificate of "" according to those
sections, correct?

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

Re: Comodo issued a certificate for an extension

[Peter Bowen]

You are correct, I was not clear.

3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly
defined "Authorization Domain Name", which should avoid this in the
future.

3.2.2.4.7 is actually the outlier, in that it allows _
(underscore + some label) prefixed to the name being validated.  It is
the one remaining place where showing control over a subdomain allows
validation of the direct parent.

The other methods mostly rely upon the registered domain name, so they
never have the subdomain problem.

Does that help?

Thanks,
Peter

On Sun, Oct 2, 2016 at 8:25 PM, Man Ho (Certizen)  wrote:
> Peter,
>
> I'm confused why only the section 3.2.2.4.7 specifically addresses this
> concern, and how. If only it does, would it implies that CA must use
> this method of section 3.2.2.4.7 to validate a Base Domain Name, which
> happened to be an Authorization Domain Name requested by the applicant ?
> However, according to section 3.2.2.4, each FQDN listed in the
> certificate is required to be validated using AT LEAST one of the
> methods only.
>
> Thanks,
>
> Man
>
>
> On 10/3/2016 3:53 AM, Peter Bowen wrote:
>> The new section 3.2.2.4.7 specifically
>> addresses DNS validation.  Under the new rules, which should be in
>> effect as of 1 March 2017, validating www. will not be a valid
>> method of showing control of .  The name is true for any valid
>> hostname under .  The only note is that names in the form
>> _. (that is starting with an underscore) can be
>> used to validate .
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Man Ho (Certizen)]

Peter,

I'm confused why only the section 3.2.2.4.7 specifically addresses this
concern, and how. If only it does, would it implies that CA must use
this method of section 3.2.2.4.7 to validate a Base Domain Name, which
happened to be an Authorization Domain Name requested by the applicant ?
However, according to section 3.2.2.4, each FQDN listed in the
certificate is required to be validated using AT LEAST one of the
methods only.

Thanks,

Man


On 10/3/2016 3:53 AM, Peter Bowen wrote:
> The new section 3.2.2.4.7 specifically
> addresses DNS validation.  Under the new rules, which should be in
> effect as of 1 March 2017, validating www. will not be a valid
> method of showing control of .  The name is true for any valid
> hostname under .  The only note is that names in the form
> _. (that is starting with an underscore) can be
> used to validate .


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

Re: Comodo issued a certificate for an extension

[Eric Mill]

On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb  wrote:

> On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen  wrote:
> > There is some good news.  The CA/Browser Forum has already addressed
> > this, even prior to the current discussions. Ballot 169
> > (https://cabforum.org/2016/08/05/ballot-169-revised-
> validation-requirements/)
> > revises 3.2.2.4 considerably.
>
> I'm aware of Ballot 169
>
> > Under the new rules, which should be in
> > effect as of 1 March 2017, validating www. will not be a valid
> > method of showing control of .  The name is true for any valid
> > hostname under .  The only note is that names in the form
> > _. (that is starting with an underscore) can be
> > used to validate .
>
> I wish I shared your confidence. My expectation is that if we leave this
> as it is, in April 2017 subscribers will still be able to get a certificate
> issued using this lackadaisical validation, and the issuing CA will say
> they feel it's not "really" disobeying the rules, that it's just a
> "technicality" and anyway what's the harm, it's so much more convenient for
> their customers this way?
>
> Comodo's document never actually says that they're abolishing this "rule"
> as a result of Ballot 169. It lets you choose to draw that implication, by
> specifying that their current practices pre-date Ballot 169's changes, but
> it never says as much. Hence I think Mozilla's rep should take this to
> CA/B, or it should go in one of the bulk CA communications, to find out at
> least how widespread the crazy is and whether it's even consistent in how
> it works from one CA to the next.
>

It would be nice for Comodo to make it explicit that this practice will
cease when Ballot 169 takes effect, and the lack of an explicit update
jumped out at me immediately when I read it. But the BRs post-169 seem
crystal clear on this, and I don't think CAs would be able to write off
this practice as a technicality or misinterpretation.

-- Eric


>
> On https://community.letsencrypt.org/ more than once users who've
> previously had certificates from elsewhere have expressed confusion or
> dismay when they realise that Let's Encrypt doesn't automatically issue
> them a certificate for both www.example.com and example.com after they
> only asked for one of the two. So this practice has apparently been
> widespread enough for some subscribers to assume it's "just how it works"
> even though it was never actually permitted by the BRs...
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Comodo issued a certificate for an extension

[Peter Bowen]

On Sun, Oct 2, 2016 at 6:23 PM, Nick Lamb  wrote:
> On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen  wrote:
>
>> Under the new rules, which should be in
>> effect as of 1 March 2017, validating www. will not be a valid
>> method of showing control of .  The name is true for any valid
>> hostname under .  The only note is that names in the form
>> _. (that is starting with an underscore) can be
>> used to validate .
>
> I wish I shared your confidence. My expectation is that if we leave this as 
> it is, in April 2017 subscribers will still be able to get a certificate 
> issued using this lackadaisical validation, and the issuing CA will say they 
> feel it's not "really" disobeying the rules, that it's just a "technicality" 
> and anyway what's the harm, it's so much more convenient for their customers 
> this way?

I'm rather confident, but then I was one of the authors of 169 and
will be pushing hard to ensure all CAs get this right.

> On https://community.letsencrypt.org/ more than once users who've previously 
> had certificates from elsewhere have expressed confusion or dismay when they 
> realise that Let's Encrypt doesn't automatically issue them a certificate for 
> both www.example.com and example.com after they only asked for one of the 
> two. So this practice has apparently been widespread enough for some 
> subscribers to assume it's "just how it works" even though it was never 
> actually permitted by the BRs...

>From my experience running a CA, it does seem customers are surprised
if certs don't automatically contain both www.example.com and
example.com. However that is unrelated to how validation works -- in
this case the simple answer for the CA to validate control of
example.com which allows issuance for both names.  The incorrect
method is to validate www.example.com and then issue for example.com.

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

Re: Comodo issued a certificate for an extension

[Nick Lamb]

On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen  wrote:
> There is some good news.  The CA/Browser Forum has already addressed
> this, even prior to the current discussions. Ballot 169
> (https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/)
> revises 3.2.2.4 considerably.

I'm aware of Ballot 169

> Under the new rules, which should be in
> effect as of 1 March 2017, validating www. will not be a valid
> method of showing control of .  The name is true for any valid
> hostname under .  The only note is that names in the form
> _. (that is starting with an underscore) can be
> used to validate .

I wish I shared your confidence. My expectation is that if we leave this as it 
is, in April 2017 subscribers will still be able to get a certificate issued 
using this lackadaisical validation, and the issuing CA will say they feel it's 
not "really" disobeying the rules, that it's just a "technicality" and anyway 
what's the harm, it's so much more convenient for their customers this way?

Comodo's document never actually says that they're abolishing this "rule" as a 
result of Ballot 169. It lets you choose to draw that implication, by 
specifying that their current practices pre-date Ballot 169's changes, but it 
never says as much. Hence I think Mozilla's rep should take this to CA/B, or it 
should go in one of the bulk CA communications, to find out at least how 
widespread the crazy is and whether it's even consistent in how it works from 
one CA to the next.

On https://community.letsencrypt.org/ more than once users who've previously 
had certificates from elsewhere have expressed confusion or dismay when they 
realise that Let's Encrypt doesn't automatically issue them a certificate for 
both www.example.com and example.com after they only asked for one of the two. 
So this practice has apparently been widespread enough for some subscribers to 
assume it's "just how it works" even though it was never actually permitted by 
the BRs...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Peter Bowen]

On Sun, Oct 2, 2016 at 9:49 AM, Nick Lamb  wrote:
>
> The second thing obviously is that they do have exactly the "rule" Richard 
> Wang described, and they believe this was justified under the BRs old 3.2.2.4 
> method 7 (which isn't a method at all, it's basically a catch-all).
>
> I think that's probably something that needs to go to CA/B although of course 
> Mozilla would be well within its rights to just write to all CAs, asking if 
> they have this or any similar "rules" that frustrate the intention of 3.2.2.4 
> and if so asking them to fix it by some reasonable deadline, such as EOY 2016.

There is some good news.  The CA/Browser Forum has already addressed
this, even prior to the current discussions. Ballot 169
(https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/)
revises 3.2.2.4 considerably.  The new section 3.2.2.4.7 specifically
addresses DNS validation.  Under the new rules, which should be in
effect as of 1 March 2017, validating www. will not be a valid
method of showing control of .  The name is true for any valid
hostname under .  The only note is that names in the form
_. (that is starting with an underscore) can be
used to validate .

So this gap will close soon.

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

Re: Comodo issued a certificate for an extension

[Nick Lamb]

On Sunday, 2 October 2016 11:11:34 UTC+1, Patrick Figel  wrote:
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html

Thanks, I too could not find this in Google Groups. That is a little concerning 
as I had assumed this was the authoritative source, since it's linked from 
Mozilla's own pages.

The first thing that jumps out at me from their report is that they mistake .sb 
for a gTLD when it is actually a ccTLD.

The second thing obviously is that they do have exactly the "rule" Richard Wang 
described, and they believe this was justified under the BRs old 3.2.2.4 method 
7 (which isn't a method at all, it's basically a catch-all).

I examined the Comodo CPS and wasn't able to find any mention of this rule. 
Indeed based on the CPS I would have assumed that control over a website 
www.example.com would under no circumstances be sufficient to get a certificate 
for the name example.com from Comodo and I would be grateful if anyone can 
point me to where they have written that it is.

I think that's probably something that needs to go to CA/B although of course 
Mozilla would be well within its rights to just write to all CAs, asking if 
they have this or any similar "rules" that frustrate the intention of 3.2.2.4 
and if so asking them to fix it by some reasonable deadline, such as EOY 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Patrick Figel]

On 02/10/16 12:01, Jason Milionis wrote:
> Still no response from COMODO CA, that's interesting, but why?

They published an incident report a couple of days ago. For some reason,
it's not visible in the Google Groups archive of m.d.s.p (at least for
me). Here's an alternative link:

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Showfom]

On Saturday, September 24, 2016 at 7:07:39 AM UTC+8, Showfom wrote:
> First, let me introduce myself, I'm a famous investor of ccTLD domains from 
> China.
> 
> Recently we get an easy-remember domain www.sb, please note the extension is 
> .sb
> 
> I ordered a Comodo Positive SSL for this domain, the common name which I 
> submit is www.sb
> 
> Usually they will give us a certificate for www.sb and www.www.sb, but this 
> time Comodo issues a certificate with DNS name www.sb and sb
> 
> I can't find our certificate in crt.sh but can be viewed here
> 
> https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966
> 
> Or you can simply type https://www.sb/ in your browser to view the certificate
> 
> https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png
> 
> I also tried to make an nginx conf in my server for https://sb/ you can 
> change your /etc/hosts or just use curl commmand
> 
> curl -v -H "Host: sb" https://www.sb/
> 
> You can find 403 Forbidden in title without any SSL certificate error because 
> I set the return status for https://sb/ to 403
> 
> Sorry for my bad English
> 
> Best Regards,
> @Showfom

The curl command is wrong, but after changed /etc/hosts or 
c:\Windows\System32\Drivers\etc\hosts , I can visit https://sb/ without any 
problem.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Showfom]

On Sunday, September 25, 2016 at 6:24:11 AM UTC+8, Percy wrote:
> Ha! @Showfom perhaps you should try getting a widecard cert from them and 
> consequently obtain a cert for all *.sb domains.

I tried to get cert from StartSSL, they will only issue www.sb or www.www.sb, 
that's good.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Ryan Sleevi]

On Sunday, September 25, 2016 at 6:14:06 PM UTC-7, Richard Wang wrote:
> This rule is ok for more case, but for this case, it is wrong.

This rule is NEVER ok. Please re-read the BRs to understand why.

> There is another bug that it means Comodo don't have the gTLD blocking system 
> that according to the BR, CA can't issue the gTLD domain to subscriber. 

The BRs do not say this. Please re-read the BRs to understand why.

> This is a BR violated misissuance, I don't know if any more certificates are 
> mis-issued since it is a bug in the code that may affect other similar order. 

You are correct that this is potentially BR violating. However, the details of 
that remain to be determined. It would be useful if you allow the CA the 
opportunity to respond. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Comodo issued a certificate for an extension

[Richard Wang]

I think I know the reason; this may be helpful for your investigation.

This is a code bug from CA issuing system that the engineer mis-understand the 
free additional domain added rule. System treat the "www" as a subdomain, most 
case it is, but in this case, it is top domain. 
Subscriber finished the domain validation for domain "www.sb", then the issuing 
system using the rule "if the domain is validated, and if the cert request is 
for www.domain.com, then add its top domain - domain.com to the certificate 
automatically", then the signing system added the domain ".sb" as its top 
domain to the certificate. This rule is ok for more case, but for this case, it 
is wrong.

There is another bug that it means Comodo don't have the gTLD blocking system 
that according to the BR, CA can't issue the gTLD domain to subscriber. 

And the excuse of "don’t know this new gTLD" is not a good reason that there 
are many new gTLDs come out very frequently, system can NOT issue the gTLD name 
for subscribers, system must block any known or unknown gTLD in the 
certificate. And this domain - "www.sb" is passed the domain validation, it 
means Comodo system know this gTLD.

This is a BR violated misissuance, I don't know if any more certificates are 
mis-issued since it is a bug in the code that may affect other similar order. I 
recommend Comodo post all issued SSL certificate to CT log server for full 
transparency to let worldwide user to check if any more mis-issuance happened.  



Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Robin Alden
Sent: Monday, September 26, 2016 1:29 AM
To: 'Peter Bowen' <pzbo...@gmail.com>; 'Nick Lamb' <tialara...@gmail.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Comodo issued a certificate for an extension

Hi All,
We did receive a direct report of the problem yesterday (24th 
September) from a Mozilla rep., thanks, and we undertook an investigation and 
remediation exercise yesterday.

The software problem which caused or allowed this certificate to be issued has 
been corrected.

That certificate (https://crt.sh/?id=34242572) was revoked yesterday morning.

We will issue a report tomorrow (26th September).

Regards
Robin Alden
Comodo



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Peter Bowen
> Sent: 25 September 2016 17:37
> To: Nick Lamb <tialara...@gmail.com>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Comodo issued a certificate for an extension
> 
> On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb <tialara...@gmail.com> wrote:
> > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com
> wrote:
> >> am I the only one who a) thinks this is slightly problematic and b) 
> >> is
> surprised that the cert still isn't revoked?
> >
> > I don't know enough about the .sb ccTLD to be clear how problematic 
> > the
> described scenario is. I would certainly like to know more. Wikipedia 
> tells me that .sb is operated like .uk used to be, with registrant 
> domains appearing only as 3LDs e.g. you used to able to buy 
> example.co.uk but not example.uk, so that having control of example.sb 
> is itself exceptional, let alone www.sb
> 
> According to https://nic.net.sb/, which is linked from
> http://www.iana.org/domains/root/db/sb.html:
> 
> "Starting from February 12, 2016 Solomon Telekom Company Limited is 
> pleased to announce the extending of .sb domain space place by 
> allowing registrations directly at the ‘second-level’."
> 
> So it appears that the scenario is that someone (presumably the 
> reporter of this issue) registered www.sb., a second level domain 
> name, which would be in accordance with the described change.
> 
> > It is important to me - as a relying party - to know if there is a 
> > problem in
> Comodo's domain validation which allows people to obtain certificates 
> for names which they do not (or perhaps, depending how .sb is run, 
> even
> cannot) control. It is not terribly important to me in principle which 
> names are affected, but in practice the extent of the risk might 
> influence Mozilla's decision as to what if anything should be done, by them 
> or by Comodo.
> >
> > However right now it's the weekend, people who do this stuff as 
> > their day
> job, rather than an outside interest, may not have responded because 
> they're busy watching televised sports or baking cakes. I will grow 
> more concerned if there's no follow-up from anybody next week.
> 
> It is unclear if this has been repor

RE: Comodo issued a certificate for an extension

[Robin Alden]

Hi All,
We did receive a direct report of the problem yesterday (24th 
September) from a Mozilla rep., thanks, and we undertook an investigation and 
remediation exercise yesterday.

The software problem which caused or allowed this certificate to be issued has 
been corrected.

That certificate (https://crt.sh/?id=34242572) was revoked yesterday morning.

We will issue a report tomorrow (26th September).

Regards
Robin Alden
Comodo



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Peter Bowen
> Sent: 25 September 2016 17:37
> To: Nick Lamb <tialara...@gmail.com>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Comodo issued a certificate for an extension
> 
> On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb <tialara...@gmail.com> wrote:
> > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com
> wrote:
> >> am I the only one who a) thinks this is slightly problematic and b) is
> surprised that the cert still isn't revoked?
> >
> > I don't know enough about the .sb ccTLD to be clear how problematic the
> described scenario is. I would certainly like to know more. Wikipedia tells me
> that .sb is operated like .uk used to be, with registrant domains appearing
> only as 3LDs e.g. you used to able to buy example.co.uk but not example.uk,
> so that having control of example.sb is itself exceptional, let alone www.sb
> 
> According to https://nic.net.sb/, which is linked from
> http://www.iana.org/domains/root/db/sb.html:
> 
> "Starting from February 12, 2016 Solomon Telekom Company Limited is
> pleased to announce the extending of .sb domain space place by
> allowing registrations directly at the ‘second-level’."
> 
> So it appears that the scenario is that someone (presumably the
> reporter of this issue) registered www.sb., a second level domain
> name, which would be in accordance with the described change.
> 
> > It is important to me - as a relying party - to know if there is a problem 
> > in
> Comodo's domain validation which allows people to obtain certificates for
> names which they do not (or perhaps, depending how .sb is run, even
> cannot) control. It is not terribly important to me in principle which names 
> are
> affected, but in practice the extent of the risk might influence Mozilla's
> decision as to what if anything should be done, by them or by Comodo.
> >
> > However right now it's the weekend, people who do this stuff as their day
> job, rather than an outside interest, may not have responded because
> they're busy watching televised sports or baking cakes. I will grow more
> concerned if there's no follow-up from anybody next week.
> 
> It is unclear if this has been reported to the CA (Comodo).  While
> some CA operators do read this Mozilla forum, it is not an official
> communication channel for any CA, as far as I know.  Any request to
> revoke a certificate needs to be sent to the address specified by the
> CA in their CPS.
> 
> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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: Comodo issued a certificate for an extension

[Peter Bowen]

On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb  wrote:
> On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com  wrote:
>> am I the only one who a) thinks this is slightly problematic and b) is 
>> surprised that the cert still isn't revoked?
>
> I don't know enough about the .sb ccTLD to be clear how problematic the 
> described scenario is. I would certainly like to know more. Wikipedia tells 
> me that .sb is operated like .uk used to be, with registrant domains 
> appearing only as 3LDs e.g. you used to able to buy example.co.uk but not 
> example.uk, so that having control of example.sb is itself exceptional, let 
> alone www.sb

According to https://nic.net.sb/, which is linked from
http://www.iana.org/domains/root/db/sb.html:

"Starting from February 12, 2016 Solomon Telekom Company Limited is
pleased to announce the extending of .sb domain space place by
allowing registrations directly at the ‘second-level’."

So it appears that the scenario is that someone (presumably the
reporter of this issue) registered www.sb., a second level domain
name, which would be in accordance with the described change.

> It is important to me - as a relying party - to know if there is a problem in 
> Comodo's domain validation which allows people to obtain certificates for 
> names which they do not (or perhaps, depending how .sb is run, even cannot) 
> control. It is not terribly important to me in principle which names are 
> affected, but in practice the extent of the risk might influence Mozilla's 
> decision as to what if anything should be done, by them or by Comodo.
>
> However right now it's the weekend, people who do this stuff as their day 
> job, rather than an outside interest, may not have responded because they're 
> busy watching televised sports or baking cakes. I will grow more concerned if 
> there's no follow-up from anybody next week.

It is unclear if this has been reported to the CA (Comodo).  While
some CA operators do read this Mozilla forum, it is not an official
communication channel for any CA, as far as I know.  Any request to
revoke a certificate needs to be sent to the address specified by the
CA in their CPS.

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

Re: Comodo issued a certificate for an extension

[Nick Lamb]

On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com  wrote:
> am I the only one who a) thinks this is slightly problematic and b) is 
> surprised that the cert still isn't revoked?

I don't know enough about the .sb ccTLD to be clear how problematic the 
described scenario is. I would certainly like to know more. Wikipedia tells me 
that .sb is operated like .uk used to be, with registrant domains appearing 
only as 3LDs e.g. you used to able to buy example.co.uk but not example.uk, so 
that having control of example.sb is itself exceptional, let alone www.sb

It is important to me - as a relying party - to know if there is a problem in 
Comodo's domain validation which allows people to obtain certificates for names 
which they do not (or perhaps, depending how .sb is run, even cannot) control. 
It is not terribly important to me in principle which names are affected, but 
in practice the extent of the risk might influence Mozilla's decision as to 
what if anything should be done, by them or by Comodo.

However right now it's the weekend, people who do this stuff as their day job, 
rather than an outside interest, may not have responded because they're busy 
watching televised sports or baking cakes. I will grow more concerned if 
there's no follow-up from anybody next week.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[mono . riot]

am I the only one who a) thinks this is slightly problematic and b) is 
surprised that the cert still isn't revoked?
Cheers,
mono
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[Percy]

Ha! @Showfom perhaps you should try getting a widecard cert from them and 
consequently obtain a cert for all *.sb domains.  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[sjw]

The affected cert has been logged here: https://crt.sh/?id=34242572


Am 24.09.2016 um 02:33 schrieb Richard Wang:
> First, I must make declaration that I don't know "Showfom", and I don't know 
> if he/she is a WoSign customer.
>
> As I said in my final statement that I wish all Mozilla trusted CA can post 
> their issued certificate to CT log server for full transparency, I am sure 
> not WoSign mis-issued certificate only, maybe some CA have more serious 
> problems.
>
> I paste my statement again here:
> WoSign believes that the Certificate Transparency is a very good solution for 
> self-discipline that force employees to attach great importance to product 
> quality control, and for external oversight mechanism that let the third 
> party supervise the CA's activity. 
> WoSign is the first CA that volunteer to post all issued SSL Certificates to 
> Google CT log server initiatively. Our aim is to let the worldwide users 
> trust WoSign SSL certificates, and hope to drive the global CAs to be open 
> and transparent publishing all issued certificates to CT log server, making 
> worldwide users, browser vendors and related stakeholder to take an overall 
> supervision, this will benefit the global Internet security.
>
>
> @Showfom: you don't need to say " Sorry for my bad English", your English is 
> very good! Our native language is Chinese, not English, so no need to say 
> sorry, I NEVER say this word again.
>
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Showfom
> Sent: Saturday, September 24, 2016 2:30 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Comodo issued a certificate for an extension
>
> First, let me introduce myself, I'm a famous investor of ccTLD domains from 
> China.
>
> Recently we get an easy-remember domain www.sb, please note the extension is 
> .sb
>
> I ordered a Comodo Positive SSL for this domain, the common name which I 
> submit is www.sb
>
> Usually they will give us a certificate for www.sb and www.www.sb, but this 
> time Comodo issues a certificate with DNS name www.sb and sb
>
> I can't find our certificate in crt.sh but can be viewed here
>
> https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966
>
> Or you can simply type https://www.sb/ in your browser to view the certificate
>
> https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png
>
> I also tried to make an nginx conf in my server for https://sb/ you can 
> change your /etc/hosts or just use curl commmand
>
> curl -v -H "Host: sb" https://www.sb/
>
> You can find 403 Forbidden in title without any SSL certificate error because 
> I set the return status for https://sb/ to 403
>
> Sorry for my bad English
>
> Best Regards,
> @Showfom
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




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: Comodo issued a certificate for an extension

[Richard Wang]

First, I must make declaration that I don't know "Showfom", and I don't know if 
he/she is a WoSign customer.

As I said in my final statement that I wish all Mozilla trusted CA can post 
their issued certificate to CT log server for full transparency, I am sure not 
WoSign mis-issued certificate only, maybe some CA have more serious problems.

I paste my statement again here:
WoSign believes that the Certificate Transparency is a very good solution for 
self-discipline that force employees to attach great importance to product 
quality control, and for external oversight mechanism that let the third party 
supervise the CA's activity. 
WoSign is the first CA that volunteer to post all issued SSL Certificates to 
Google CT log server initiatively. Our aim is to let the worldwide users trust 
WoSign SSL certificates, and hope to drive the global CAs to be open and 
transparent publishing all issued certificates to CT log server, making 
worldwide users, browser vendors and related stakeholder to take an overall 
supervision, this will benefit the global Internet security.


@Showfom: you don't need to say " Sorry for my bad English", your English is 
very good! Our native language is Chinese, not English, so no need to say 
sorry, I NEVER say this word again.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Showfom
Sent: Saturday, September 24, 2016 2:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Comodo issued a certificate for an extension

First, let me introduce myself, I'm a famous investor of ccTLD domains from 
China.

Recently we get an easy-remember domain www.sb, please note the extension is .sb

I ordered a Comodo Positive SSL for this domain, the common name which I submit 
is www.sb

Usually they will give us a certificate for www.sb and www.www.sb, but this 
time Comodo issues a certificate with DNS name www.sb and sb

I can't find our certificate in crt.sh but can be viewed here

https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966

Or you can simply type https://www.sb/ in your browser to view the certificate

https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png

I also tried to make an nginx conf in my server for https://sb/ you can change 
your /etc/hosts or just use curl commmand

curl -v -H "Host: sb" https://www.sb/

You can find 403 Forbidden in title without any SSL certificate error because I 
set the return status for https://sb/ to 403

Sorry for my bad English

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

RE: Comodo issued a certificate for an extension

[Richard Wang]

First, I must make declaration that I don't know "Showfom", and I don't know if 
he/she is a WoSign customer.

As I said in my final statement that I wish all Mozilla trusted CA can post 
their issued certificate to CT log server for full trenchancy, I am sure not 
WoSign mis-issued certificate, maybe some CA have more serious problems..

I paste my statement again here:
WoSign believes that the Certificate Transparency is a very good solution for 
self-discipline that force employees to attach great importance to product 
quality control, and for external oversight mechanism that let the third party 
supervise the CA's activity. 
WoSign is the first CA that volunteer to post all issued SSL Certificates to 
Google CT log server initiatively. Our aim is to let the worldwide users trust 
WoSign SSL certificates, and hope to drive the global CAs to be open and 
transparent publishing all issued certificates to CT log server, making 
worldwide users, browser vendors and related stakeholder to take an overall 
supervision, this will benefit the global Internet security.


@Showfom: you don't need to say " Sorry for my bad English", your English is 
very good! Our native language is Chinese, not English, so no need to say 
sorry, I NEVER say this word again.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Showfom
Sent: Saturday, September 24, 2016 2:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Comodo issued a certificate for an extension

First, let me introduce myself, I'm a famous investor of ccTLD domains from 
China.

Recently we get an easy-remember domain www.sb, please note the extension is .sb

I ordered a Comodo Positive SSL for this domain, the common name which I submit 
is www.sb

Usually they will give us a certificate for www.sb and www.www.sb, but this 
time Comodo issues a certificate with DNS name www.sb and sb

I can't find our certificate in crt.sh but can be viewed here

https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966

Or you can simply type https://www.sb/ in your browser to view the certificate

https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png

I also tried to make an nginx conf in my server for https://sb/ you can change 
your /etc/hosts or just use curl commmand

curl -v -H "Host: sb" https://www.sb/

You can find 403 Forbidden in title without any SSL certificate error because I 
set the return status for https://sb/ to 403

Sorry for my bad English

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

Comodo issued a certificate for an extension

[Showfom]

First, let me introduce myself, I'm a famous investor of ccTLD domains from 
China.

Recently we get an easy-remember domain www.sb, please note the extension is .sb

I ordered a Comodo Positive SSL for this domain, the common name which I submit 
is www.sb

Usually they will give us a certificate for www.sb and www.www.sb, but this 
time Comodo issues a certificate with DNS name www.sb and sb

I can't find our certificate in crt.sh but can be viewed here

https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966

Or you can simply type https://www.sb/ in your browser to view the certificate

https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png

I also tried to make an nginx conf in my server for https://sb/ you can change 
your /etc/hosts or just use curl commmand

curl -v -H "Host: sb" https://www.sb/

You can find 403 Forbidden in title without any SSL certificate error because I 
set the return status for https://sb/ to 403

Sorry for my bad English

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