Certificates with common names not present in their SANs

[alex....@gmail.com]

Hi all,

7.1.4.2.2 of the CABF Baseline Requirements requires that common names always be an element from the SAN.

Here are 62 certs, from a variety of CAs which do not meet that requirement: https://misissued.com/batch/1/

These appear to be for a variety of reasons:

- just plain wrongness :-)
- leading/trailing spaces in either the CN or the SAN
- Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the SAN
- My personal favorite, the presence of zero-width-space unicode characters in the CN

There's probably some other reasons, there's a lot to sort through.

I've notified several of the CAs already, but not all. (I notably haven't yet notified Symantec, who appear to have the plurality of these because of the IDNA issue).

Alex

[Nick Lamb]

On Sunday, 6 August 2017 14:10:36 UTC+1, alex....@gmail.com wrote:
> - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the SAN

Note https://bugs.python.org/issue28414

At least one popular implementation of TLS in a non-browser client (the Python SSL implementation) requires that non-ASCII FQDNs are written out as U-labels in the Common Name in order to correctly match them

It can't work with A-labels because it (erroneously) transforms Punycoded names into U-labels before matching and as a result it can't match IDNs in SANs at all since these will be presented as A-labels

Christian considers the current situation "sane" but it will so far as I can see encourage CAs to issue these bogus certificates _and_ weaken the support for SANs, and we should encourage Python to get their act together and fix this.

[Kurt Roeckx]

On Sat, Aug 05, 2017 at 02:36:14PM -0700, alex.gaynor--- via dev-security-policy wrote:
> - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the SAN

I think that's actually correrct?


Kurt

[alex....@gmail.com]

On Sunday, August 6, 2017 at 3:08:32 PM UTC-4, Nick Lamb wrote:
> On Sunday, 6 August 2017 14:10:36 UTC+1, alex....@gmail.com wrote:
> > - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the SAN
>
> Note https://bugs.python.org/issue28414

I've followed up on this bug, but it seems like a red herring to me -- if the value is in the SAN (as it is required to be!) the value will simply be matched from there.

Further, a quick search of crt.sh's DB shows that quite a lot of certs are issued with IDNA-encoded CNs:

certwatch=> select count(*) from certificate_identity where name_type = 'commonName' and lower(name_value) LIKE 'xn--%';
count
--------
242943


Alex

[Nick Lamb]

"simply" how?

If it's your belief that the Python code actually does work for IDN SANs I think you're going to need to do better than just asserting that it's "simply" so in the face of subject experts saying it's broken.

[Alex Gaynor]

Sorry, you're right -- I'd misunderstood the issue with Python. (FWIW, I'm
one of the maintainers of the Python ssl module, and I anticipate us having
a fix for IDNs by the next release).

Alex

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

[Jonathan Rudenberg]

> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Hi all,
>
> 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always be an element from the SAN.
>
> Here are 62 certs, from a variety of CAs which do not meet that requirement: https://misissued.com/batch/1/

I sent a problem report to Symantec about these certificates via their web form on 2017-08-07 and received this response from them a few minutes ago:

> Thank you for reporting the issue for Symantec, Thawte and RapidSSL certificates; however, we feel that the certificates we have issued are compliant. We consider the puny-coded SAN to match the native-coded CN and to best cover both human consumers and machine consumers that need to be able to read the name. Therefore, the certificates should not be revoked.

[Matthew Hardeman]

Didn't someone recently float the argument that the native u-label was required by local regulation / custom (in China) to be included and so they stuffed it into the CN?

[Ryan Sleevi]

CFCA stated this, in
https://cabforum.org/pipermail/public/2017-July/011733.html

Since then, no further evidence of this claim has been provided.

SHECA ( https://cabforum.org/pipermail/public/2017-July/011737.html ) and
GDCA ( https://cabforum.org/pipermail/public/2017-July/011736.html ) are
more restrained in claiming local law, although made similarly problematic
claims :)