Re: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

2017-08-18 Thread Jonathan Rudenberg via dev-security-policy
+mdsp

> On Aug 18, 2017, at 05:56, ramirommu...@gmail.com wrote:
> 
> Hi Jonathan
> You are right, we are going to look into this, taken into account that the 
> same serial number should be in the real certificate.
> 
> Regards
> 
> El jueves, 17 de agosto de 2017, 19:54:31 (UTC+2), Jonathan Rudenberg 
> escribió:
>> 
>> 
>> > On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy 
>> >  wrote: 
>> > 
>> > https://crt.sh/?id=112929021=cablint 
>> > is a precertificate. You can see the CT Precertificate Poison critical 
>> > extention. 
>> 
>> The serial number of this certificate should still be added to the relevant 
>> CRL, as it is not possible to prove the non-existance of a corresponding 
>> certificate without the CT Poison extension. 
>> 
>> Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Miss-issuance: URI in dNSName SAN

2017-08-17 Thread Jonathan Rudenberg via dev-security-policy

> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy 
>  wrote:
> 
> https://crt.sh/?id=112929021=cablint
> is a precertificate. You can see the CT Precertificate Poison critical 
> extention. 

The serial number of this certificate should still be added to the relevant 
CRL, as it is not possible to prove the non-existance of a corresponding 
certificate without the CT Poison extension.

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


Re: Miss-issuance: URI in dNSName SAN

2017-08-17 Thread ramirommunoz--- via dev-security-policy
El jueves, 17 de agosto de 2017, 12:26:05 (UTC+2), ramiro...@gmail.com  
escribió:
> El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham  escribió:
> > On 08/08/17 14:33, Alex Gaynor wrote:
> > > Following up on this thread, 8 days ago I emailed Camerfirma, I have not
> > > heard back from them, nor have they taken any action. What is the
> > > appropriate next step here?
> > 
> > I have emailed the primary Point of Contact at Camerfirma to enquire as
> > to what is going on.
> > 
> > Gerv
> Hi Gev and Alex
> 
> We have been trying to contact with our customer to replace the wrong 
> certificate otherwise we could block our customers services. We found 
> difficulties to reach the right person due to the holidays period. 
> 
> We have already revoke 
> - https://crt.sh/?id=5129200=cablint
> - https://crt.sh/?id=42531587=cablint
> and we are working on
> - https://crt.sh/?id=112929021=cablint
> We expect to be revoked along this day
> 
> All of then are mistakes from the request form that are not been detected by 
> the AR operator.
> 
> placing "http://; or "https://; in the domain name. 
> 
> We are going to improve control over the domain name entry form and report to 
> the AR operators.
> 
> Best regards

https://crt.sh/?id=112929021=cablint
is a precertificate. You can see the CT Precertificate Poison critical 
extention. 


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


Re: Miss-issuance: URI in dNSName SAN

2017-08-17 Thread ramirommunoz--- via dev-security-policy
El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham  escribió:
> On 08/08/17 14:33, Alex Gaynor wrote:
> > Following up on this thread, 8 days ago I emailed Camerfirma, I have not
> > heard back from them, nor have they taken any action. What is the
> > appropriate next step here?
> 
> I have emailed the primary Point of Contact at Camerfirma to enquire as
> to what is going on.
> 
> Gerv
Hi Gev and Alex

We have been trying to contact with our customer to replace the wrong 
certificate otherwise we could block our customers services. We found 
difficulties to reach the right person due to the holidays period. 

We have already revoke 
- https://crt.sh/?id=5129200=cablint
- https://crt.sh/?id=42531587=cablint
and we are working on
- https://crt.sh/?id=112929021=cablint
We expect to be revoked along this day

All of then are mistakes from the request form that are not been detected by 
the AR operator.

placing "http://; or "https://; in the domain name. 

We are going to improve control over the domain name entry form and report to 
the AR operators.

Best regards  


 


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


Re: Miss-issuance: URI in dNSName SAN

2017-08-15 Thread Gervase Markham via dev-security-policy
On 08/08/17 14:33, Alex Gaynor wrote:
> Following up on this thread, 8 days ago I emailed Camerfirma, I have not
> heard back from them, nor have they taken any action. What is the
> appropriate next step here?

I have emailed the primary Point of Contact at Camerfirma to enquire as
to what is going on.

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


Re: Miss-issuance: URI in dNSName SAN

2017-08-15 Thread Gervase Markham via dev-security-policy
On 31/07/17 15:14, Alex Gaynor wrote:
> So far I've encountered issues with:
> 
> - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field
> - StartCom - who filled out "web publication", I don't know what that means

I have emailed both of these CAs to request that they provide this
information. Once they have done so, you will be able to find the
updated values in this live report:

https://ccadb-public.secure.force.com/mozilla/CAInformationReport

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


Re: Miss-issuance: URI in dNSName SAN

2017-08-08 Thread Alex Gaynor via dev-security-policy
Hi all,

Following up on this thread, 8 days ago I emailed Camerfirma, I have not
heard back from them, nor have they taken any action. What is the
appropriate next step here?

Alex

On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor  wrote:

> I've been attempting to report a bunch of miss-issued certificates this
> weekend (hobbies are important!) I've primarily been using
> https://ccadb-public.secure.force.com/mozillacommunications/
> CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=
> Q00028 as my reference (without which I would be totally lost!)
>
> So far I've encountered issues with:
>
> - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field
> - StartCom - who filled out "web publication", I don't know what that means
>
> To all the CAs who included a straightforward email or webform in there,
> thank you!
>
> Alex
>
> On Mon, Jul 31, 2017 at 10:10 AM, Gervase Markham via dev-security-policy
>  wrote:
>
>> On 25/07/17 18:13, Jeremy Rowley wrote:
>> > I would also love to see a more standardized notice mechanism that is
>> > universal to all CAs. Right now, notifying CAs is a pain as some have
>> > different webforms, some use email, and some don't readily tell you how
>> to
>> > contact them about certificate problems.
>>
>> "Not readily telling" is a BR violation; if you come across a CA like
>> that, please do let us know. The info should be in the CCADB and in the
>> CAs report.
>>
>> I agree it would be nice to have something more standard, but we have
>> what we have right now.
>>
>> 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


Re: Miss-issuance: URI in dNSName SAN

2017-07-31 Thread Gervase Markham via dev-security-policy
On 25/07/17 18:13, Jeremy Rowley wrote:
> I would also love to see a more standardized notice mechanism that is
> universal to all CAs. Right now, notifying CAs is a pain as some have
> different webforms, some use email, and some don't readily tell you how to
> contact them about certificate problems.  

"Not readily telling" is a BR violation; if you come across a CA like
that, please do let us know. The info should be in the CCADB and in the
CAs report.

I agree it would be nice to have something more standard, but we have
what we have right now.

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


RE: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Jeremy Rowley via dev-security-policy
Each CA is required (under the BRs) to provide public information on how to
submit certificate problem reports, including mis-issued certificates. The
only way to properly notify the CA is through that mechanism as those are
monitored 24 hours. CAs participating on the list usually have a couple of
reps who monitor and participate, but not 24x7. I do agree there should be
penalties for missing the 24 hour requirement to give the BRs a bit more
teeth, but those penalties should be based on the proper notice process
being followed. 

I would also love to see a more standardized notice mechanism that is
universal to all CAs. Right now, notifying CAs is a pain as some have
different webforms, some use email, and some don't readily tell you how to
contact them about certificate problems.  

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, July 25, 2017 10:58 AM
To: Alex Gaynor <alex.gay...@gmail.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Miss-issuance: URI in dNSName SAN

Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.

In any event, here are some certificates, by CA, that have been mis-issued
and linked on this list many days ago at this point:

PSCProcert - https://crt.sh/?id=124094761 - dNSName is a URI PSCProcert -
https://crt.sh/?id=175466182 - dNSName is for a .local domain Camerfirma
AAPP II - 2014 - https://crt.sh/?id=42531587 - dNSName is a URI AC
CAMERFIRMA AAPP - https://crt.sh/?id=5129200 - dNSName is a URI StartCom
Class 2 Primary Intermediate Server CA -
https://crt.sh/?id=10714112 - incorrect wildcard "*g10.net-lab.net"
StartCom Class 3 OV Server CA - https://crt.sh/?id=17295812 - incorrect
wildcard "*dev02.calendar42.com"
StartCom Class 1 DV Server CA - https://crt.sh/?id=78248795 - invalid
dNSName "-1ccenter.777chao.com"
TI Trust Technologies Global CA - https://crt.sh/?id=48682944 - invalid
wildcard "*nuvolaitaliana.it"
UniCredit Subordinate External - https://crt.sh/?id=44997156 - invalid
wildcard "*.*.rnd.unicredit.it"
Swisscom Smaragd CA 2 - https://crt.sh/?id=5982951 - invalid wildcard "*.*.
int.swisscom.ch"
Swisscom Smaragd CA 2 - https://crt.sh/?id=175444569 - dNSName is for a
.local domain Verizon Public SureServer CA G14-SHA2 -
https://crt.sh/?id=33626750 - dNSName is for a .test domain Verizon Public
SureServer CA G14-SHA2 - https://crt.sh/?id=12344381 - dNSName is for a
.local domain CLASS 2 KEYNECTIS CA - https://crt.sh/?id=42475510 - dNSName
is for a .corp domain EC-SectorPublic - https://crt.sh/?id=98706307 -
dNSName is for a .local domain


Should there be some penalty for the failure of CAs to revoke within the
time period required by the BRs?

Alex

On Sat, Jul 22, 2017 at 10:11 AM, alex.gaynor--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It has now been several days, does Camerafirma intend to revoke these 
> certificates, as required by the BRs (within 24 hours of being notified)?
> ___
> 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


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: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Kurt Roeckx via dev-security-policy
On Tue, Jul 25, 2017 at 12:57:44PM -0400, Alex Gaynor via dev-security-policy 
wrote:
> Following up on this (and really several other threads). The BRs require
> mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
> are required to track m.d.s.p. per the Mozilla Root Policy, so really
> notifying this list _ought_ to qualify as notifying the CAs.

I think requests for revocation should be done using the contact
information they provided to do that.


Kurt

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


Re: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Alex Gaynor via dev-security-policy
Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.

In any event, here are some certificates, by CA, that have been mis-issued
and linked on this list many days ago at this point:

PSCProcert - https://crt.sh/?id=124094761 - dNSName is a URI
PSCProcert - https://crt.sh/?id=175466182 - dNSName is for a .local domain
Camerfirma AAPP II - 2014 - https://crt.sh/?id=42531587 - dNSName is a URI
AC CAMERFIRMA AAPP - https://crt.sh/?id=5129200 - dNSName is a URI
StartCom Class 2 Primary Intermediate Server CA -
https://crt.sh/?id=10714112 - incorrect wildcard "*g10.net-lab.net"
StartCom Class 3 OV Server CA - https://crt.sh/?id=17295812 - incorrect
wildcard "*dev02.calendar42.com"
StartCom Class 1 DV Server CA - https://crt.sh/?id=78248795 - invalid
dNSName "-1ccenter.777chao.com"
TI Trust Technologies Global CA - https://crt.sh/?id=48682944 - invalid
wildcard "*nuvolaitaliana.it"
UniCredit Subordinate External - https://crt.sh/?id=44997156 - invalid
wildcard "*.*.rnd.unicredit.it"
Swisscom Smaragd CA 2 - https://crt.sh/?id=5982951 - invalid wildcard "*.*.
int.swisscom.ch"
Swisscom Smaragd CA 2 - https://crt.sh/?id=175444569 - dNSName is for a
.local domain
Verizon Public SureServer CA G14-SHA2 - https://crt.sh/?id=33626750 -
dNSName is for a .test domain
Verizon Public SureServer CA G14-SHA2 - https://crt.sh/?id=12344381 -
dNSName is for a .local domain
CLASS 2 KEYNECTIS CA - https://crt.sh/?id=42475510 - dNSName is for a .corp
domain
EC-SectorPublic - https://crt.sh/?id=98706307 - dNSName is for a .local
domain


Should there be some penalty for the failure of CAs to revoke within the
time period required by the BRs?

Alex

On Sat, Jul 22, 2017 at 10:11 AM, alex.gaynor--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It has now been several days, does Camerafirma intend to revoke these
> certificates, as required by the BRs (within 24 hours of being notified)?
> ___
> 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: Miss-issuance: URI in dNSName SAN

2017-07-22 Thread Ryan Sleevi via dev-security-policy
On Fri, Jul 21, 2017 at 4:04 AM ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham
> escribió:
> > On 19/07/17 14:53, Alex Gaynor wrote:
> > > I'd like to report the following instance of miss-issuance:
> >
> > Thank you. Again, I have drawn this message to the attention of the CAs
> > concerned (Government of Venezuela and Camerfirma).
> >
> > Gerv
>
> Hi all
>
> Regarding Camerfirma certificates, we have follow the rules imposed by the
> local public administration to regulate the profile of several
> certificates. SSL certificates for public administration websites included.
> There is a entry in cabforum where this issue is described
> https://cabforum.org/pipermail/public/2016-June/007896.html.
> New eIDAS regulation has forced to Spanish Administration to fix this
> problem so from now on we can issue certificate that fully fulfil the
> cabforum rules.
> AC Camerfirma will offer to our public administration customers to renew
> the SSL certificates  with our new eIDAS 2016 CAs.


Could you point where the regulation require(s/d) the CN and SAN (in type
dNSName) contain a URI?

The past discussion was in context of additional SAN types not permitted by
the BRs, but the issue highlighted in this thread is clear violation of RFC
5280 semantics, and it is difficult to believe that was encompassed by
Camerafirma's previous disclosure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Miss-issuance: URI in dNSName SAN

2017-07-22 Thread ramirommunoz--- via dev-security-policy
El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham  escribió:
> On 19/07/17 14:53, Alex Gaynor wrote:
> > I'd like to report the following instance of miss-issuance:
> 
> Thank you. Again, I have drawn this message to the attention of the CAs
> concerned (Government of Venezuela and Camerfirma).
> 
> Gerv

Hi all

Regarding Camerfirma certificates, we have follow the rules imposed by the 
local public administration to regulate the profile of several certificates. 
SSL certificates for public administration websites included. There is a entry 
in cabforum where this issue is described 
https://cabforum.org/pipermail/public/2016-June/007896.html.
New eIDAS regulation has forced to Spanish Administration to fix this problem 
so from now on we can issue certificate that fully fulfil the cabforum rules.
AC Camerfirma will offer to our public administration customers to renew the 
SSL certificates  with our new eIDAS 2016 CAs. 

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


Re: Miss-issuance: URI in dNSName SAN

2017-07-20 Thread Gervase Markham via dev-security-policy
On 19/07/17 14:53, Alex Gaynor wrote:
> I'd like to report the following instance of miss-issuance:

Thank you. Again, I have drawn this message to the attention of the CAs
concerned (Government of Venezuela and Camerfirma).

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


Miss-issuance: URI in dNSName SAN

2017-07-19 Thread Alex Gaynor via dev-security-policy
Morning all,

I'd like to report the following instance of miss-issuance:

All of the following contain a URI in a dNSName SAN entry. These
certificates are neither revoked, nor expired, and all are from CAs
currently trusted by the Mozilla Root Program.

https://crt.sh/?id=124094761=cablint
Issuer: 
commonName= PSCProcert
countryName   = VE
organizationName  = Sistema Nacional de
Certificacion Electronica
organizationalUnitName= Proveedor de Certificados PROCERT
stateOrProvinceName   = Miranda
localityName  = Chacao
emailAddress  = conta...@procert.net.ve

https://crt.sh/?id=42531587=cablint
Issuer: 
commonName= Camerfirma AAPP II - 2014
localityName  = Madrid (see current address at
https://www.camerfirma.com/address)
serialNumber  = A82743287
organizationName  = AC Camerfirma S.A.
organizationalUnitName= AC CAMERFIRMA
countryName   = ES

https://crt.sh/?id=5129200=cablint
Issuer: 
commonName= AC CAMERFIRMA AAPP
serialNumber  = A82743287
organizationalUnitName= AC CAMERFIRMA
localityName  = MADRID (Ver en
https://www.camerfirma.com/address)
organizationName  = AC CAMERFIRMA S.A.
countryName   = ES



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