Hacker News Reader

Comment by imrehg | Hacker News Reader

They didn't, that entry is in the top level commonName (CN in the openssl output), or looking stright in openssl.cnf:

    ...snip...
    commonName = *

    ...

    [alt_names]
    DNS.1 = *.*
    DNS.2 = *.*.*
    ...

View on HN

SubjectAltNames should always include the common name, modern browsers won’t even look at the common name value any more (because it’s validation algorithm is not well defined, whereas it is for subjectAltNames).

Should be not must. The RFC doesn't required it. SSL implementations are complicated. Browsers might accept this up until hmthe Nth SAN, at which point they stop reading because they have arbitrary SAN limits (not in the spec). Some issuers care about CN/Alt match and some don't

More fun than generating this cert would be doing an analysis of who will accept it, who will reject it and who will accept up to a point. (Obviously I dontbexpect anyone to issue it, if you handed in a CSR for it.)

From a purely pragmatic point of view, in the Web PKI CN is ignored by Chrome for some time now and I think Firefox did that too. There were, and might still be, exceptions for certificates you trust which aren't from the Web PKI. You break it, you bought it.

The Baseline Requirements require that Public CAs ensure CN if present (which for compatibility it usually will be) is set to the same name as one of the SANs. Historically breaches were not uncommon, but as noted above now these certificates won't work as intended in Chrome so that's another practical reason above getting a slap on the wrist from m.d.s.policy.

Modern TLS libraries also shouldn't accept a wildcard TLD nor wildcards that are anywhere but the left most lower-level domain (eg *.example.com).

My point being the Common Name missing from the Subject Alt Names is the least of the problems with this certificate.

Reply on news.ycombinator.com