boulder: PA rejects domains ending in IDN TLD

Dependency of library which has only 8 stars is blocking you? Or, if to look at the list itself - 182 stars, random updates, pending issues.

In present days number of new TLDs is increasing rapidly and issues will only accumulate.

Finally - what is the sense to check domain suffix - you are checking /.well-known/acme-challenge anyway? If domain is incorrect - it will fail.

@kachkaev Absolutely - I will update this thread when it reaches prod. We appreciate your patience! I promise we’re almost there 😃

You have really bug in IDN domain zones. You service require domain name in punnycode, but check domain zone by the unicode list from “eightstartslibrary”.

Example: publicsuffix-go - resolve “рф”, but you reject “пример.рф” you resolve пример.рф , but publicsuffix-go reject xn–p1ai

Log for reference:

[Sat Oct 22 02:49:03 EDT 2016] Getting new-authz for domain='wangqiliang.xn--fiqs8s'
[Sat Oct 22 02:49:03 EDT 2016] url='https://acme-v01.api.letsencrypt.org/acme/new-authz'
[Sat Oct 22 02:49:03 EDT 2016] payload='{"resource": "new-authz", "identifier": {"type": "dns", "value": "wangqiliang.xn--fiqs8s"}}'
[Sat Oct 22 02:49:03 EDT 2016] RSA key
[Sat Oct 22 02:49:04 EDT 2016] GET
[Sat Oct 22 02:49:04 EDT 2016] url='https://acme-v01.api.letsencrypt.org/directory'
[Sat Oct 22 02:49:04 EDT 2016] timeout
[Sat Oct 22 02:49:04 EDT 2016] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Sat Oct 22 02:49:05 EDT 2016] ret='0'
[Sat Oct 22 02:49:05 EDT 2016] POST
[Sat Oct 22 02:49:05 EDT 2016] url='https://acme-v01.api.letsencrypt.org/acme/new-authz'
[Sat Oct 22 02:49:05 EDT 2016] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Sat Oct 22 02:49:05 EDT 2016] _ret='0'
[Sat Oct 22 02:49:05 EDT 2016] code='400'
[Sat Oct 22 02:49:05 EDT 2016] new-authz error: {"type":"urn:acme:error:malformed","detail":"Name does not end in a public suffix","status": 400}

[Sat Oct 22 02:54:09 EDT 2016] Getting new-authz for domain='wangqiliang.中国'
[Sat Oct 22 02:54:09 EDT 2016] url='https://acme-v01.api.letsencrypt.org/acme/new-authz'
[Sat Oct 22 02:54:09 EDT 2016] payload='{"resource": "new-authz", "identifier": {"type": "dns", "value": "wangqiliang.中国"}}'
[Sat Oct 22 02:54:09 EDT 2016] RSA key
[Sat Oct 22 02:54:10 EDT 2016] GET
[Sat Oct 22 02:54:10 EDT 2016] url='https://acme-v01.api.letsencrypt.org/directory'
[Sat Oct 22 02:54:10 EDT 2016] timeout
[Sat Oct 22 02:54:10 EDT 2016] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Sat Oct 22 02:54:10 EDT 2016] ret='0'
[Sat Oct 22 02:54:10 EDT 2016] POST
[Sat Oct 22 02:54:10 EDT 2016] url='https://acme-v01.api.letsencrypt.org/acme/new-authz'
[Sat Oct 22 02:54:10 EDT 2016] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Sat Oct 22 02:54:11 EDT 2016] _ret='0'
[Sat Oct 22 02:54:11 EDT 2016] code='400'
[Sat Oct 22 02:54:11 EDT 2016] new-authz error: {"type":"urn:acme:error:malformed","detail":"Invalid character in DNS name","status": 400}

@TimKGS Yes - we will comment on the ticket when it’s done. You can also watch status.letsencrypt.org

Same here for a domain in .рф zone defined by me as .xn--p1ai:

ACME server returned an error: urn:acme:error:malformed :: The request message was malformed :: Name does not end in a public suffix

While I know there’s nothing more technically difficult about supporting one writing system as opposed to another within IDNs, it’s still heartwarming to see that people just commenting on this single issue succeeded in getting certs issued for names in five different scripts on the first day!

@kachkaev your issue sounds like it’s related to an out-of-date certbot version. It’s unrelated to this issue, but if you file an issue on that other repo and tag me I can help out.

Worked for .xn–j6w193g (.香港) using a custom client.

Can verify that it finally works. Successfully got my certs for .コム and .닷컴 without problems 👍

As a user of popular docker-letsencrypt-nginx-proxy-companion I’m still unable to get a cert for .xn--p1ai (i.e. .рф). But that’s likely to be this issue: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion/issues/130

The error in my case says the following:

Creating/renewal xn--abcdef.xn--p1ai certificates... (xn--abcdef.xn--p1ai)
2016-12-08 23:09:07,317:INFO:simp_le:1211: Generating new account key
2016-12-08 23:09:08,186:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1401, in main
    return main_with_exceptions(cli_args)
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1386, in main_with_exceptions
    persist_new_data(args, existing_data)
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1282, in persist_new_data
    client = registered_client(args, existing_data.account_key)
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1224, in registered_client
    client = acme_client.Client(directory=args.server, key=key, net=net)
  File "build/bdist.linux-x86_64/egg/acme/client.py", line 63, in __init__
    self.net.get(directory).json())
  File "build/bdist.linux-x86_64/egg/acme/messages.py", line 169, in from_json
    raise jose.DeserializationError(str(error))
DeserializationError: Deserialization error: Wrong directory fields

Unhandled error has happened, traceback is above

Debugging tips: -v improves output verbosity. Help is available under --help.
Sleep for 3600s

If anyone knowledgable can help with a PR in https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion, that’d be fantastic!

Really exited the Letsencrypt is finally available for IDNs, according to other comments! That’s a great day to celebrate! 🎉 🎉 🎉

Domain .рф success (using ISP Manager, Let’s Encrypt plugin) Thanks

.みんな success (with some more punycode in the domain name, using webroot lego)

@kachkaev @slavonnet @TimKGS @rqou, others - the update in production is complete. Can you please verify you’re now able to issue for IDN TLDs without error?

@kachkaev Oops! Yes I meant Dec 1st. I edited my comment above. Apologies for the confusion.

@kachkaev - you’re correct, nothing will have to change on your end once the update to Boulder is live in production.

@slavonnet No sooner than Dec 1st. There’s no deploy this week due to the American Thanksgiving holidays. We do deploys to staging on Tuesdays and deploys to production on Thursdays.