Miss-issuance: URI in dNSName SAN

[Alex Gaynor]

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&opt=cablint
Issuer: <https://crt.sh/?caid=750&opt=cablint>
commonName = PSCProcert
countryName = VE
organizationName = Sistema Nacional de
Certificacion Electronica
organizationalUnitName = Proveedor de Certificados PROCERT
stateOrProvinceName = Miranda
localityName = Chacao
emailAddress = cont...@procert.net.ve

https://crt.sh/?id=42531587&opt=cablint
Issuer: <https://crt.sh/?caid=5792&opt=cablint>
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&opt=cablint
Issuer: <https://crt.sh/?caid=141&opt=cablint>
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

[Gervase Markham]

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

[ramiro...@gmail.com]

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.

[Ryan Sleevi]

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

> El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham
> escribió:

> 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.

[alex....@gmail.com]

It has now been several days, does Camerafirma intend to revoke these certificates, as required by the BRs (within 24 hours of being notified)?

[Alex Gaynor]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Kurt Roeckx]

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

[Jeremy Rowley]

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=digice...@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, July 25, 2017 10:58 AM
To: Alex Gaynor <alex....@gmail.com>
Cc: mozilla-dev-s...@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.

[Gervase Markham]

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

[Alex Gaynor]

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=a05o000003WrzBC&QuestionId=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 <
dev-secur...@lists.mozilla.org> 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

[Alex Gaynor]

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 <aga...@mozilla.com> 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=a05o000003WrzBC&QuestionId=
> 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
> <dev-secur...@lists.mozilla.org> 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

[Gervase Markham]

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

[Gervase Markham]

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

[ramiro...@gmail.com]

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&opt=cablint
- https://crt.sh/?id=42531587&opt=cablint
and we are working on
- https://crt.sh/?id=112929021&opt=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

[ramiro...@gmail.com]

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

[Jonathan Rudenberg]

> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> https://crt.sh/?id=112929021&opt=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

[Jonathan Rudenberg]

+mdsp

> On Aug 18, 2017, at 05:56, ramiro...@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