Internationalized Domain Names

The date has changed THREE times.

  1. Before July 1st
  2. Before August 1, 2016
  3. Before August 30th
  4. Before November 30th

I hope that will not end up like the whole idea of how … link above …

Well, you know that the ECDSA intermediate is another functionality also postponed temporarily, since the date changed again to March 31, 2017…

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.”

1 Like

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.


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.

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?

1 Like

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.

well I think domain checks are okay, similar to the high risk domains you already do, but not site checks.

Impersonating domains is not an IDN exclusive issue. Trying to police it via CA’s is pretty much pointless and will be largely ineffective.


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ⅼ (gоο, 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.

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.

AFAIK yes, they do. See ICANN Guidelines for the Implementation of Internationalized Domain Names:

…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оο, when I own

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! :slight_smile:

1 Like

My IDN domain which is a website for local language.

I wish SSL support for IDN domain like mine.

What about only supporting IDNs on subdomains first? And maybe also TLDs.

They can already do There is no point in avoiding homoglyphs in this case.

1 Like

Full IDN support should land before November 30, 2016. See this thread for a recent discussion:

Hope to see IDN in LE soon … some of our Customers are already asking when they can get their LE Cert! :wink:

There is definitely ongoing progress and work on this.


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).

② The Boulder CA software has added a feature to permit issuance for IDNs (as a technical matter).

③ 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).

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 é as a synonym for -d 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.