At 11:30am PST on August 10, 2017, Let=E2=80=99s 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 c=
ertificates were found and revoked, a fix was applied to our CA systems, an=
d we communicated with our community. We consider the matter to be fully re=
solved 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 numb=
er of certificates containing punycode domain names which had not undergone=
compliant unicode normalization. We confirmed that this was the case and b=
egan investigating our code and the relevant RFCs.
We noticed that the code we added to check the validity of punycode encodin=
gs in CSRs when we implemented support for IDNs didn't enforce any form of =
Unicode Normalization. We started developing a fix. After seeking outside i=
nsight into the issue and reading the relevant reference documents we came =
to the conclusion that Normalization Form KC was required. The BRs referenc=
e RFC 5280, which in turn references the encoding specified in RFC 3490 for=
IDNs, which requires Normalization Form KC. We finished our fix and deploy=
ed it to our CA at 5:20PM PST.
While developing the fix we searched our issuance databases for all unexpir=
ed certificates containing punycode DNS names and checked them for non-NFKC=
compliant names. We found 16, which are listed below. We revoked these cer=
tificates 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.
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA
Serial numbers of affected and revoked certificates: