Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

On 15/08/17 16:53, Ben Wilson wrote:
> Attached is an audit from 2016.  They are due for another one for 2017.

Attachments don't appear on this list, but I have the docs. Please email
me if you'd like them. I've asked Ben to update CCADB to point to them,
and to also update any other entries where it is written "available on
request". That is not a valid value for that field.

Gerv

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

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Attached is an audit from 2016.  They are due for another one for 2017.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:55 AM
To: Ben Wilson <ben.wil...@digicert.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

Hi Ben,

On 03/08/17 15:38, Ben Wilson wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption
> that revocation will cause to their banking operations:

I've looked up the certs relating to this sub-CA in the CCADB. The key in
question:

https://crt.sh/?caid=1698=cablint,x509lint

appears to be in two certs, which are:

https://crt.sh/?id=18068159=cablint,x509lint
and
https://crt.sh/?id=6158202=cablint,x509lint

They have CCADB entries here (note: these links work for me, but AIUI CA links
are different):

https://ccadb.my.salesforce.com/001o00dsANG
https://ccadb.my.salesforce.com/001o00dsAlD

The audit fields for both of these say "Available on request". I'm not sure
that's a valid value for that field; it's supposed to link to the actual
audit. Nevertheless, I am now requesting. Can you please provide the audits
for this subCA?

Thanks,

Gerv



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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

No, not yet.  We're currently in negotiations/discussions with them.  

Here is a snippet from a communication from them:

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

Sincerely yours,

Ben

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:44 AM
To: Ben Wilson <ben.wil...@digicert.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore 
intermediate

Hi Ben,

On 03/08/17 14:32, Ben Wilson wrote:
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.

That's today; is it still the plan to revoke their intermediate?

Gerv


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: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

Hi Ben,

On 03/08/17 15:38, Ben Wilson wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:

I've looked up the certs relating to this sub-CA in the CCADB. The key
in question:

https://crt.sh/?caid=1698=cablint,x509lint

appears to be in two certs, which are:

https://crt.sh/?id=18068159=cablint,x509lint
and
https://crt.sh/?id=6158202=cablint,x509lint

They have CCADB entries here (note: these links work for me, but AIUI CA
links are different):

https://ccadb.my.salesforce.com/001o00dsANG
https://ccadb.my.salesforce.com/001o00dsAlD

The audit fields for both of these say "Available on request". I'm not
sure that's a valid value for that field; it's supposed to link to the
actual audit. Nevertheless, I am now requesting. Can you please provide
the audits for this subCA?

Thanks,

Gerv

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Gervase Markham via dev-security-policy]

Hi Ben,

On 03/08/17 14:32, Ben Wilson wrote:
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.

That's today; is it still the plan to revoke their intermediate?

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Matt Palmer via dev-security-policy]

On Thu, Aug 03, 2017 at 02:38:33PM +, Ben Wilson via dev-security-policy 
wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:

[...]

> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.

They don't appear to have enough time and resources to run a CA properly,
either, and the non-revocation of the CA certificate causes the rest of the
Internet critical security problems.

Adding the intermediate to OneCRL and revoking on 15th August seems like a
reasonable compromise to solve an issue that is, when all is said and done,
entirely of their own making.  December 31, being nearly five months away,
is far too long, IMO.

A 15th August deadline gives them 10 days to replace 300 public certs, which
is 30 certs to do per day...  that seems reasonable for one person to do,
and I'm sure there's more than one person at **a bank that runs its own CA**
who can do certificate replacements.

If that's considered too aggressive a deadline, I'd ask Intesa Sanpaolo what
their *absolute* earliest possible date for non-disruptive distrust would be. 
Then we can decide if that's reasonable or not.

- Matt

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

Ouch. Thanks for clarifying.

Alex

On Thu, Aug 3, 2017 at 10:46 AM, Ben Wilson <ben.wil...@digicert.com> wrote:

> There are over 300 publicly visible servers, according to Censys.IO.
>
>
>
> *From:* Alex Gaynor [mailto:agay...@mozilla.com]
> *Sent:* Thursday, August 3, 2017 8:42 AM
> *To:* Ben Wilson <ben.wil...@digicert.com>
> *Cc:* Nick Lamb <tialara...@gmail.com>; mozilla-dev-security-policy@
> lists.mozilla.org
>
> *Subject:* Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
>
>
> If I'm reading this correctly, these certificates are for internal
> services, not publicly accessible. Could they add their intermediate
> directly to these trust stores, allowing you to revoke it?
>
>
>
> Failing that, it sounds like OneCRL would be an appropriate remedy.
>
>
>
> Alex
>
>
>
> On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Nick and Mozilla Community,
>
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:
>
> Good Evening Ben,
>
>About the problem with the certificate you recently notified us, I
> confirm you that we have replaced the certificates today, so we have now
> revoked the wrong one.
>
> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.
>
> Moreover, I would like to inform you that in order to rationalize our
> infrastructure and create new synergy between our suppliers, we've planned
> to move our certificates to an Italian CA outsourcer. We have already
> started this activity and our intent is to complete the migration before
> the
> end of the year, to respect the contract we have settled, with deadline
> December, 31st 2017.
>
> Therefore I have to kindly recommend you not to revoke the CA, before the
> end of the contract, because it will cause several problems to the Bank and
> to our users (customers and colleagues).
>
> We are available to set up a call conference with you to discuss the
> matter.
> Looking forward to hear from you.
>
> Best regards,
> Riccardo D'Agostini
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
>
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb <tialara...@gmail.com>;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:34 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> > Nick,
> > We are in discussions with Intesa Sanpaolo about implementing/pursuing
> > OneCRL or a similar approach (e.g. outright revocation of the CAs).
> > Thanks,
> > Ben
>
> Is there any progress on this? To be honest I was more meaning that Mozilla
> (Gerv?) should just add this subCA to OneCRL and be done with it.
>
> ___
> 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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

There are over 300 publicly visible servers, according to Censys.IO.



From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, August 3, 2017 8:42 AM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Nick Lamb <tialara...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore 
intermediate



If I'm reading this correctly, these certificates are for internal services, 
not publicly accessible. Could they add their intermediate directly to these 
trust stores, allowing you to revoke it?



Failing that, it sounds like OneCRL would be an appropriate remedy.



Alex



On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Nick and Mozilla Community,

Here is the response from Intesa Sanpaolo concerning the disruption that
revocation will cause to their banking operations:

Good Evening Ben,

   About the problem with the certificate you recently notified us, I
confirm you that we have replaced the certificates today, so we have now
revoked the wrong one.

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

We are available to set up a call conference with you to discuss the matter.
Looking forward to hear from you.

Best regards,
Riccardo D'Agostini


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben 
<mailto:dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org> ] On

Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb <tialara...@gmail.com <mailto:tialara...@gmail.com> >;
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: Certificate with invalid dnsName issued from Baltimore
intermediate

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben 
<mailto:dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org> ] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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





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: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

If I'm reading this correctly, these certificates are for internal
services, not publicly accessible. Could they add their intermediate
directly to these trust stores, allowing you to revoke it?

Failing that, it sounds like OneCRL would be an appropriate remedy.

Alex

On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Nick and Mozilla Community,
>
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:
>
> Good Evening Ben,
>
>About the problem with the certificate you recently notified us, I
> confirm you that we have replaced the certificates today, so we have now
> revoked the wrong one.
>
> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.
>
> Moreover, I would like to inform you that in order to rationalize our
> infrastructure and create new synergy between our suppliers, we've planned
> to move our certificates to an Italian CA outsourcer. We have already
> started this activity and our intent is to complete the migration before
> the
> end of the year, to respect the contract we have settled, with deadline
> December, 31st 2017.
>
> Therefore I have to kindly recommend you not to revoke the CA, before the
> end of the contract, because it will cause several problems to the Bank and
> to our users (customers and colleagues).
>
> We are available to set up a call conference with you to discuss the
> matter.
> Looking forward to hear from you.
>
> Best regards,
> Riccardo D'Agostini
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb <tialara...@gmail.com>;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:34 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> > Nick,
> > We are in discussions with Intesa Sanpaolo about implementing/pursuing
> > OneCRL or a similar approach (e.g. outright revocation of the CAs).
> > Thanks,
> > Ben
>
> Is there any progress on this? To be honest I was more meaning that Mozilla
> (Gerv?) should just add this subCA to OneCRL and be done with it.
>
> ___
> 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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Nick and Mozilla Community,

Here is the response from Intesa Sanpaolo concerning the disruption that
revocation will cause to their banking operations:

Good Evening Ben,

   About the problem with the certificate you recently notified us, I
confirm you that we have replaced the certificates today, so we have now
revoked the wrong one.

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

We are available to set up a call conference with you to discuss the matter.
Looking forward to hear from you.

Best regards,
Riccardo D'Agostini


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb <tialara...@gmail.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Certificate with invalid dnsName issued from Baltimore
intermediate

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing 
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing 
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Nick Lamb via dev-security-policy]

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla 
(Gerv?) should just add this subCA to OneCRL and be done with it.

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

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Nick,
We are in discussions with Intesa Sanpaolo about implementing/pursuing
OneCRL or a similar approach (e.g. outright revocation of the CAs).
Thanks,
Ben 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Sunday, July 23, 2017 2:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Sunday, 23 July 2017 20:12:18 UTC+1, Charles Reiss  wrote:
> This CA also issued a recent certificate for the unqualified dNSName 
> 'webinterfacestrong': https://crt.sh/?id=177606495

Another name that it shouldn't be possible to issue for, but this time one
which can actually exist in local networks and therefore is put at risk by
the existence of such bogus certificates.

>From the view on https://crt.sh/ it appears that this CA does not
automatically log all the certificates it issues which Mozilla will end up
trusting. It may have issued certificates we haven't seen yet.

DigiCert / Ben is that statement correct?

If we cannot today see the "whole iceberg" of certificates issued by this
subCA, and we know it can and does issue problematic certificates I think
it's a good candidate for distrust in OneCRL.
___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Nick Lamb via dev-security-policy]

On Sunday, 23 July 2017 20:12:18 UTC+1, Charles Reiss  wrote:
> This CA also issued a recent certificate for the unqualified dNSName 
> 'webinterfacestrong': https://crt.sh/?id=177606495

Another name that it shouldn't be possible to issue for, but this time one 
which can actually exist in local networks and therefore is put at risk by the 
existence of such bogus certificates.

>From the view on https://crt.sh/ it appears that this CA does not 
>automatically log all the certificates it issues which Mozilla will end up 
>trusting. It may have issued certificates we haven't seen yet.

DigiCert / Ben is that statement correct?

If we cannot today see the "whole iceberg" of certificates issued by this 
subCA, and we know it can and does issue problematic certificates I think it's 
a good candidate for distrust in OneCRL.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Charles Reiss via dev-security-policy]

On 07/17/2017 11:21 AM, Ben Wilson wrote:

Dear Jonathan,

Thank you for bringing this to our attention.  We have contacted Intesa 
Sanpaolo regarding this error and have asked them to correct it as soon as 
possible.
Sincerely yours,


This CA also issued a recent certificate for the unqualified dNSName 
'webinterfacestrong': https://crt.sh/?id=177606495

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

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Just as a follow up, these two certificates (with
www.intesasanpaolovita..biz) were revoked on 19 July 2017.  See
http://ca.intesasanpaolo.com/portalCais0/crl/servext2.crl.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Tuesday, July 18, 2017 9:54 AM
To: Jakob Bohm <jb-mozi...@wisemo.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/07/2017 21:27, Nick Lamb wrote:
> > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
> >> Thank you for bringing this to our attention.  We have contacted 
> >> Intesa
> Sanpaolo regarding this error and have asked them to correct it as 
> soon as possible.
> >
> > "Correcting" the error is surely the smaller of the two tasks ahead.
> >
>
> Depends if the only error is allowing double dots (while correctly 
> validating the domain as if spelled without the extra dot).  Things 
> are much worse if double dots bypass domain validation completely.
>
> Since at least two CA systems have now been found to accept double 
> dots, where only single dots should be allowed, it is reasonable to 
> assume that some relying parties also allow double dots.


It is not reasonable to conclude there is a pattern based on two samples,
nor is it reasonable to conclude there is a pattern in an unrelated system.
If you are aware of any relying party libraries based on CA validation
libraries, that would be useful in establishing the reasonableness of the
conclusion.


This makes it
> essential that any certificates with this syntax error have been 
> completely validated for the equivalent single-dotted name.
>
> I also notice that this is apparently an unconstrained 
> intermediate/SubCA.
>
> Since this appears to be a certificate for the cert holders own 
> domains, it is also possible domain validation was done manually, as 
> in "we know first hand that we control these domains", making this an 
> OV cert, not a DV cert.


All OV certs are DV certs - they are subsets.

Perhaps you're confusing DNS validation done at an Authorization Domain
Name, rather than FQDN. That would be consistent with allowing the customer
to enter labels below the validated domain (under 3.2.5 of the BRs), but not
validating it's a valid DNS label or well formed domain name.
___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Rob Stradling via dev-security-policy]

On 19/07/17 15:31, Jeremy Rowley via dev-security-policy wrote:

You should also filter out expired certs as they aren't usable.


I've added a 2nd tab that just shows unexpired certs.  I'll also add a 
column to track the revocation status of each of these certs.


I've left the expired certs in the 1st tab, since they show historical 
issuance problems.  Perhaps some of those CAs still have code bugs that 
need to be fixed.



On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy 
 wrote:

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:



(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



Here's a report of all "double dot" certs known to crt.sh that are useable
for server authentication and chain to a root trusted by Mozilla:

https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to
produce this report:

SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
  FROM certificate_identity ci, ca, certificate c
  WHERE ci.NAME_VALUE LIKE '%..%'
AND ci.NAME_TYPE IN ('dNSName', 'commonName')
AND ci.ISSUER_CA_ID = ca.ID
AND ci.CERTIFICATE_ID = c.ID
AND EXISTS (
  SELECT 1
FROM ca_trust_purpose ctp
WHERE ci.ISSUER_CA_ID = ctp.CA_ID
  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
)
AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;


--
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Rob Stradling via dev-security-policy]

Hi Alex.  This is about issuance (mal)practices, so therefore I didn't 
omit certs that are already revoked.


On 19/07/17 15:29, Alex Gaynor via dev-security-policy wrote:

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:



(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



Here's a report of all "double dot" certs known to crt.sh that are useable
for server authentication and chain to a root trusted by Mozilla:

https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to
produce this report:

SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
   FROM certificate_identity ci, ca, certificate c
   WHERE ci.NAME_VALUE LIKE '%..%'
 AND ci.NAME_TYPE IN ('dNSName', 'commonName')
 AND ci.ISSUER_CA_ID = ca.ID
 AND ci.CERTIFICATE_ID = c.ID
 AND EXISTS (
   SELECT 1
 FROM ca_trust_purpose ctp
 WHERE ci.ISSUER_CA_ID = ctp.CA_ID
   AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
   AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
 )
 AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
   GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
   ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;

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


--
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Jeremy Rowley via dev-security-policy]

You should also filter out expired certs as they aren't usable.

> On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> I think there might be a bug in your SQL, one of the offending certs is
> issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
> OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
> 
> Alex
> 
> On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
>> 
>> 
>>> (Due to limitations in the search methodology - scraping crt.sh
>>> search results and looping through tlds - I only searched for ..tld. It
>>> would certainly be valuable to search further.)
>>> 
>> 
>> Here's a report of all "double dot" certs known to crt.sh that are useable
>> for server authentication and chain to a root trusted by Mozilla:
>> 
>> https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
>> QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing
>> 
>> 
>> P.S.
>> For anyone interested, here's the SQL I executed on the crt.sh DB to
>> produce this report:
>> 
>> SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
>> array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
>>  FROM certificate_identity ci, ca, certificate c
>>  WHERE ci.NAME_VALUE LIKE '%..%'
>>AND ci.NAME_TYPE IN ('dNSName', 'commonName')
>>AND ci.ISSUER_CA_ID = ca.ID
>>AND ci.CERTIFICATE_ID = c.ID
>>AND EXISTS (
>>  SELECT 1
>>FROM ca_trust_purpose ctp
>>WHERE ci.ISSUER_CA_ID = ctp.CA_ID
>>  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
>>  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
>>)
>>AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
>>  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
>> x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
>>  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;
>> 
>> --
>> 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
>> 
> ___
> 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: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
> 
>
>> (Due to limitations in the search methodology - scraping crt.sh
>> search results and looping through tlds - I only searched for ..tld. It
>> would certainly be valuable to search further.)
>>
>
> Here's a report of all "double dot" certs known to crt.sh that are useable
> for server authentication and chain to a root trusted by Mozilla:
>
> https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
> QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing
>
>
> P.S.
> For anyone interested, here's the SQL I executed on the crt.sh DB to
> produce this report:
>
> SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
> array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
>   FROM certificate_identity ci, ca, certificate c
>   WHERE ci.NAME_VALUE LIKE '%..%'
> AND ci.NAME_TYPE IN ('dNSName', 'commonName')
> AND ci.ISSUER_CA_ID = ca.ID
> AND ci.CERTIFICATE_ID = c.ID
> AND EXISTS (
>   SELECT 1
> FROM ca_trust_purpose ctp
> WHERE ci.ISSUER_CA_ID = ctp.CA_ID
>   AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
>   AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
> )
> AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
>   GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
> x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
>   ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Peter Gutmann via dev-security-policy]

Hanno Böck via dev-security-policy  
writes:

>More dotdot-certificates:

Given how widespread (meaning from different CAs) these are, is there some
quirk of a widely-used resolver library that allows them?  I've done a bit of
impromptu testing of various tools/bits of code but none of them seem to allow
double-dot domain names, so I'm wondering why there's so many of them that no-
one's ever caught, until now by explicitly searching for them.

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Rob Stradling via dev-security-policy]

On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:


(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)


Here's a report of all "double dot" certs known to crt.sh that are 
useable for server authentication and chain to a root trusted by Mozilla:


https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhNQVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to 
produce this report:


SELECT c.ID, x509_notBefore(c.CERTIFICATE), 
x509_notAfter(c.CERTIFICATE), array_to_string(array_agg(DISTINCT 
ci.NAME_VALUE), CHR(10)), ca.NAME

  FROM certificate_identity ci, ca, certificate c
  WHERE ci.NAME_VALUE LIKE '%..%'
AND ci.NAME_TYPE IN ('dNSName', 'commonName')
AND ci.ISSUER_CA_ID = ca.ID
AND ci.CERTIFICATE_ID = c.ID
AND EXISTS (
  SELECT 1
FROM ca_trust_purpose ctp
WHERE ci.ISSUER_CA_ID = ctp.CA_ID
  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
)
AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE), 
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME

  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;

--
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Nick Lamb via dev-security-policy]

On Tuesday, 18 July 2017 20:29:50 UTC+1, Jeremy Rowley  wrote:
> Some of these certs are really old.  Is there a reason people were using 
> double dot names? Are they all mistakes in the certificate request or is 
> there some logic behind them?

Unless I see good evidence to the contrary I will assume mistakes. The 
personnel with responsibility for obtaining certificates in most organisations 
know very little about this stuff. If you offer them a box where they can type 
www. and it doesn't say "Bzzt, wrong! Try again" they will only find out that 
the resulting certificates are garbage when they try them.

Anecdote: My employer uses a popular brand of SSL-intercepting Middle Box, and 
they had used its "demo" root CA for months or possibly years before I pointed 
out that this was a grave security risk detailed in the product's own manual. 
No-one would officially acknowledge my warning, but after a few months it 
evidently reached someone with the power to change things, and so one morning 
the CA was silently replaced and a new CA root cert was pushed out to all the 
Windows clients. This new "root cert" lacked CA:TRUE and had clearly been 
created by typing whatever seemed intuitively reasonable into all the X.500 
series name fields. Certificates presented to end user machines by the Middle 
Box were now signed by this "CA".

Interestingly this was accepted by Windows as a root cert. But not by lots of 
other systems due to lack of CA:TRUE, and within two days the root was replaced 
once again, this time using a cert that looked exactly like the one for the 
original demo CA, including CA:TRUE, and all the name branding from the 
supplier but with a different key pair. Since this CA was not obviously unsafe, 
I held my tongue about the other problems with it and counted it as a win for 
security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Charles Reiss via dev-security-policy]

On 07/18/2017 11:57 AM, Hanno Böck wrote:

More dotdot-certificates:

[snip]

via searching censys.io:

https://crt.sh/?id=174803642
for *..syntaxafrica.com
Issued by GoDaddy in 2016; expires later this year, but revoked (CRL 
timestamp says a few days after issuance)


https://crt.sh/?id=38662560
for *usmc..afpimsstaging.mil
Issued by U.S. Government in 2012; expired 2015

I also some old internal name certificates:

https://crt.sh/?id=39441152
for autodiscover.eat...ltransport.local
Issued by GoDaddy in 2012; expired 2015

https://crt.sh/?id=39333847
for autodiscover.jgexchange2.bellgibfamily.local
Issued by GoDaddy in 2012; expired 2015
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Hanno Böck via dev-security-policy]

On Tue, 18 Jul 2017 21:43:28 +0200
Hanno Böck via dev-security-policy
 wrote:

> It has this commonname:
> commonName= .guidedstudies.com
> 
> Well... that's also not a valid hostname...

And of course it's not the only one:
https://crt.sh/?CN=.%25

(the first three seem to root to code signing certificates and probably
don't fall under BRs, but there are others)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Hanno Böck via dev-security-policy]

On Tue, 18 Jul 2017 19:29:10 +
Jeremy Rowley via dev-security-policy
 wrote:

> Some of these certs are really old.

Some of them are also not so old and still valid.
All from GoDaddy:

https://crt.sh/?id=22835635
https://crt.sh/?id=8216255

This one
https://crt.sh/?id=637932
is also interesting.
It is not expired, but revoked.
It has this commonname:
commonName= .guidedstudies.com

Well... that's also not a valid hostname...


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Jeremy Rowley via dev-security-policy]

Some of these certs are really old.  Is there a reason people were using double 
dot names? Are they all mistakes in the certificate request or is there some 
logic behind them?

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Tom via dev-security-policy
Sent: Tuesday, July 18, 2017 12:17 PM
To: Hanno Böck <ha...@hboeck.de>; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore intermediate


The "www..*" search is also intersting, I think:
https://crt.sh/?dNSName=www..%25

crt.sh IDLogged At  ⇧   Not Before  IdentityIssuer Name
397448732016-10-02  2012-12-29  www..coinfling.com  
386479982016-10-01  2011-03-24  www..altmangroup.com
375324392016-10-01  2014-05-02  www..edm.me 
352341082016-09-26  2013-12-09  www..erhgroup.com.tw
337105522016-09-22  2009-08-04 www..webmail.collegeofidaho.edu
332788532016-09-20  2013-03-26  www..labpro2000.com 
329180042016-09-19  2013-04-30  www..getswapapp.com 
228356352016-06-22  2016-06-20  www..tapspace.org   
623 2015-10-07  2015-09-23  www..imypaths.com   
8584525 2015-07-24  2015-07-22  www..myacademicprogram.in   
8431374 2015-07-13  2015-07-06  www..marza.com.br   
8216255 2015-06-28  2015-06-25  www..mysummitortho.com  
4327936 2014-06-14  2014-06-12  www..mysummitortho.com  
4303228 2014-06-10  2008-12-03  www..wildlifelicense.com
3956875 2014-04-25  2014-04-23  www..mysummitortho.com  
2728659 2013-09-28  2013-09-25  www..marza.com.br   
637932  2013-03-26  2012-10-21  www..guidedstudies.com  
85797   2013-03-26  2012-07-01  www..mysummitortho.com  


Le 18/07/2017 à 17:57, Hanno Böck a écrit :
> More dotdot-certificates:
> 
> https://crt.sh/?id=34528113
> for autodiscover.amphenolcanada..com
> Expired 2012
> issued by Geotrust (aka symantec)
> 
> https://crt.sh/?id=3478078
> for PDC-LIB-WEB1.RBI1.rbi..in
> Expired 2016
> issued by Institute for Development and Research in Banking Technology
> 
> https://crt.sh/?id=4112846
> pkictslvws.dmdc.osd..mil
> expired 2016
> issued by U.S. Government
> 
> So all expired, but certainly at least the ones from 2016 are 
> worrying, indicating that the issuing CAs are failing at domain validation.
> 
> (Due to limitations in the search methodology - scraping crt.sh search 
> results and looping through tlds - I only searched for ..tld. It would 
> certainly be valuable to search further.)
> 

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Tom via dev-security-policy]

The "www..*" search is also intersting, I think:
https://crt.sh/?dNSName=www..%25

crt.sh IDLogged At  ⇧   Not Before  IdentityIssuer Name
397448732016-10-02  2012-12-29  www..coinfling.com  
386479982016-10-01  2011-03-24  www..altmangroup.com
375324392016-10-01  2014-05-02  www..edm.me 
352341082016-09-26  2013-12-09  www..erhgroup.com.tw
337105522016-09-22  2009-08-04 www..webmail.collegeofidaho.edu
332788532016-09-20  2013-03-26  www..labpro2000.com 
329180042016-09-19  2013-04-30  www..getswapapp.com 
228356352016-06-22  2016-06-20  www..tapspace.org   
623 2015-10-07  2015-09-23  www..imypaths.com   
8584525 2015-07-24  2015-07-22  www..myacademicprogram.in   
8431374 2015-07-13  2015-07-06  www..marza.com.br   
8216255 2015-06-28  2015-06-25  www..mysummitortho.com  
4327936 2014-06-14  2014-06-12  www..mysummitortho.com  
4303228 2014-06-10  2008-12-03  www..wildlifelicense.com
3956875 2014-04-25  2014-04-23  www..mysummitortho.com  
2728659 2013-09-28  2013-09-25  www..marza.com.br   
637932  2013-03-26  2012-10-21  www..guidedstudies.com  
85797   2013-03-26  2012-07-01  www..mysummitortho.com  


Le 18/07/2017 à 17:57, Hanno Böck a écrit :

More dotdot-certificates:

https://crt.sh/?id=34528113
for autodiscover.amphenolcanada..com
Expired 2012
issued by Geotrust (aka symantec)

https://crt.sh/?id=3478078
for PDC-LIB-WEB1.RBI1.rbi..in
Expired 2016
issued by Institute for Development and Research in Banking Technology

https://crt.sh/?id=4112846
pkictslvws.dmdc.osd..mil
expired 2016
issued by U.S. Government

So all expired, but certainly at least the ones from 2016 are worrying,
indicating that the issuing CAs are failing at domain validation.

(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Hanno Böck via dev-security-policy]

More dotdot-certificates:

https://crt.sh/?id=34528113
for autodiscover.amphenolcanada..com
Expired 2012
issued by Geotrust (aka symantec)

https://crt.sh/?id=3478078
for PDC-LIB-WEB1.RBI1.rbi..in
Expired 2016
issued by Institute for Development and Research in Banking Technology

https://crt.sh/?id=4112846
pkictslvws.dmdc.osd..mil
expired 2016
issued by U.S. Government

So all expired, but certainly at least the ones from 2016 are worrying,
indicating that the issuing CAs are failing at domain validation.

(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Ryan Sleevi via dev-security-policy]

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/07/2017 21:27, Nick Lamb wrote:
> > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
> >> Thank you for bringing this to our attention.  We have contacted Intesa
> Sanpaolo regarding this error and have asked them to correct it as soon as
> possible.
> >
> > "Correcting" the error is surely the smaller of the two tasks ahead.
> >
>
> Depends if the only error is allowing double dots (while correctly
> validating the domain as if spelled without the extra dot).  Things are
> much worse if double dots bypass domain validation completely.
>
> Since at least two CA systems have now been found to accept double dots,
> where only single dots should be allowed, it is reasonable to assume
> that some relying parties also allow double dots.


It is not reasonable to conclude there is a pattern based on two samples,
nor is it reasonable to conclude there is a pattern in an unrelated system.
If you are aware of any relying party libraries based on CA validation
libraries, that would be useful in establishing the reasonableness of the
conclusion.


This makes it
> essential that any certificates with this syntax error have been
> completely validated for the equivalent single-dotted name.
>
> I also notice that this is apparently an unconstrained
> intermediate/SubCA.
>
> Since this appears to be a certificate for the cert holders own domains,
> it is also possible domain validation was done manually, as in "we know
> first hand that we control these domains", making this an OV cert, not a
> DV cert.


All OV certs are DV certs - they are subsets.

Perhaps you're confusing DNS validation done at an Authorization Domain
Name, rather than FQDN. That would be consistent with allowing the customer
to enter labels below the validated domain (under 3.2.5 of the BRs), but
not validating it's a valid DNS label or well formed domain name.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Jonathan Rudenberg via dev-security-policy]

> On Jul 17, 2017, at 15:27, Nick Lamb via dev-security-policy 
>  wrote:
> 
> On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
>> Thank you for bringing this to our attention.  We have contacted Intesa 
>> Sanpaolo regarding this error and have asked them to correct it as soon as 
>> possible.
> 
> "Correcting" the error is surely the smaller of the two tasks ahead.
> 
> This CA is trusted in the Web PKI, and should have technical controls in 
> place to ensure that subject details in any certificates issued are 
> appropriately validated.
> 
> There cannot possibly have been appropriate validation of this name, because 
> it cannot exist in the Internet DNS.

I just did a quick check, and this is actually the second certificate issued 
with this error, here is the first one:

https://crt.sh/?q=A8F200048358EBC31F77D90D30BF640B7E9D39D2BFCCA93C08517BCACC1CC2CA=cablint,x509lint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Nick Lamb via dev-security-policy]

On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
> Thank you for bringing this to our attention.  We have contacted Intesa 
> Sanpaolo regarding this error and have asked them to correct it as soon as 
> possible.

"Correcting" the error is surely the smaller of the two tasks ahead.

This CA is trusted in the Web PKI, and should have technical controls in place 
to ensure that subject details in any certificates issued are appropriately 
validated.

There cannot possibly have been appropriate validation of this name, because it 
cannot exist in the Internet DNS.

So that means at the very least the CA's technical controls are not effective 
in preventing issuance of certificates for names which weren't actually 
successfully validated. Of course in m.d.s.policy we aren't privy to details of 
exactly how the controls fall short, but it makes sense to err on the side of 
caution -- if certificates can be issued for www.intesasanpaolovita..biz then 
why not for www.google.com or any other name?

I think it would be enlightening to see the records of how the names in this 
certificate were validated before issuance. I do not know if DigiCert samples 
or otherwise examines such records from Intesa Sanpaolo routinely, but it 
certainly would seem in order to look at them now. Since the subject of the 
leaf certificate is also Intesa Sanpaolo itself, this ought to be very easy to 
arrange.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Dear Jonathan,

Thank you for bringing this to our attention.  We have contacted Intesa 
Sanpaolo regarding this error and have asked them to correct it as soon as 
possible.
Sincerely yours,

Ben Wilson, JD, CISA, CISSP
DigiCert VP of Compliance

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Monday, July 17, 2017 9:15 AM
To: dev-security-policy@lists.mozilla.org
Subject: Certificate with invalid dnsName issued from Baltimore intermediate

This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which 
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of 
“www.intesasanpaolovita..biz” (note the two dots): 

https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint

This raises some questions about the technical controls in place for issuance 
from this CA.

Jonathan


___
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