RE: StartCom issuing bogus certificates
Hi <https://bugzilla.mozilla.org/attachment.cgi?id=8873408> https://bugzilla.mozilla.org/attachment.cgi?id=8873408 <https://bugzilla.mozilla.org/attachment.cgi?id=8873409> https://bugzilla.mozilla.org/attachment.cgi?id=8873409 these are the 2 documents I tried to upload to the list, these are now in the bug created by Gerv at <https://bugzilla.mozilla.org/show_bug.cgi?id=1369359> https://bugzilla.mozilla.org/show_bug.cgi?id=1369359 Best regards Iñigo Barreira CEO StartCom CA Limited From: Vincent Lynch [mailto:vtly...@gmail.com] Sent: jueves, 1 de junio de 2017 14:46 To: Eric Mill <e...@konklone.com>; Gervase Markham <g...@mozilla.org>; Inigo Barreira <in...@startcomca.com>; Jeremy Rowley <jeremy.row...@digicert.com>; Yuhong Bao <yuhongbao_...@hotmail.com> Cc: Kurt Roeckx <k...@roeckx.be>; Matthew Hardeman <mharde...@gmail.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: StartCom issuing bogus certificates Hi Inigo, You mentioned there would be a report attached but I believe you forgot to send it? Can you upload the report and provide a URL? I believe that's the 'best practice' for sharing files here as it allows non-subscribers to access the file via the Google Groups archive. -Vincent On Thu, Jun 1, 2017 at 6:40 AM Inigo Barreira via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Hi all, Firstly I´d like to apologize for not having answering before and for posting an initial response that was not correct not accurate and not related what it´s being discussed right now. It was my fault for not having checked before with my team, which is in China and they are 6 hours ahead, but was my first reaction when saw test in the SAN. So, sorry for this. In fact, the "issue" was due for implementing the CT log. Recently one customer asked why we weren´t logging our certificates in the CT logs, which we were doing it but with some problems because of the great firewall. So, we were talking with Primekey and provided a solution to implement in our system. We did it yesterday and for checking it, we created those "fake" certificates for testing, which were revoked inmediately. Attached there´s a report in which we explain all that has happened. And also some screenshots. In this report also indicate what remeditation steps we´ve already done to avoid these issues happen again in the future. We´ve also realized that the CRL generation didn´t work as supposed because didn´t generate a new CRL when those certificates were revoked but in the next update. We are dealing with Primekey to know what has happened. The OCSP response instead was correct and showed the certificates as revoked. For some other comments/suggestions posted in this thread I´d like to say that: - this incident is not related to the "real" issuance system through our CMS system in which all domains are verified - these certs were issued and revoked inmediately as they were only for testing. I know it wasn´t a good decission - regarding my initial response for test URLs, those are going to be generated under our own website, like valid.startcomca.com <http://valid.startcomca.com> , revoked.startcomca.com <http://revoked.startcomca.com> - and for those other certs in crt.sh, those are revoked but there are four that were not issued because the connection with the CT failed and for some reason are showed in the crt.sh. We´re contacting Primekey to know what has happened but it seems to be related with the Startcom log, which didn´t logged it because it failed and google logs, which did it, so maybe is a configuration issue. Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo <mailto:dev-security-policy-bounces%2Binigo> =startcomca@lists.mozilla.org <mailto:startcomca@lists.mozilla.org> ] On Behalf Of Gervase Markham via dev-security-policy Sent: jueves, 1 de junio de 2017 10:27 To: Yuhong Bao <yuhongbao_...@hotmail.com <mailto:yuhongbao_...@hotmail.com> >; Eric Mill <e...@konklone.com <mailto:e...@konklone.com> >; Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Kurt Roeckx <k...@roeckx.be <mailto:k...@roeckx.be> >; Matthew Hardeman <mharde...@gmail.com <mailto:mharde...@gmail.com> > Subject: Re: StartCom issuing bogus certificates On 01/06/17 01:48, Yuhong Bao wrote: > I don't think there is anything important on example.com <http://example.com> > though How would you like it if a CA decided there was nothing important on your website and
Re: StartCom issuing bogus certificates
Hi Inigo,
You mentioned there would be a report attached but I believe you forgot to
send it?
Can you upload the report and provide a URL? I believe that's the 'best
practice' for sharing files here as it allows non-subscribers to access the
file via the Google Groups archive.
-Vincent
On Thu, Jun 1, 2017 at 6:40 AM Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi all,
>
> Firstly I´d like to apologize for not having answering before and for
> posting an initial response that was not correct not accurate and not
> related what it´s being discussed right now. It was my fault for not having
> checked before with my team, which is in China and they are 6 hours ahead,
> but was my first reaction when saw test in the SAN. So, sorry for this.
>
> In fact, the "issue" was due for implementing the CT log. Recently one
> customer asked why we weren´t logging our certificates in the CT logs,
> which
> we were doing it but with some problems because of the great firewall. So,
> we were talking with Primekey and provided a solution to implement in our
> system. We did it yesterday and for checking it, we created those "fake"
> certificates for testing, which were revoked inmediately.
> Attached there´s a report in which we explain all that has happened. And
> also some screenshots.
> In this report also indicate what remeditation steps we´ve already done to
> avoid these issues happen again in the future.
>
> We´ve also realized that the CRL generation didn´t work as supposed because
> didn´t generate a new CRL when those certificates were revoked but in the
> next update. We are dealing with Primekey to know what has happened. The
> OCSP response instead was correct and showed the certificates as revoked.
>
> For some other comments/suggestions posted in this thread I´d like to say
> that:
>
> - this incident is not related to the "real" issuance system through our
> CMS
> system in which all domains are verified
> - these certs were issued and revoked inmediately as they were only for
> testing. I know it wasn´t a good decission
> - regarding my initial response for test URLs, those are going to be
> generated under our own website, like valid.startcomca.com,
> revoked.startcomca.com
> - and for those other certs in crt.sh, those are revoked but there are four
> that were not issued because the connection with the CT failed and for some
> reason are showed in the crt.sh. We´re contacting Primekey to know what has
> happened but it seems to be related with the Startcom log, which didn´t
> logged it because it failed and google logs, which did it, so maybe is a
> configuration issue.
>
> Best regards
>
> Iñigo Barreira
> CEO
> StartCom CA Limited
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org
> ]
> On Behalf Of Gervase Markham via dev-security-policy
> Sent: jueves, 1 de junio de 2017 10:27
> To: Yuhong Bao <yuhongbao_...@hotmail.com>; Eric Mill <e...@konklone.com>;
> Jeremy Rowley <jeremy.row...@digicert.com>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Kurt Roeckx
> <k...@roeckx.be>; Matthew Hardeman <mharde...@gmail.com>
> Subject: Re: StartCom issuing bogus certificates
>
> On 01/06/17 01:48, Yuhong Bao wrote:
> > I don't think there is anything important on example.com though
>
> How would you like it if a CA decided there was nothing important on your
> website and so decided it was OK to misissue certificates for it?
>
> This requirement is a positive requirement ("must have validated domain
> ownership or control by applicant"), not a negative requirement ("domain
> must not have anything important on it").
>
> Gerv
> ___
> 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
>
--
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
RE: StartCom issuing bogus certificates
Hi all,
Firstly I´d like to apologize for not having answering before and for
posting an initial response that was not correct not accurate and not
related what it´s being discussed right now. It was my fault for not having
checked before with my team, which is in China and they are 6 hours ahead,
but was my first reaction when saw test in the SAN. So, sorry for this.
In fact, the "issue" was due for implementing the CT log. Recently one
customer asked why we weren´t logging our certificates in the CT logs, which
we were doing it but with some problems because of the great firewall. So,
we were talking with Primekey and provided a solution to implement in our
system. We did it yesterday and for checking it, we created those "fake"
certificates for testing, which were revoked inmediately.
Attached there´s a report in which we explain all that has happened. And
also some screenshots.
In this report also indicate what remeditation steps we´ve already done to
avoid these issues happen again in the future.
We´ve also realized that the CRL generation didn´t work as supposed because
didn´t generate a new CRL when those certificates were revoked but in the
next update. We are dealing with Primekey to know what has happened. The
OCSP response instead was correct and showed the certificates as revoked.
For some other comments/suggestions posted in this thread I´d like to say
that:
- this incident is not related to the "real" issuance system through our CMS
system in which all domains are verified
- these certs were issued and revoked inmediately as they were only for
testing. I know it wasn´t a good decission
- regarding my initial response for test URLs, those are going to be
generated under our own website, like valid.startcomca.com,
revoked.startcomca.com
- and for those other certs in crt.sh, those are revoked but there are four
that were not issued because the connection with the CT failed and for some
reason are showed in the crt.sh. We´re contacting Primekey to know what has
happened but it seems to be related with the Startcom log, which didn´t
logged it because it failed and google logs, which did it, so maybe is a
configuration issue.
Best regards
Iñigo Barreira
CEO
StartCom CA Limited
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: jueves, 1 de junio de 2017 10:27
To: Yuhong Bao <yuhongbao_...@hotmail.com>; Eric Mill <e...@konklone.com>;
Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Kurt Roeckx
<k...@roeckx.be>; Matthew Hardeman <mharde...@gmail.com>
Subject: Re: StartCom issuing bogus certificates
On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though
How would you like it if a CA decided there was nothing important on your
website and so decided it was OK to misissue certificates for it?
This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not have anything important on it").
Gerv
___
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: StartCom issuing bogus certificates
On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though
How would you like it if a CA decided there was nothing important on
your website and so decided it was OK to misissue certificates for it?
This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not have anything important on it").
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
The content on example.com isn't important. An unauthorized certificate can still potentially be used to intercept an HTTPS connection to example.com and cause malicious behavior that is unrelated to the "real" content of example.com. I'm pushing on this because it's important to understand that a misissuance like this is bad for more than just "compliance" reasons. It's the same principle behind moving away from unencrypted connections generally -- even "unimportant" sites benefit from the use of HTTPS, in part because it closes off attack vectors that are present for all connections that fail to treat the network as untrusted. -- Eric On Wed, May 31, 2017 at 8:48 PM, Yuhong Bao <yuhongbao_...@hotmail.com> wrote: > I don't think there is anything important on example.com though > > From: Eric Mill <e...@konklone.com> > Sent: Wednesday, May 31, 2017 4:34:20 PM > To: Jeremy Rowley > Cc: Kurt Roeckx; Yuhong Bao; mozilla-dev-security-pol...@lists.mozilla.org; > Matthew Hardeman > Subject: Re: StartCom issuing bogus certificates > > It's absolutely not harmless to use example.com<http://example.com> to > test certificate issuance. People visit example.com<http://example.com> > all the time, given its role. An unauthorized certificate for example.com< > http://example.com> could let someone other than its owner hijack user > connections, and maliciously redirect traffic or inject code/content, same > as for any other online service people use. It's an actual security > problem, not just a compliance violation. > > -- Eric > > On Wed, May 31, 2017 at 3:18 PM, Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org<mailto:dev- > security-pol...@lists.mozilla.org>> wrote: > Agreed - the license to use the domain granted by IANA is only for > inclusion > in documents (https://www.iana.org/domains/reserved). There isn't a > license > to use the domain for testing or any other purposes. > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley ev-security-policy-bounces%2Bjeremy.rowley>=digicert.com@lists.mozilla > .org] On Behalf Of Kurt Roeckx via dev-security-policy > Sent: Wednesday, May 31, 2017 11:55 AM > To: Yuhong Bao <yuhongbao_...@hotmail.com<mailto:yuhongbao_...@hotmail.com > >> > Cc: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozil > la-dev-security-pol...@lists.mozilla.org>; Matthew Hardeman > <mharde...@gmail.com<mailto:mharde...@gmail.com>> > Subject: Re: StartCom issuing bogus certificates > > On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via > dev-security-policy > wrote: > > The point is that "misissuance" of example.com<http://example.com> is > harmless as they are > reserved by IANA. > > But example.com<http://example.com> is a real domain that that even has > an https website. The > certificate is issued by digicert, and the subject says it's to ICANN. If > the certificate is not requested by IANA or ICANN nobody should issue a > certificate for it. > > > Kurt > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org<mailto:dev- > security-pol...@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org<mailto:dev- > security-pol...@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > -- > konklone.com<https://konklone.com> | @konklone<https://twitter.com/ > konklone> > -- konklone.com | @konklone <https://twitter.com/konklone> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
I don't think there is anything important on example.com though From: Eric Mill <e...@konklone.com> Sent: Wednesday, May 31, 2017 4:34:20 PM To: Jeremy Rowley Cc: Kurt Roeckx; Yuhong Bao; mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman Subject: Re: StartCom issuing bogus certificates It's absolutely not harmless to use example.com<http://example.com> to test certificate issuance. People visit example.com<http://example.com> all the time, given its role. An unauthorized certificate for example.com<http://example.com> could let someone other than its owner hijack user connections, and maliciously redirect traffic or inject code/content, same as for any other online service people use. It's an actual security problem, not just a compliance violation. -- Eric On Wed, May 31, 2017 at 3:18 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Agreed - the license to use the domain granted by IANA is only for inclusion in documents (https://www.iana.org/domains/reserved). There isn't a license to use the domain for testing or any other purposes. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley<mailto:dev-security-policy-bounces%2Bjeremy.rowley>=digicert.com@lists.mozilla .org] On Behalf Of Kurt Roeckx via dev-security-policy Sent: Wednesday, May 31, 2017 11:55 AM To: Yuhong Bao <yuhongbao_...@hotmail.com<mailto:yuhongbao_...@hotmail.com>> Cc: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>; Matthew Hardeman <mharde...@gmail.com<mailto:mharde...@gmail.com>> Subject: Re: StartCom issuing bogus certificates On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy wrote: > The point is that "misissuance" of example.com<http://example.com> is > harmless as they are reserved by IANA. But example.com<http://example.com> is a real domain that that even has an https website. The certificate is issued by digicert, and the subject says it's to ICANN. If the certificate is not requested by IANA or ICANN nobody should issue a certificate for it. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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<mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
It's absolutely not harmless to use example.com to test certificate issuance. People visit example.com all the time, given its role. An unauthorized certificate for example.com could let someone other than its owner hijack user connections, and maliciously redirect traffic or inject code/content, same as for any other online service people use. It's an actual security problem, not just a compliance violation. -- Eric On Wed, May 31, 2017 at 3:18 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Agreed - the license to use the domain granted by IANA is only for > inclusion > in documents (https://www.iana.org/domains/reserved). There isn't a > license > to use the domain for testing or any other purposes. > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.c > om@lists.mozilla > .org] On Behalf Of Kurt Roeckx via dev-security-policy > Sent: Wednesday, May 31, 2017 11:55 AM > To: Yuhong Bao <yuhongbao_...@hotmail.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman > <mharde...@gmail.com> > Subject: Re: StartCom issuing bogus certificates > > On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via > dev-security-policy > wrote: > > The point is that "misissuance" of example.com is harmless as they are > reserved by IANA. > > But example.com is a real domain that that even has an https website. The > certificate is issued by digicert, and the subject says it's to ICANN. If > the certificate is not requested by IANA or ICANN nobody should issue a > certificate for it. > > > Kurt > > ___ > 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 > > -- konklone.com | @konklone <https://twitter.com/konklone> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: StartCom issuing bogus certificates
Agreed - the license to use the domain granted by IANA is only for inclusion in documents (https://www.iana.org/domains/reserved). There isn't a license to use the domain for testing or any other purposes. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kurt Roeckx via dev-security-policy Sent: Wednesday, May 31, 2017 11:55 AM To: Yuhong Bao <yuhongbao_...@hotmail.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman <mharde...@gmail.com> Subject: Re: StartCom issuing bogus certificates On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy wrote: > The point is that "misissuance" of example.com is harmless as they are reserved by IANA. But example.com is a real domain that that even has an https website. The certificate is issued by digicert, and the subject says it's to ICANN. If the certificate is not requested by IANA or ICANN nobody should issue a certificate for it. Kurt ___ 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: StartCom issuing bogus certificates
On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy wrote: > The point is that "misissuance" of example.com is harmless as they are > reserved by IANA. But example.com is a real domain that that even has an https website. The certificate is issued by digicert, and the subject says it's to ICANN. If the certificate is not requested by IANA or ICANN nobody should issue a certificate for it. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
Hi Yuhong, Yes, there may not be much harm in a mis-issued certificate for example.com due to its purpose/use. However, from the perspective of root programs and the CA/B Forum, it is still mis-issuance and considered a serious problem. CAs should not be issuing certificates without documented confirmation that the certificate request was properly verified. As Matthew suggested, the proper thing for a CA to do is operate their own domain for these kinds of tests. -Vincent On Wed, May 31, 2017 at 1:10 PM Yuhong Bao via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The point is that "misissuance" of example.com is harmless as they are > reserved by IANA. > > From: dev-security-policy <dev-security-policy-bounces+yuhongbao_386= > hotmail@lists.mozilla.org> on behalf of Matthew Hardeman via > dev-security-policy <dev-security-policy@lists.mozilla.org> > Sent: Wednesday, May 31, 2017 10:08:10 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: StartCom issuing bogus certificates > > On Wednesday, May 31, 2017 at 12:04:51 PM UTC-5, Yuhong Bao wrote: > > It would be better to use example.com and not test.com or anything like > that, as that is defined by IANA as a reserved domain. > > No, it is necessary to respect the baseline requirements in issuing from > "real" trusted or to-be-trusted systems. > > CAs have gotten in trouble / are in trouble for mis-issuances including > example.com quite recently. > > If a dnsName needs to be included in your test certificate, register a > domain owned by the CA for testing purposes. > > ___ > 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 > -- Vincent Lynch ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
On Wednesday, May 31, 2017 at 12:10:36 PM UTC-5, Yuhong Bao wrote: > The point is that "misissuance" of example.com is harmless as they are > reserved by IANA. Except that having a trusted root CA in the major root programs is a privileged club with a lot of non-obvious rules. One of those (roughly) being that you are never allowed to issue certs for things you don't have permission to issue a cert for. Not even for tests. See this certificate. https://crt.sh/?id=24558997 Ask Symantec if the misissuance of that certificate for www.example.com was harmless to them. I suspect they won't answer [at least not timely answer], but if they were being honest I'll be they really really regret that certificate's issuance. Hint: The issuance of that "harmless" certificate is one of the reasons that they're on their way to being a really-close-to-not-trusted CA. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
The point is that "misissuance" of example.com is harmless as they are reserved by IANA. From: dev-security-policy <dev-security-policy-bounces+yuhongbao_386=hotmail@lists.mozilla.org> on behalf of Matthew Hardeman via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: Wednesday, May 31, 2017 10:08:10 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: StartCom issuing bogus certificates On Wednesday, May 31, 2017 at 12:04:51 PM UTC-5, Yuhong Bao wrote: > It would be better to use example.com and not test.com or anything like that, > as that is defined by IANA as a reserved domain. No, it is necessary to respect the baseline requirements in issuing from "real" trusted or to-be-trusted systems. CAs have gotten in trouble / are in trouble for mis-issuances including example.com quite recently. If a dnsName needs to be included in your test certificate, register a domain owned by the CA for testing purposes. ___ 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: StartCom issuing bogus certificates
It would be better to use example.com and not test.com or anything like that, as that is defined by IANA as a reserved domain. From: dev-security-policy <dev-security-policy-bounces+yuhongbao_386=hotmail@lists.mozilla.org> on behalf of Inigo Barreira via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: Wednesday, May 31, 2017 9:21:00 AM To: patryk.szczyglow...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: StartCom issuing bogus certificates Hi all, There´s been a misunderstanding internally when requested to create some "test" certificates as indicated in the Microsoft root program requirements as stated in 4b "Test URLs for each root, or a URL of a publicly accessible server that Microsoft can use to verify the certificates." but of course not this way. We will revoke them inmediately. Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of patryk.szczyglowski--- via dev-security-policy Sent: miércoles, 31 de mayo de 2017 17:45 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: StartCom issuing bogus certificates Hello, My first post here. I just noticed StartCom have issued today couple obviously fake certificates: https://crt.sh/?id=146437565 Subject: commonName= ov organizationName = test localityName = Beijing stateOrProvinceName = Beijing countryName = Beijing serialNumber = 123456 X509v3 Subject Alternative Name: DNS:www.test.cn https://crt.sh/?id=146484676 Subject: commonName= iv givenName = Jeremy surname = Liao localityName = Beijing stateOrProvinceName = Beijing countryName = CN X509v3 Subject Alternative Name: DNS:www.test.cn https://crt.sh/?id=146517428 Subject: commonName= ov organizationName = test localityName = Beijing stateOrProvinceName = Beijing countryName = Beijing serialNumber = 123456 X509v3 Subject Alternative Name: DNS:www.test.cn I am well aware these certificates will not be accepted in Firefox/NSS, but because of the fact their root certificate is still in NSS trust store, there might be some interest in the community regarding obvious policy violation. Regards, Patryk Szczygłowski ___ 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: StartCom issuing bogus certificates
Wow. That is disheartening. Those are issued from their newly cut intermediates issued descending from their G3 root, which I had assumed was the infrastructure that they intend to get audited for inclusion into the various root programs again. It would seem an issuance like that on that infrastructure was a bad call if I'm correct on that part. Or at a minimum, I really hope they had permission from whoever owns test.cn. I actually was a long time paying customer and fan of StartCom. It really was the cheapest way to pre-validate and do multiple EV issuances. I thought their issuance interface was rather innovative, along with their pricing model. (I'm aware of the controversy on the charging for revocation thing, and I see both sides. Ultimately, I agree that responsible revocation is a matter that should not disincentivized by economic policies of an individual CA.) Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: StartCom issuing bogus certificates
Hi all, There´s been a misunderstanding internally when requested to create some "test" certificates as indicated in the Microsoft root program requirements as stated in 4b "Test URLs for each root, or a URL of a publicly accessible server that Microsoft can use to verify the certificates." but of course not this way. We will revoke them inmediately. Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of patryk.szczyglowski--- via dev-security-policy Sent: miércoles, 31 de mayo de 2017 17:45 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: StartCom issuing bogus certificates Hello, My first post here. I just noticed StartCom have issued today couple obviously fake certificates: https://crt.sh/?id=146437565 Subject: commonName= ov organizationName = test localityName = Beijing stateOrProvinceName = Beijing countryName = Beijing serialNumber = 123456 X509v3 Subject Alternative Name: DNS:www.test.cn https://crt.sh/?id=146484676 Subject: commonName= iv givenName = Jeremy surname = Liao localityName = Beijing stateOrProvinceName = Beijing countryName = CN X509v3 Subject Alternative Name: DNS:www.test.cn https://crt.sh/?id=146517428 Subject: commonName= ov organizationName = test localityName = Beijing stateOrProvinceName = Beijing countryName = Beijing serialNumber = 123456 X509v3 Subject Alternative Name: DNS:www.test.cn I am well aware these certificates will not be accepted in Firefox/NSS, but because of the fact their root certificate is still in NSS trust store, there might be some interest in the community regarding obvious policy violation. Regards, Patryk Szczygłowski ___ 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
