Unable to issue SSL for info.na and school.na

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: info.na and school.na

I ran this command: Install an AutoSSL in CWPPRO

It produced this output: Domain name is an ICANN TLD", "status": 400

My web server is (include version):Apache/2.4.57

The operating system my web server runs on is (include version):CentOS Linux release 7.9.2009 (Core)

My hosting provider, if applicable, is:dic.net

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): CWPpro version:

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):Using CA: https://acme-v02.api.letsencrypt.org/directory

1 Like

Welcome @dicnet

Those two names are in the Public Suffix List. You can get certs for subdomains of those but not the names themselves.

The PSL is used for names that are shared among large groups.



It's more than just "on the PSL" it's in the "ICANN" part of the PSL, meaning that it's not just shared by some hosting company but that ICANN and/or the PSL think that the names aren't directly available for registration. Might it be that those aren't really the full names of the site that's trying to get set up here?


I have no idea why they're in that section of the psl. They do not look like they're nic-administrated.

% dig +short +nosplit @ ns na.
% dig +short +nosplit @ ns info.na.
% dig +short +nosplit @ ns school.na.
% dig +short +nosplit @ ns com.na.
1 Like

And, the beginning of that PSL section actually references http://www.info.na/domain/, and it looks like www.info.na is in fact using a Let's Encrypt certificate, even though one can't get it for info.na. And there are plenty of subdomains with certificates which at a quick glance may be unrelated to each other.



A quick glance of the Namibian TLD suggests that public registration all happens on the third level across partitioned second levels (i.e. like example.co.uk).


Both third and second level. Quite expensive to go on the second level, tho.


@dicnet So, it appears that people are confused about how you managed to register these names because other public records suggest that names at this level (directly under .na) are not available for registration by the public.

Are you working with the domain administrator for .na in some way? Has there been a policy change about what names can be registered under this domain recently?


@schoen yes one can register 2nd level .na domain names, my challenge though it figure out how to get Let's Encrypt to see info.na and school.na as valid names and not as ICANN TLD", "status": 400
I am also unsure removing them from the PSL will do the trick. Users can also register subdomains under info.na and school.na and their Let's Encrypt certificates work 100%
Any ideas what I can do to fix this challenge?

1 Like

So we're still trying to figure out what the current state of things is: Are you working with the domain administrator for .na, and so trying to register names underneath info.na/school.na but also want to put up a web page at those addresses? Are those names yours specifically, or are they just part of how .na organizes its space?

It might be that they're supposed to be in the "Private Domains" section of the PSL instead of the "ICANN Domains" section, but I think we just don't understand enough about the structure of the .na domain space to be able to recommend what it's supposed to be yet.


yes they are my domain names, and I am a registrar for .na, and I offer domain names under .info.na and school.na and yes I would like SSL certs on info.na and school.na
thank you


We're rapidly running into the end of my knowledge, so I'm not sure what one would do with this information either way, but: Are there other registrars that also register names underneath info.na/school.na, or are those subdomains exclusively "yours" to delegate from?

(And I'm not really sure who to escalate this to, it's certainly possible that the current entries on the PSL are "wrong", but I'm not sure who should advise on what they're "supposed" to be, or how to fix them. Also, is not issuing to a name on the ICANN part of the PSL part of the BRs, or might there be some other CA that might be more accommodating?)


Just as a test to try out some other CAs, can you change the CA Directory to one of these, and see if you get a similar error message?

Buypass Go: https://api.buypass.com/acme/directory
ZeroSSL: https://acme.zerossl.com/v2/DV90

I don't really expect them to work either, but it seems like it can't hurt to try.


From my understanding I think PSL listing is right but want to have introduction page on tld itself. Iirc that's allowed (but no wildcard obviously) but boulder rejects it
(There is a problem when it's tld itself because you can't construct base domain name but it doesn't happen here I think)


The Baseline Requirements say we cannot issue wildcard certificates for any names which appear in the ICANN section of the Public Suffix List.

For the sake of consistency, and because we believe it would generally be surprising for a domain name like "co.uk" to serve a webpage, we also refuse to issue any certificate for a name which appears in the ICANN section of the PSL. You can see the code which does that check here: boulder/policy/pa.go at 8545ea8364d877555378a3a2a9e5e5cab5e17f0a · letsencrypt/boulder · GitHub

We could change this behavior, but it is a somewhat risky change from a compliance perspective, and this is (to the best of our memory) the first time an issue like this has come up.

It's possible that another CA would issue this certificate. Another option might be to redirect info.na to something like about.info.na or www.info.na, and get a certificate for that domain name instead?


From a technology perspective, do you think a CAA record with account identifier could be leveraged to ensure compliance in situations like this? It would, of course, require a change to the BR to support this use. I am just wondering if a CAA record would be an efficient / appropriate path forward for registry operators to advocate, as the increase in TLDs is likely to create more situations like this.


I think you'd need some extension to CAA to indicate that it's for exact-name-only. Having a CAA record on a TLD (or TLD-equivalent like .co.uk) is likely to cause confusion for those registered under it which don't have a CAA record themselves. (It has happened in the past but probably not intentionally.)


Wouldn't browsers require a certificate even for a HTTP redirect? As e.g. Chrome/Chromium defaults to HTTPS nowadays.


Thank you all for your valuable feedback.
For now, I have decided to host info.na on one server and set up a Redirect 301 / https://www.info.na in the .htaccess file, which is hosted on another server with a working SSL.

1 Like

You'll need working SSL certificates installed for both info.na and www.info.na for that plan to work properly.