# Internationalized Domain Names **URL:** \ **Category:** Issuance Policy\ **Created:** [August 13, 2015, 8:19pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94 "2015-08-13T20:19:46Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Ascendor](https://avatars.discourse-cdn.com/v4/letter/a/a9adbd/32.png) [@Ascendor](https://community.letsencrypt.org/u/Ascendor)\ **Post date:** [July 12, 2016, 8:20pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/82 "2016-07-12T20:20:59Z")
The date has changed THREE times. 1. Before July 1st 2. Before August 1, 2016 3. Before August 30th 4. Before November 30th ---
**Author:** ![build000](https://avatars.discourse-cdn.com/v4/letter/b/b4bc9f/32.png) [@build000](https://community.letsencrypt.org/u/build000)\ **Post date:** [July 12, 2016, 8:35pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/83 "2016-07-12T20:35:22Z")
> **[EFForg/OpenWireless](https://github.com/EFForg/OpenWireless)** > > The official home of the EFF OpenWireless Project I hope that will not end up like the whole idea of how … link above … 🕶 ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [July 13, 2016, 7:28am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/85 "2016-07-13T07:28:09Z")
Well they have to eventually support them or back away from their stated goal: “Our goal with Let’s Encrypt is to get the Web to 100% HTTPS.” > **[Progress Towards 100% HTTPS, June 2016 - Let's Encrypt - Free SSL/TLS...](https://letsencrypt.org/2016/06/22/https-progress-june-2016.html)** > > Our goal with Let’s Encrypt is to get the Web to 100% HTTPS. We’d like to give a quick progress update. ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [July 19, 2016, 9:06pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/86 "2016-07-19T21:06:02Z")
Love the double standard. On one hand it’s not the CA’s roll to police malicious sites/domains, then on the other hand CA’s should police IDN’s. LOL ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [July 19, 2016, 9:40pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/87 "2016-07-19T21:40:35Z")
well I think, the site should not be policed but the domains should be policed because there are probably registrars that are pretty lax in some standards. ---
**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\ **Post date:** [July 19, 2016, 9:46pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/88 "2016-07-19T21:46:07Z")
These are two completely different things. CAs as malware filters are bad because: - They’re typically bad at detecting malware in the first place, as it’s not typically their core competency - even if they’d be good at detecting malware, revocation is a terrible and slow way to block it and - it’s a slippery slope. Detecting script spoofing, on the other hand, might not be the easiest thing in the world to implement, but blocking domains that mix scripts from different languages probably gets rid of most script spoofing vectors and is orders of magnitude easier than malware detection in general. Certificates that are not issued in the first place don’t suffer from the slow revocation problem, and I don’t see how you could make the slippery slope/censorship argument here either, unless the filtering algorithm is too broad. Finally, let’s say this is a valid comparison: Despite their stance on CAs as malware filters, Let’s Encrypt has still decided to do basic malware filtering via Google’s Safe Browsing API because it’s the current status quo in the industry. So where exactly is the double standard if the same policy is applied to IDNs? ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [July 19, 2016, 11:36pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/89 "2016-07-19T23:36:48Z")
> [@NOYB](#): > > On one hand it's not the CA's roll to police malicious sites/domains, then on the other hand CA's should police IDN's. Yep, I realize these two policies conflict a bit. We're still doing the research to confirm what our obligations are with regards to IDNs and what the possible pitfalls are. ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [July 20, 2016, 10:31am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/90 "2016-07-20T10:31:17Z")
well I think domain checks are okay, similar to the high risk domains you already do, but not site checks. ---
**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\ **Post date:** [July 26, 2016, 6:12am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/91 "2016-07-26T06:12:08Z")
Impersonating domains is not an IDN exclusive issue. Trying to police it via CA’s is pretty much pointless and will be largely ineffective. 'CEO FRAUD’ ---
**Author:** ![Oskar](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/oskar/32/1575_2.png) [@Oskar](https://community.letsencrypt.org/u/Oskar)\ **Post date:** [July 26, 2016, 6:25pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/92 "2016-07-26T18:25:15Z")
I still don’t see what exactly is the problem regarding IDNs. All domain registries that are implementing IDNs are already blocking domains that mix scripts from different languages so if somebody wanted to register say [gоοgⅼe.com](http://xn--gge-9yc84dw71l.com) ([gоοgle.com](http://xn--ggle-0nd57e.com)), such attempt would be blocked at the registry level. And since there is no way how to obtain LE certificate for a non-existent domain name, I think there don’t have to be any special treatment to punycode domain names. ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [July 27, 2016, 12:27pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/93 "2016-07-27T12:27:54Z")
well do really ALL IDN registries have such policies? also obviously there would be a problem for new IDN accepting registries that dont do that. ---
**Author:** ![Oskar](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/oskar/32/1575_2.png) [@Oskar](https://community.letsencrypt.org/u/Oskar)\ **Post date:** [July 27, 2016, 2:56pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/94 "2016-07-27T14:56:32Z")
AFAIK yes, they do. See [ICANN Guidelines for the Implementation of Internationalized Domain Names](https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en): > …visually confusable characters from different scripts will not be allowed to co-exist in a single set of permissible code points unless a corresponding policy and character table is clearly defined. Allowing mixing IDN scripts would be dangerous for any registry, regardless of whether LE offers certificate for IDNs or not. On the other hand, everybody should be free to register (and get a LE certificate) to any sub-domain name under domain of their own control. I don't see any reason why should LE or any other CA forbid me from getting a certificate for [gоοgle.example.com](http://xn--ggle-0nd57e.example.com), when I own [example.com](http://example.com). ---
**Author:** ![berb](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/berb/32/8456_2.png) [@berb](https://community.letsencrypt.org/u/berb)\ **Post date:** [August 23, 2016, 12:58pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/95 "2016-08-23T12:58:54Z")
Just wanted to add my voice to the choir of voices asking for IDN support. The ETA has been changed a few times now so I wonder if this ETA (november 30) is going to hold? We are releasing a service relying on LE next week and now we have to tell our users they can’t register IDN domains and use with our service – I work at the Swedish registry responsible for .se and .nu so it feels kinda crappy not being able to offer the full domain name “experience”. Having that said, it’s so good LE exists and you guys are doing a great job! 🙂 ---
**Author:** ![Rajat](https://avatars.discourse-cdn.com/v4/letter/r/ebca7d/32.png) [@Rajat](https://community.letsencrypt.org/u/Rajat)\ **Post date:** [September 18, 2016, 4:41am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/96 "2016-09-18T04:41:08Z")
xn–8gcz5b4g.​com My IDN domain which is a website for local language. [https://ଓଡିଆ.com](https://xn--8gcz5b4g.com) I wish SSL support for IDN domain like mine. ---
**Author:** ![gre\_gor](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/gre_gor/32/8963_2.png) [@gre\_gor](https://community.letsencrypt.org/u/gre_gor)\ **Post date:** [October 7, 2016, 10:04pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/97 "2016-10-07T22:04:16Z")
What about only supporting IDNs on subdomains first? And maybe also TLDs. They can already do [paypal.totalylegit.com](http://paypal.totalylegit.com). There is no point in avoiding homoglyphs in this case. ---
**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\ **Post date:** [October 8, 2016, 7:43am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/98 "2016-10-08T07:43:59Z")
Full IDN support should land before November 30, 2016. See this thread for a recent discussion: > [@Error: IDN domains are not supported: zweikapitäne.de](https://community.letsencrypt.org/t/error-idn-domains-are-not-supported-zweikapitane-de/20618): > > H… ---
**Author:** ![futureweb](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/futureweb/32/69239_2.png) [@futureweb](https://community.letsencrypt.org/u/futureweb)\ **Post date:** [October 12, 2016, 11:34am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/99 "2016-10-12T11:34:16Z")
Hope to see IDN in LE soon … some of our Customers are already asking when they can get their LE Cert! 😉 ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [October 12, 2016, 5:31pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/100 "2016-10-12T17:31:03Z")
There is definitely ongoing progress and work on this. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [October 18, 2016, 10:42pm UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/101 "2016-10-18T22:42:37Z")
Hi folks, I'm happy to point to three pieces of progress on Let's Encrypt IDN support: ① The new Let's Encrypt CPS 1.5 released today permits issuances for IDNs (as a policy matter). > [@Updated CPS v1.5](https://community.letsencrypt.org/t/updated-cps-v1-5/21334): > > W… ② The Boulder CA software has added a feature to permit issuance for IDNs (as a technical matter). > > > Add feature flagged support for issuing for IDNs, fixes #597. > > This patch expect…s that clients have performed valid IDN2008 encoding on any label that includes unicode characters. Invalid encodings (including non-compatible IDN2003 encoding) will be rejected. No script-mixing or script exclusion checks are performed as we assume that if a name is resolvable that it conforms to the registrar's policies on these matters and if it uses non-standard scripts in sub-domains etc that browsers should be the ones choosing how to display those names. > > Required a full update of the \`golang.org/x/net\` tree to pull in \`golang.org/x/net/idna\`, all test suites pass. ③ The current development version of the Certbot client no longer prevents users from requesting punycode-formatted IDNs as part of their certificate requests (as a user interface matter). > > > First cut at not rejecting punycode names. > > Probably fixes #3619. It would be great for any other clients that currently forbid requesting certs containing punycode IDN names (the ones beginning with "`xn--`") to remove that limitation at this time. There's also ongoing work on Certbot to allow users to specify requested names in Unicode form instead of IDNA form so that users will eventually be able to say `-d éxample.org` as a synonym for `-d xn--xample-9ua.org`. Right now requests can be entered only using IDNA form (with `xn--`) for all labels containing a non-ASCII character. If you don't know the IDNA form of your domain, you can find it using various software such as the `idn2` program. Note that issuance of certs for IDNs _has not begun yet_ and we're still waiting for an announcement of when this may happen. But I wanted to let people know that several pieces have now been put in place to move the process forward. ---
**Author:** ![Ascendor](https://avatars.discourse-cdn.com/v4/letter/a/a9adbd/32.png) [@Ascendor](https://community.letsencrypt.org/u/Ascendor)\ **Post date:** [October 19, 2016, 11:26am UTC](https://community.letsencrypt.org/t/internationalized-domain-names/94/102 "2016-10-19T11:26:05Z")
Awesome! Thanks for keeping us posted! [Previous page](https://community.letsencrypt.org/t/internationalized-domain-names/94.md?page=4) [Next page](https://community.letsencrypt.org/t/internationalized-domain-names/94.md?page=6)