On Thu, February 13, 2014 3:36 pm, Paul Hoffman wrote: > And, with many thanks to Rob, https://www.éxample.org/ (also known as > https://www.xn--xample-9ua.org/) should now let you test with a cert whose > CN has éxample.org, not the Punycode. > > --Paul Hoffman > _______________________________________________ > wpkops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/wpkops >
Unfortunately, it still includes the Punycode in the SAN, as would be expected of a BR-conforming CN. The result of this is every (browser) implementation I know of will ignore the CN, fall back to the SAN, and thus perform punycode matching the same as in the .com case. I only highlight this because in the absence of the SAN, CryptoAPI (aka IE) will take the Punycode'd input domain and expand it to its U-Label form, then compare that with the Common Name. I'm not aware of any other implementations that perform this step (either punycoding the CN or taking the A-Labels and converting to U-Labels) For those with your Crypt32 PDBs (from the Microsoft symbol store), debuggers handy, and perverse interests, look for calls to the function CompareSSLDNStoCommonName, which will promote Punycode'd names into the Unicode form ( I_ConvertIdnHostNameToAsciiOrUnicode ), before doing a string comparison ( CompareStringW ). Chrome on Windows used to do the same, by virtue of relying on CryptoAPI, although the name checks in Windows have since been disabled in favour of an internal implementation that is normalized across all Chrome platforms ( https://code.google.com/p/chromium/codesearch#chromium/src/net/cert/x509_certificate.cc&rcl=1392294813&l=503 ) It would take a non-BR cert to cover this case. _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
