Missing TLD [xn--4dbrk0ce / .ישראל]

Feature Requests
1

Hi,

Trying to generate certificate for a newly approved TLD failes, it is not recognized by either the service or the ACME client.

**the TLD name is **
.ישראל
xn--4dbrk0ce

The message i get is:
Error creating new order :: Cannot issue for "xn--5dbedt4e.xn--4dbrk0ce": Domain name does not end with a valid public suffix (TLD)"

Thanks.

2 Likes
2

Hi @Lavie, and welcome to the LE community forum :slight_smile:

What is the full name?

4 Likes
3

Hi,

Thank you.

Full name of what ?

4

The FQDN that you are trying to get a cert for.

4 Likes
5

I may have misread the topic title.
Is the FQDN: xn--5dbedt4e.xn--4dbrk0ce ?

4 Likes
6

this is a TLD which will have some reserved SLDs
The rest will be end customer domains.

The TLD is .xn–4dbrk0ce / .ישראל]

We currently want to issue test certificate for:

which is the FQDN \ end entity domain....

2 Likes
7

The Internet can resolve it:

Name:    xn--5dbedt4e.xn--4dbrk0ce
Address: 192.115.211.56

So, I agree with your request.
LE should be able to provide a cert for it.

Which ACME client (and version) are you using?

5 Likes
8

ACME.SH
v2.8.9

9

This is a Pilot for introducing the new TLD to the public.

The TLD will start provisioning domains via the Registrars starting September 5th,2022.
Then it will be end customers facing this issue.

1 Like
10

There is s newer version.

Then you may need to wait until it is "official".

@lestaff may know more.

4 Likes
11

This part of Boulder (LetsEncrypt's system) is driven by the public suffix list https://publicsuffix.org/ . Many other web technologies rely on this, including browser cookies.

The registry administering the domain must register with the public suffix list and have the new domain included. This is a failure of the registry, not LetsEncrypt.

8 Likes
12

thanks for the info @jvanasco @rg305 , will submit Zone updates to the publicsuffix project.

3 Likes
13

We should also note that it takes time for Let's Encrypt to respond to changes to the Publix Suffix List.

After the PSL has been updated, Let's Encrypt needs to pull in these changes (this currently happens on the first day of each month, so next scheduled update is on September 1st), and then a new Boulder release will need to be deployed with that change, which can take up to around two weeks in suboptimal cases).

In any case, if the registry plans to let this domain go live soon, the corresponding PR to the PSL should be made ASAP. There is also a certain authentication procedure to be followed by a registry's representative, but that's not Let's Encrypt related.

8 Likes
14

I'm curious how the PSL handles TLDs like this. I always thought their TLD list comes from the IANA?

Although looking at the PSLs commits this is not necessarily the case it seems.

5 Likes
15

If there is a centralized process I haven't seen it. The PSL documentation states this:

Requests for changes to the ICANN section either need to come from the registry, ICANN or the IANA and be provided with links to supporting official documentation.

Sounds to me like "someone authoritative", but not necessarily ICANN itself (for IDN ccTLD's).

5 Likes
16

FYI

The test is in https://github.com/letsencrypt/boulder/blob/main/iana/iana.go

Which imports GitHub - weppos/publicsuffix-go: Domain name parser for Go based on the Public Suffix List.

Yes, the registry does it via the guidelines - Guidelines · publicsuffix/list Wiki · GitHub

Basically you need someone to create a PR, then create a TXT record that references the PR to prove control of the root. On top of that, the register should publish something on their site, and the account connected to the PR should ideally be referenced in the root zone database (Root Zone Database) ,

Having ICANN do this doesn't make sense, because a registry might not want the domain to be included in the PSL as-is. For example, many TLDs don't allow public registrations unless it's on a partitioned subdomain (e.g. .uk vs .com.uk)

7 Likes
17

Well, not directly. Boulder has all its dependencies stored in the /vendor/ directory, so it requires manual updating..

Another reason to hate the Go dependency system if you'd ask me.. Requiring a copy of all dependencies is just silly IMO. I'm not even sure how that's possible with all kinds of different licenses et cetera.

4 Likes
18

Since Go introduced a proper module system, it isn't required anymore. However it is pretty convenient to have all the sources of your dependencies, and makes reviewing upgrades of them easier.

5 Likes
19

I can understand this aspect for security sensitive reasons. Although it's quite a lot of code to check if one would want to do so the first time :stuck_out_tongue:

Although I'm not a developer, I'm not sure if one would always review upgrades of dependencies. That's what integration testing is also for, right?

Anyway, the PSL needs to be updated manually with regard to Boulder, at the moment, although I believe it's also planned to do this automatically, right?

4 Likes
20

There is a monthly job which updates it, but a human still reviews and merges the automatically opened pull request to update the version. We can also trigger that job manually if needed, such as if we want to get the new ישראל TLD deployed during August before the Sept 1 job runs. There usually isn't any urgency to PSL updates though.

8 Likes