At 11:30am PST on August 10, 2017, Let’s Encrypt was made aware of a compliance issue regarding unicode normalization of domain names. During the same day we were made aware of the issue, all unexpired non-compliant certificates were found and revoked, a fix was applied to our CA systems, and we communicated with our community. We consider the matter to be fully resolved at this point, please let us know if we missed anything.
We were notified by a community member that Let's Encrypt had issued a number of certificates containing punycode domain names which had not undergone compliant unicode normalization. We confirmed that this was the case and began investigating our code and the relevant RFCs. We noticed that the code we added to check the validity of punycode encodings in CSRs when we implemented support for IDNs didn't enforce any form of Unicode Normalization. We started developing a fix. After seeking outside insight into the issue and reading the relevant reference documents we came to the conclusion that Normalization Form KC was required. The BRs reference RFC 5280, which in turn references the encoding specified in RFC 3490 for IDNs, which requires Normalization Form KC. We finished our fix and deployed it to our CA at 5:20PM PST. While developing the fix we searched our issuance databases for all unexpired certificates containing punycode DNS names and checked them for non-NFKC compliant names. We found 16, which are listed below. We revoked these certificates and notified the subscribers who requested them. I would like to thank the community members that discovered this issue, as well as the Let's Encrypt team that worked hard to resolve it quickly. -- Josh Aas Executive Director Internet Security Research Group Let's Encrypt: A Free, Automated, and Open CA Serial numbers of affected and revoked certificates: 03d03877cbcec666b81340ed6a39c47556d1 03758d04a7816ba893847658e636a58e1f71 03ef82538ca2e54e97ae2b180ecb32f8cee4 044568f36455d8847713adb24c69e60bf123 033e73ebfd2f270bc6109925f1ed40edca8b 038295d240613cdb9367506c0d3cf8002401 03556fbc38b13ea3a9b7f4dd59dacc350293 030cfe12721e17ca02c095b4a0c5e60ca8da 03ca6617e634f2f5ad9224ca32ca4c835909 03bd090cfe0fbd07b4fc60df07bbc5770b35 0314017b4eab87bb0f211e9e2bb329ca4297 03f48a8c02c473ce971236b6407ad7d00d89 03bfa7b8f318a30a88894523ebd2717ea9b4 032d7c46b0a815faa41a1876fed4d66a9993 039f94badc798eea44f8c81ceb0515024871 038f81a32455e41b702ffb1732186be3a007 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
