CFCA certificate with invalid domain

[michel.le...@gmail.com]

Hello,

I noticed this certificate https://crt.sh/?id=1231965201&opt=cablint,x509lint,zlint that has an invalid domain `mail.xinhua08.con` in SANs. This looks like a typo and `mail.xinhua08.com` is present in other certificates. Such an issue makes me wonder about the quality of their validation.

[Buschart, Rufus]

I just sent them a certificate problem report.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von michel.lebihan2000--- via dev-security-policy
> Gesendet: Mittwoch, 27. Februar 2019 08:54
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: CFCA certificate with invalid domain

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

[bsteph...@gmail.com]

[Jonathan Rudenberg]

On Fri, Mar 15, 2019, at 10:58, bstephens822--- via dev-security-policy wrote:
> On Wednesday, February 27, 2019 at 10:28:00 AM UTC-5,
> michel.le...@gmail.com wrote:

> > Hello,
> >
> > I noticed this certificate https://crt.sh/?id=1231965201&opt=cablint,x509lint,zlint that has an invalid domain `mail.xinhua08.con` in SANs. This looks like a typo and `mail.xinhua08.com` is present in other certificates. Such an issue makes me wonder about the quality of their validation.

I've noted this on a similar bug and asked for details: https://bugzilla.mozilla.org/show_bug.cgi?id=1524733

[Nick Lamb]

On Fri, 15 Mar 2019 19:41:58 -0400
Jonathan Rudenberg via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> I've noted this on a similar bug and asked for details:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1524733

I can't say that this pattern gives me any confidence that the CA
(CFCA) does CAA checks which are required by the BRs.

I mean, how do you do a CAA check for a name that can't even exist? If
you had the technology to run this check, and one possible outcome is
"name can't even exist" why would you choose to respond to that by
issuing anyway, rather than immediately halting issuance because
something clearly went badly wrong? So I end up thinking probably CFCA
does not actually check names with CAA before issuing, at least it does
not check the names actually issued.

Nick.

[Jakob Bohm]

Technically, the name can exist, if (for some bad reason) ICANN were to
create the con. TLD (which would be a major invitation to phishing).

As "not found" is a permissive CAA check result, CAA checking may be
perfectly fine in this case.

Domain control validation however obviously failed, as no one controls
the non-existent domain, and thus no one could have proven control of
that domain.


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

[jonath...@gmail.com]

在 2019年2月27日星期三 UTC+8下午11:28:00，michel.le...@gmail.com写道：

> Hello,
>
> I noticed this certificate https://crt.sh/?id=1231965201&opt=cablint,x509lint,zlint that has an invalid domain `mail.xinhua08.con` in SANs. This looks like a typo and `mail.xinhua08.com` is present in other certificates. Such an issue makes me wonder about the quality of their validation.

For the missed input subjectAltname in this case, as Jokob Bohm said, the CAA checking action couldn't prevent this from happening perfectly. We CFCA checked the production log, and this error is caused by operator's manual input. CFCA had finished system updates which would check TLD in common name and subjectAltnames automatically in February 27 update, the wrong TLD input will be reported as "invalid TLD " from the system after this update. More training had been done to operators.

[Matt Palmer]

On Mon, Mar 25, 2019 at 12:05:44AM -0700, jonathansshn--- via dev-security-policy wrote:
> 在 2019年2月27日星期三 UTC+8下午11:28:00，michel.le...@gmail.com写道：

> For the missed input subjectAltname in this case, as Jokob Bohm said, the
> CAA checking action couldn't prevent this from happening perfectly. We
> CFCA checked the production log, and this error is caused by operator's
> manual input. CFCA had finished system updates which would check TLD in
> common name and subjectAltnames automatically in February 27 update, the
> wrong TLD input will be reported as "invalid TLD " from the system after
> this update. More training had been done to operators.

Which method of domain control validation was used for this name in this
certificate?

- Matt