Certificate with invalid dnsName issued from Baltimore intermediate

[Jonathan Rudenberg]

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&opt=cablint,x509lint

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

Jonathan

[Ben Wilson]

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

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

[Nick Lamb]

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.

[Jonathan Rudenberg]

> On Jul 17, 2017, at 15:27, Nick Lamb via dev-security-policy <dev-secur...@lists.mozilla.org> 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&opt=cablint,x509lint

[Jakob Bohm]

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


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy <
dev-secur...@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.

[Hanno Böck]

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

[Tom]

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

crt.sh ID Logged At ⇧ Not Before Identity Issuer Name
39744873 2016-10-02 2012-12-29 www..coinfling.com
38647998 2016-10-01 2011-03-24 www..altmangroup.com
37532439 2016-10-01 2014-05-02 www..edm.me
35234108 2016-09-26 2013-12-09 www..erhgroup.com.tw
33710552 2016-09-22 2009-08-04 www..webmail.collegeofidaho.edu
33278853 2016-09-20 2013-03-26 www..labpro2000.com
32918004 2016-09-19 2013-04-30 www..getswapapp.com
22835635 2016-06-22 2016-06-20 www..tapspace.org
9999623 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

[Jeremy Rowley]

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?

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

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

<dev-secur...@lists.mozilla.org> 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]

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

<dev-secur...@lists.mozilla.org> 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)

[Charles Reiss]

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.bell....gibfamily.local
Issued by GoDaddy in 2012; expired 2015

[Nick Lamb]

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.

[Rob Stradling]

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

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

[Peter Gutmann]

Hanno Böck via dev-security-policy <dev-secur...@lists.mozilla.org> 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.

[Alex Gaynor]

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

[Jeremy Rowley]

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

[Rob Stradling]

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

[Rob Stradling]

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.

[Tom]

Following that discovery, I've search for odd (invalid?) DNS names.
Here is the list of certificated I've found, it may overlap some
discovery already reported.
If I'm correct, theses certificate are not revoked, not expired, and
probably trusted by Mozilla (crt.sh issuer are marked trusted by
Mozilla, but not all).

Starting with *:
https://crt.sh/?id=7211484 *eis.aetc.af.mil
https://crt.sh/?id=10714112 *g10.net-lab.net
https://crt.sh/?id=48682944 *nuvolaitaliana.it
https://crt.sh/?id=15736178 *assets.blog.cn.net.ru
https://crt.sh/?id=17295812 *dev02.calendar42.com
https://crt.sh/?id=15881220 *dev.1septem.ru
https://crt.sh/?id=15655700 *assets.blog.cn.net.ru
https://crt.sh/?id=17792808 *quickbuild.raptorengineering.io

Starting with -:
https://crt.sh/?id=54285413 -d1-datacentre-12g-console-2.its.deakin.edu.au
https://crt.sh/?id=78248795 -1ccenter.777chao.com

Multiple *.:
https://crt.sh/?id=13299376 *.*.victoria.ac.nz
https://crt.sh/?id=44997156 *.*.rnd.unicredit.it
https://crt.sh/?id=5982951 *.*.int.swisscom.ch

Internals TLD:
https://crt.sh/?id=33626750 a1.verizon.test
https://crt.sh/?id=33123653 DAC38997VPN2001A.trmk.corp
https://crt.sh/?id=42475510 naccez.us.areva.corp
https://crt.sh/?id=10621703 collaboration.intra.airbusds.corp
https://crt.sh/?id=48726306 zdeasaotn01.dsmain.ds.corp

Are CAs allowed to deliver such certificates?

(Methodology: https://blog.tdelmas.ovh/crt-sh/ with the links for
expired/revoked certificates)

[Charles Reiss]

On 07/19/2017 06:03 PM, Tom wrote:
> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and
> probably trusted by Mozilla (crt.sh issuer are marked trusted by
> Mozilla, but not all).
>

[snip]

Some additional problematic certs:

chains to Swisscom:
https://crt.sh/?id=175444569 wxadm.swissucc.local

chains to CATCert, notBefore in 2017:
https://crt.sh/?id=98706307 maritim4.mmaritim.local

chains to PROCERT, notBefore in 2017:
https://crt.sh/?id=175466182 fospuca.local

chains to Baltimore Cybertrust Root (DigiCert):
https://crt.sh/?id=12344381 lorweb.local

chains to Baltimore Cybertrust Root (DigiCert), notBefore in 2017:
https://crt.sh/?id=175469208 skbfep01.justica.local
https://crt.sh/?id=175469209 energy.ctd and pt

chains to QuoVadis, notBefore in 2017:
https://crt.sh/?id=175466199 devsrv.pe.siemens.info-com (swapped -/.)

chains to DocuSign, notBefore in 2017:
https://crt.sh/?id=99149574 "www.immonotaireargus.com " (trailing space)

[Jeremy Rowley]

Thank you, Charles and Tom, for bringing this to the forefront. We have
contacted the cross-signed partner and asked for an explanation. We've also
demanded revocation within 24 hours and a full scan to determine whether any
other certificates exist.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Charles Reiss via dev-security-policy
Sent: Wednesday, July 19, 2017 7:02 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:

> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and
> probably trusted by Mozilla (crt.sh issuer are marked trusted by
> Mozilla, but not all).
>

[snip]

Some additional problematic certs:

chains to Swisscom:
https://crt.sh/?id=175444569 wxadm.swissucc.local

chains to CATCert, notBefore in 2017:
https://crt.sh/?id=98706307 maritim4.mmaritim.local

chains to PROCERT, notBefore in 2017:
https://crt.sh/?id=175466182 fospuca.local

chains to Baltimore Cybertrust Root (DigiCert):
https://crt.sh/?id=12344381 lorweb.local

chains to Baltimore Cybertrust Root (DigiCert), notBefore in 2017:
https://crt.sh/?id=175469208 skbfep01.justica.local
https://crt.sh/?id=175469209 energy.ctd and pt

chains to QuoVadis, notBefore in 2017:
https://crt.sh/?id=175466199 devsrv.pe.siemens.info-com (swapped -/.)

chains to DocuSign, notBefore in 2017:
https://crt.sh/?id=99149574 "www.immonotaireargus.com " (trailing space)

[Charles Reiss]

On 07/19/2017 06:03 PM, Tom wrote:

> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and
> probably trusted by Mozilla (crt.sh issuer are marked trusted by
> Mozilla, but not all).

Annotating these certs:

> Starting with *:

I believe this cert is presently untrusted by Mozilla due to revocation
of all paths to the Federal PKI:
> https://crt.sh/?id=7211484 *eis.aetc.af.mil

chains to StartCom (and all of these from StartCom are minor compared to
StartCom's other problems):
> https://crt.sh/?id=10714112 *g10.net-lab.net

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=48682944 *nuvolaitaliana.it

chains to StartCom:

> https://crt.sh/?id=15736178 *assets.blog.cn.net.ru
> https://crt.sh/?id=17295812 *dev02.calendar42.com
> https://crt.sh/?id=15881220 *dev.1septem.ru
> https://crt.sh/?id=15655700 *assets.blog.cn.net.ru
> https://crt.sh/?id=17792808 *quickbuild.raptorengineering.io


>
> Starting with -:

chains to QuoVadis:
> https://crt.sh/?id=54285413
> -d1-datacentre-12g-console-2.its.deakin.edu.au

chains to StartCom:

> https://crt.sh/?id=78248795 -1ccenter.777chao.com


>
> Multiple *.:

chains to QuoVadis:
> https://crt.sh/?id=13299376 *.*.victoria.ac.nz

I believe this cert is presently trusted by Mozilla only via a
technically constrained subCA:
> https://crt.sh/?id=44997156 *.*.rnd.unicredit.it

chains to Swisscom:

> https://crt.sh/?id=5982951 *.*.int.swisscom.ch


>
> Internals TLD:

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=33626750 a1.verizon.test

I believe this cert is presently untrusted by Mozilla due to revocation
of the relevant subCA:
> https://crt.sh/?id=33123653 DAC38997VPN2001A.trmk.corp

chains to Certplus (DocuSign):
> https://crt.sh/?id=42475510 naccez.us.areva.corp

I believe these presently lack an unrevoked, unexpired trust path in
Mozilla:

[Inigo Barreira]

Thanks for this info. These Startcom certs were issued from the old system.
We´ll contact the users and act accordingly.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startco...@lists.mozilla.org]
On Behalf Of Charles Reiss via dev-security-policy
Sent: jueves, 20 de julio de 2017 3:30
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:

> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and
> probably trusted by Mozilla (crt.sh issuer are marked trusted by
> Mozilla, but not all).

Annotating these certs:

> Starting with *:

I believe this cert is presently untrusted by Mozilla due to revocation of
all paths to the Federal PKI:
> https://crt.sh/?id=7211484 *eis.aetc.af.mil

chains to StartCom (and all of these from StartCom are minor compared to
StartCom's other problems):
> https://crt.sh/?id=10714112 *g10.net-lab.net

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=48682944 *nuvolaitaliana.it

chains to StartCom:

> https://crt.sh/?id=15736178 *assets.blog.cn.net.ru
> https://crt.sh/?id=17295812 *dev02.calendar42.com
> https://crt.sh/?id=15881220 *dev.1septem.ru
> https://crt.sh/?id=15655700 *assets.blog.cn.net.ru
> https://crt.sh/?id=17792808 *quickbuild.raptorengineering.io


>
> Starting with -:

chains to QuoVadis:
> https://crt.sh/?id=54285413
> -d1-datacentre-12g-console-2.its.deakin.edu.au

chains to StartCom:

> https://crt.sh/?id=78248795 -1ccenter.777chao.com


>
> Multiple *.:

chains to QuoVadis:
> https://crt.sh/?id=13299376 *.*.victoria.ac.nz

I believe this cert is presently trusted by Mozilla only via a
technically constrained subCA:
> https://crt.sh/?id=44997156 *.*.rnd.unicredit.it

chains to Swisscom:

> https://crt.sh/?id=5982951 *.*.int.swisscom.ch


>
> Internals TLD:

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=33626750 a1.verizon.test

I believe this cert is presently untrusted by Mozilla due to revocation
of the relevant subCA:
> https://crt.sh/?id=33123653 DAC38997VPN2001A.trmk.corp

chains to Certplus (DocuSign):
> https://crt.sh/?id=42475510 naccez.us.areva.corp

I believe these presently lack an unrevoked, unexpired trust path in
Mozilla:

> https://crt.sh/?id=10621703 collaboration.intra.airbusds.corp
> https://crt.sh/?id=48726306 zdeasaotn01.dsmain.ds.corp

[Stephen Davidson]

Hello:

Thanks for pointing these out. Regarding the two problematic certificates
noted below chained to QuoVadis:

Changes were made to our systems last year dealing these very issues, and it
appears that these remaining certificates were not revoked. They will now
be revoked.
Leading hyphens and reallywildcards are now rejected by our systems.

Regards, Stephen
QuoVadis

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozi
lla.org] On Behalf Of Charles Reiss via dev-security-policy
Sent: Wednesday, July 19, 2017 10:30 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:

> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and
> probably trusted by Mozilla (crt.sh issuer are marked trusted by
> Mozilla, but not all).

Annotating these certs:

> Starting with *:

I believe this cert is presently untrusted by Mozilla due to revocation of
all paths to the Federal PKI:
> https://crt.sh/?id=7211484 *eis.aetc.af.mil

chains to StartCom (and all of these from StartCom are minor compared to
StartCom's other problems):
> https://crt.sh/?id=10714112 *g10.net-lab.net

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=48682944 *nuvolaitaliana.it

chains to StartCom:

> https://crt.sh/?id=15736178 *assets.blog.cn.net.ru
> https://crt.sh/?id=17295812 *dev02.calendar42.com
> https://crt.sh/?id=15881220 *dev.1septem.ru
> https://crt.sh/?id=15655700 *assets.blog.cn.net.ru
> https://crt.sh/?id=17792808 *quickbuild.raptorengineering.io


>
> Starting with -:

chains to QuoVadis:
> https://crt.sh/?id=54285413
> -d1-datacentre-12g-console-2.its.deakin.edu.au

chains to StartCom:

> https://crt.sh/?id=78248795 -1ccenter.777chao.com


>
> Multiple *.:

chains to QuoVadis:
> https://crt.sh/?id=13299376 *.*.victoria.ac.nz

I believe this cert is presently trusted by Mozilla only via a
technically constrained subCA:
> https://crt.sh/?id=44997156 *.*.rnd.unicredit.it

chains to Swisscom:

> https://crt.sh/?id=5982951 *.*.int.swisscom.ch


>
> Internals TLD:

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=33626750 a1.verizon.test

I believe this cert is presently untrusted by Mozilla due to revocation
of the relevant subCA:
> https://crt.sh/?id=33123653 DAC38997VPN2001A.trmk.corp

chains to Certplus (DocuSign):
> https://crt.sh/?id=42475510 naccez.us.areva.corp

I believe these presently lack an unrevoked, unexpired trust path in
Mozilla:

> https://crt.sh/?id=10621703 collaboration.intra.airbusds.corp
> https://crt.sh/?id=48726306 zdeasaotn01.dsmain.ds.corp

[Ben Wilson]

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=digice...@lists.mozilla.org] On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Tuesday, July 18, 2017 9:54 AM
To: Jakob Bohm <jb-mo...@wisemo.com>;
mozilla-dev-s...@lists.mozilla.org

Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

[Charles Reiss]

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

[Nick Lamb]

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.

[Ben Wilson]

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=digice...@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Sunday, July 23, 2017 2:35 PM
To: mozilla-dev-s...@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.

[Nick Lamb]

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.

[Ben Wilson]

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=digice...@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-s...@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.

[Ben Wilson]

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=digice...@lists.mozilla.org] On
Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb <tiala...@gmail.com>;
mozilla-dev-s...@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=digice...@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy

Sent: Wednesday, August 2, 2017 10:34 AM

To: mozilla-dev-s...@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.

[Alex Gaynor]

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

> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On

> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb <tiala...@gmail.com>;
> mozilla-dev-s...@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=digice...@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy

> Sent: Wednesday, August 2, 2017 10:34 AM

> To: mozilla-dev-s...@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.
>

[Ben Wilson]

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

From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Thursday, August 3, 2017 8:42 AM
To: Ben Wilson <ben.w...@digicert.com>
Cc: Nick Lamb <tiala...@gmail.com>;
mozilla-dev-s...@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-secur...@lists.mozilla.org

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben

<mailto:dev-security-policy-bounces%2Bben> =digice...@lists.mozilla.org
<mailto:digice...@lists.mozilla.org> ] On

Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM

To: Nick Lamb <tiala...@gmail.com <mailto:tiala...@gmail.com> >;
mozilla-dev-s...@lists.mozilla.org
<mailto:mozilla-dev-s...@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> =digice...@lists.mozilla.org
<mailto:digice...@lists.mozilla.org> ] On
Behalf Of Nick Lamb via dev-security-policy

Sent: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-s...@lists.mozilla.org

<mailto:mozilla-dev-s...@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-secur...@lists.mozilla.org

<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Alex Gaynor]

Ouch. Thanks for clarifying.

Alex

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

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

> *From:* Alex Gaynor [mailto:aga...@mozilla.com]
> *Sent:* Thursday, August 3, 2017 8:42 AM
> *To:* Ben Wilson <ben.w...@digicert.com>
> *Cc:* Nick Lamb <tiala...@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 <

> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
>

> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM

> To: Nick Lamb <tiala...@gmail.com>;
> mozilla-dev-s...@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=digice...@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy

> Sent: Wednesday, August 2, 2017 10:34 AM

> To: mozilla-dev-s...@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.
>

[Matt Palmer]

On Thu, Aug 03, 2017 at 02:38:33PM +0000, 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

[Gervase Markham]

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

[Gervase Markham]

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&opt=cablint,x509lint

appears to be in two certs, which are:

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

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

https://ccadb.my.salesforce.com/001o000000dsANG
https://ccadb.my.salesforce.com/001o000000dsAlD

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

[Ben Wilson]

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:ge...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:44 AM
To: Ben Wilson <ben.w...@digicert.com>;
mozilla-dev-s...@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.

[Ben Wilson]

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

-----Original Message-----
From: Gervase Markham [mailto:ge...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:55 AM
To: Ben Wilson <ben.w...@digicert.com>;

mozilla-dev-s...@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:

[Gervase Markham]

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