Domain name does not end with a valid public suffix (TLD) (v2)

Hello everyone, and thanks for your time.

I am currently setting up an update environment for our current GitLab environment.

One of the functions that is trying to be enabled is SSL, through the ACME protocol, letsencrypt.

Within our LAN, we already have a DNS service already configured, with the record ‘gitlab.dev.primary’ pointing to the update environment; and we also have our own ACME Provider API based on Step-CA solution.

The letsencrypt parameters, acme_production_endpoint and acme_staging_endpoint, have already been configured to point to our ACME provider API.

The problem we are having is that when executing gitlab-ctl reconfigure, when trying to issue the certificate, the following error appears:

Running handlers:
There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[gitlab.dev.primary] (letsencrypt::http_authorization line 6) had an error: Acme::Client::Error::RejectedIdentifier: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 41) had an error: Acme::Client::Error::RejectedIdentifier: Error creating new order :: Cannot issue for "gitlab.dev.primary": Domain name does not end with a valid public suffix (TLD)

Apparently the DNS zone .primary does not meet the conditions for issuing the certificate; although we have already issued certificates for this zone with our ACME Provider API with other products, such as cert-manager or certbot.

Since this is an internal environment, not public; and that I am using my own ACME provider API, shouldn’t it be possible to issue the certificate? is there a way to bypass or disable this validation?

Thank you again for your time and I apologize for my bad English.

Hello,
In the end, does anyone have any idea about this topic?

Even in an internal environment (and is it air-gapped or just behind a router) it’s a bad idea to use TLDs that are not registered. If the environment is not completely air gapped there will be systems on the border that can access both, and they will have problems finding out what that name refers to if somebody registers it on the public internet some day. If the internal environement is truly air gapped the situation is better, but there are probably still ways the name could leak and cause problems.

(If there are wireless capabilities anywhere in the network, there might be air gapped units inside the internal environment, then you’ll need to define things properly)

Apart from that I don’t know much about the ACME protocol or gitlab’s ability to create certs.