Issue with *.zm TLD



I control the domain I’ve been able to get a cert for However, because the publicsuffix list states *.zm as a TLD, I can’t get a cert for, even though I have the domain. The problem here is that some countries, such as Zambia, have a pretty loose policy around TLDs, so *.zm is no more valid, than the list of observed TLDs on the wikipedia page for .zm. I realise this is actually an issue with the publicsuffix list, rather than letsencrypt per se, but it is nonetheless a corner case that letsencrypt should deal with. Is there a way to request that the publicsuffix is bypassed? Surely if I am able to pass the challenge stage then it doesn’t matter that my domain might be a TLD?



Name is an ICANN TLD error *.bn ccTLD

Hi Guy,

What specific error are you getting when trying to get a cert for ? I’m slightly confused as to why this is a publicsuffix list issue …


also iirc every TLD like .com and stuff is and should be on the PSL…



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:




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 ( 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 but only for (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:


whereas the ZM tld has a subset of suffixes, and it also allows registration at the root level. Is 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.

Kenia SLD vs publicsuffix list?

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


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.


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.

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

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