I control the domain ischool.zm. I’ve been able to get a cert for www.ischool.zm. However, because the publicsuffix list states *.zm as a TLD, I can’t get a cert for ischool.zm, 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?
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
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?
@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.
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.
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
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
It was not added by an ICANN request
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.
