3 ms·
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 sto
by igetspam 6y ago
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.)
- tialaramex 6y agoFrom 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.