Issue with *.zm TLD

Hi,

I get the following error:

Error: urn:acme:error:malformed :: The request message was malformed :: Error creating new authz :: Name is an ICANN TLD

Which, looking through the source for boulder, is caused when there’s a name collision with something in the publicsuffix list. If there’s another way to resolve it, I’m all ears though :slightly_smiling:

Thanks,

Guy.

well usually this would mean that you are not trying to get a cert for a domain UNDER an ICANN TLD but rather for the TLD ITSELF
but your LE command really involves the whole domain doesnt it?

okay stop. I saw something intresting when checking comparison of wiki and PSL.

accoding to wiki, which is the direct source of the PSL entry there's something intresting noted:

Registrations are made at the third level beneath established
sub-domains; registered ISPs can register at the second level, although
there are some unexplained exceptions to this rule.

in short it is set so any Level 2 domain (example.zm) cannot be designated as cookie target (which was the original use for the PSL, but it is also used to check for domain targets for certs.)

seems your site is once of those exceptions.
as it is now you cannot get a cert for ischool.zm but only for www.ischool.zm (because it is a 3rd level domain and wildcards only can cover one level.

Yeah, historically, our company was connected with an ISP founded my our founder, so that might be how we got the Level 2 domain. Oh well, I might just have to bite the bullet and buy a cert for that domain.

This is interesting, it may be an issue with the PSL. It looks like the PSL contains the following rule:

*.zm

whereas the ZM tld has a subset of suffixes, and it also allows registration at the root level. Is ischool.zm some sort of “special” domain, or anybody can register a domain at the root level?

@guysherman you can just redirect to www and use https there.
www is a Level 3 and should work.

@weppos as I outlined in the wiki entry level 2 domains are usually the exception for zm.

@My1 we tend to not trust wikipedia when making the ultimate choice. We did it in the past, but we now require an official approval from the registry (either direct or indirect from the website) or similar proof.

I’m going to research it, but any extra hint or reference is welcome. That’s why I was asking about that specific domain. I’d be interested to know more about these exceptions (specifically, how long is the list and how does it work).

We may either add them as !rule exceptions (that will take higher precedence over the *) or whitelist zm.

1 Like

well you could try to contact their registry over this coz most ppl wont know about this.

also you are speaking in a way as if you are responsible for the PSL, are you one of their maintainers? (just curious)

I’m not sure if anybody can. It might be because our founder also owned an ISP at the time he was able to register it, even if it isn’t open to everybody.

@My1 I have done just that. I just want to deal with the situation where someone directly types https://ischool.zm in their address bar.

well yeah but not many ppl are typing https in the bar, but true that is a problem, and the zm policy is a bit “funny” here.

Yes, I have commit access.

I agree, it is definitely something that is worth investigating. Feel free to open an issue at GitHub - publicsuffix/list: The Public Suffix List.

Even if i am not effected i have two questions:
For .zm the wiki page list exactly 8 sub domains that should be used. And say there are an uncounted list of exceptions. So i do not see any reason to list *.zm as public suffix.
Why not list these eight as public suffix ? And do the same with zw.
ac.zm
co.zm
com.zm
edu.zm
gov.zm
net.zm
org.zm
sch.zm

ac.zw
org.zw
co.zw

Indeed, you would probably want to add zm (not *.zm) to that list, but that would be sensible, given that exceptions are allowed by the issuer.

No not only zm as i said there are known second level domains that are commonly used.
So i see the reason to include them into the public suffix list. But not the wildcard.
And as long as there is no official reference i would change it without discussion.
Since wiki is no trusted source. It can be used for information as long as you can verify
them independently. (see “Family David Spango” )

It was added long time ago, it may very well be an old rule that was never updated.

This is not really how it works. The implications of changing a rule in the PSL should not be underestimated. Changing a rule (in particular a rule affecting an ICANN TLD) requires a verification plus a cross-review.

So you say it is no problem to add an *.tld based on an wikipedia artikle.
While if someone who can prove that he is affected by the entry can not
say wiki is incorrect, and change *.zm to the 8 known general subdomain
will cause no security risk to the known public subdomains while it allow all
legimate “exception” domains to be correctly be used.
ac.zm
co.zm
com.zm
edu.zm
gov.zm
net.zm
org.zm
sch.zm
zm

  1. It was not added by an ICANN request
  2. It block at least one legal domain ischool.zm from using cookies.

If someone would be nagative he could claim that this is an action that has negative businesses impact.

Another point is the PSL is used for rate limit -> No Problem
If LE would block PSL names from issuing Wildcard -> No Problem
If LE block PSL names fromissuing an Cert this is an Problem.
For example if i own top-dyn-dns.domain and allow users to use subdomains.
I can live with the restriction not to use cookies but i have an problem if can not get an cert for my domain
for securely use it as admin or info domain about this service.

I meant zm in addition to your list.

I believe @weppos is saying the opposite: A Wikipedia article is no longer sufficient proof for changes to the PSL.

However, I think what you're getting at is: If Wikipedia was sufficient in the past, it should be sufficient to undo past decisions that were also based on Wikipedia? I think that's not a practical policy, since it would prevent ratcheting up the requirements.

If LE block PSL names fromissuing an Cert this is an Problem.

Note that there are two "sections" to the PSL: ICANN TLDs and Private suffixes. For the purposes of rejecting issuance, we use the ICANN TLD section. Your example of "top-dyn-dns.domain" would presumably be a Private suffix and so would not be rejected.

Thanks for your participation in this thread @weppos, it's been very helpful!

To summarize: '*.zm' is listed on the current PSL, in the ICANN section, which means that any single DNS label, combined with '.zm', is considered an ICANN public suffix. This may be an error in the PSL, which will require an approval from the .zm registry to fix.

From the Let's Encrypt side: We will wait for such an update. We're not planning to generate overrides.

@guysherman, it sounds like you may have contacts at the .zm registry. Would you like to reach out to them and ask them to request a PSL update?