Name is an ICANN TLD error *.bn ccTLD

Help
1

I encountered this error a couple of weeks ago. After searching online. I figured out a way to fix it. First, send a pull request to /publicsuffix/list. The list will be used to generate a file for /weppos/publicsuffx-go which is then auto-pulled by letsencrypt/boulder. All repo has now been updated with the new rule (about a day ago).

But when I run certbot, I’m still facing the same error. (1) Is the production letsencrypt server running the same version as the Github repo or will it take some time before it does? (2) Is there something I’m missing?

My domain is:
app.bn
I ran this command:
certbot
It produced this output:
An unexpected error occurred:
The request message was malformed :: Error creating new order :: Name is an ICANN TLD
My web server is (include version):
Nginx1.14.0
The operating system my web server runs on is (include version):
Ubuntu16.04
My hosting provider, if applicable, is:
DigitalOcean
I can login to a root shell on my machine (yes or no, or I don’t know):
yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

2

Hi @thefitri,

The inclusion in boulder is ad-hoc so let's call to @cpu and he could take a look to add the updated psl to boulder (it could take a few weeks). Anyway, take a look to this post Public Suffix List update schedule? - #2 by cpu

Cheers,
sahsanu

2 Likes
3

Hi @sahsanu. Thanks, I'm following all three Github repo (psl, psl-go and boulder) closely. However, the link to the post you gave me answered my question. I'll post it here so people can easily find it in the future:

1 Like
4

As luck would have it we've already updated the Public Suffix List dependency that Boulder/Let's Encrypt uses to allow .bn domains: Update publicsuffix-go to cbbcd04 by weppos · Pull Request #3814 · letsencrypt/boulder · GitHub

You will see the policy error with Certbot until this change is deployed to our staging and production environments next week.

I would estimate that this will get deployed to production on Thursday August 16th and at that point you shouldn't see this error anymore.

Thanks for your patience!

3 Likes
5

Sweet! Thanks @cpu.

The process wasn’t clear to me until I read the boulder source code (Thanks to this post). So I’m going to share the process and timeline below for others:

6-August: Submitted pull request on Github as per guideline.
8-August: Merged to publicsuffix/list https://github.com/publicsuffix/list/pull/702
9-August: Merged to weppos/publicsuffix-go https://github.com/weppos/publicsuffix-go/pull/140
10-August: Merged to letsencrypt/boulder https://github.com/letsencrypt/boulder/pull/3814
14-August: Staging (Scheduled/Estimate)
16-August: Deployed to production (Scheduled/Estimate)

ICANN TLD Error on Let’s Encrypt Boulder Source Code pointing to @weppos 's publicsuffix-go.

Thanks for the effort everyone :slight_smile:

5 Likes
6

Thanks for doing that! I'm sure it will help others down the road. Interested folks might also find our Boulder release process README helpful/interesting.

One other thing to note: In the future we plan to treat the PSL data as configuration and not code, letting Boulder live-reload it: Support live-loading public suffix data at runtime · Issue #3132 · letsencrypt/boulder · GitHub We haven't found the time to implement that yet but when we do it should substantially cut down the time between the publicsuffix source of truth being updated and Boulder having that data.

5 Likes
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.