4 ms·

I hear you, but I also am encouraged that, for example, in 2017-ish, Chrome was able to turn on enforcement of deprecating CommonName in favor of SAN for single

I hear you, but I also am encouraged that, for example, in 2017-ish, Chrome was able to turn on enforcement of deprecating CommonName in favor of SAN for single-name serverauth certs. They flipped a switch and a lot of sites broke, then fixed themselves. There was no mass exodus. You could argue that this was because of Chrome's dominance and I'd agree to an extent, but I like the fact that the solution was not just "have browsers pretend this is ok." And that was for a change that really did not matter from a security standpoint, it was just catching up to an RFC change.

tialaramex 5y ago
> They flipped a switch and a lot of sites broke, then fixed themselves. No. This isn't a thing that happened. Certificates which lack SANs matching a DNS name claimed as Common Name had been non-compliant since PKIX last century. So in the subsequent decade plus the big problem was identifying CAs which were flouting these rules and then getting them to understand what they'd done wrong and stop doing it. That's something which CA/B (the CA/B BRs forbade this from the outset) and m.d.s.policy were getting good traction on by 2013 or so, but Certificate Transparency (initially seeded by Google's "Googlebot" robots before the Chrome mandate) represents a sea change beyond that because now finding non-compliant certificates was a trivial SQL query. And that took such non-compliant certificates from "rare but you will find them if you look hard" to "extinct" very quickly indeed. Even when there were still a few technically non-compliant certificates out there, they wouldn't break Chrome, the usual non-compliance went like this: Say you own a site with an IDN https://президент.рф/ https://xn--d1abbgf6aiiy.xn--p1ai/ and so the DNS entry for that is xn--d1abbgf6aiiy.xn--p1ai - your SAN DnsName will say xn--d1abbgf6aiiy.xn--p1ai because that's how SANs work, but you persuade the issuing CA to write президент.рф in the Common Name instead of xn--d1abbgf6aiiy.xn--p1ai because it looks nicer. [ NB Hacker News won't show the IDN to most (any?) of you but imagine you're a Russian and your web browser shows this URL in Cyrillic not as Punycode ] This is non-compliant with PKIX, because this Common Name doesn't match any of the SANs. It can't because it's Unicode and none of the SANs can express Unicode [IpAddress SANs are numbers, and DnsName SANs are restricted to a simple alphabet suitable for writing names of hosts in DNS]. But it doesn't cause any problems for Chrome because the SANs match the real DNS names of the server, the Common Name is just decorative garbage that doesn't match anything.
- hamburglar 5y ago
  > No. This isn't a thing that happened. Oh, I beg to differ. I saw many examples of this for certs my company had issued from a digicert private CA. Maybe this didn’t happen with certs from public web pki but I can assure you it did for private certs, for which browser support is still an important issue. But I’ll admit this is moving the goalposts on you and your point is made. I still would prefer the more hard-ass approach but the reality is that consumer products are going to prefer ease of use over correctness, so what are you going to do.

tialaramex 5y ago

> They flipped a switch and a lot of sites broke, then fixed themselves. No. This isn't a thing that happened. Certificates which lack SANs matching a DNS name claimed as Common Name had been non-compliant since PKIX last century. So in the subsequent decade plus the big problem was identifying CAs which were flouting these rules and then getting them to understand what they'd done wrong and stop doing it. That's something which CA/B (the CA/B BRs forbade this from the outset) and m.d.s.policy were getting good traction on by 2013 or so, but Certificate Transparency (initially seeded by Google's "Googlebot" robots before the Chrome mandate) represents a sea change beyond that because now finding non-compliant certificates was a trivial SQL query. And that took such non-compliant certificates from "rare but you will find them if you look hard" to "extinct" very quickly indeed. Even when there were still a few technically non-compliant certificates out there, they wouldn't break Chrome, the usual non-compliance went like this: Say you own a site with an IDN https://президент.рф/ https://xn--d1abbgf6aiiy.xn--p1ai/ and so the DNS entry for that is xn--d1abbgf6aiiy.xn--p1ai - your SAN DnsName will say xn--d1abbgf6aiiy.xn--p1ai because that's how SANs work, but you persuade the issuing CA to write президент.рф in the Common Name instead of xn--d1abbgf6aiiy.xn--p1ai because it looks nicer. [ NB Hacker News won't show the IDN to most (any?) of you but imagine you're a Russian and your web browser shows this URL in Cyrillic not as Punycode ] This is non-compliant with PKIX, because this Common Name doesn't match any of the SANs. It can't because it's Unicode and none of the SANs can express Unicode [IpAddress SANs are numbers, and DnsName SANs are restricted to a simple alphabet suitable for writing names of hosts in DNS]. But it doesn't cause any problems for Chrome because the SANs match the real DNS names of the server, the Common Name is just decorative garbage that doesn't match anything.

hamburglar 5y ago
> No. This isn't a thing that happened. Oh, I beg to differ. I saw many examples of this for certs my company had issued from a digicert private CA. Maybe this didn’t happen with certs from public web pki but I can assure you it did for private certs, for which browser support is still an important issue. But I’ll admit this is moving the goalposts on you and your point is made. I still would prefer the more hard-ass approach but the reality is that consumer products are going to prefer ease of use over correctness, so what are you going to do.