I am trying to set up web apps like a Gitlab instance for a local only environment. It's available only locally or through a VPN. Local CA's or trusting the certificate on every PC that connects is out of the question. I just want to locally validate and manage the certificate without the need for a public domain name.
I get the following error running gitlab-ctl reconfigure:
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[hostname.com] (letsencrypt::http_authorization line 6) had an error:
(/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 26) had
an error: RuntimeError: ruby_block[create certificate for hostname.com]
(/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an
error: RuntimeError: [hostname.com] Validation failed, unable to request certificate.
What do I do? I know I have to exchange PiHole (which is a recursive DNS, since it's based on dnsmasq) for an authoritative DNS server like Technitium DNS server and possibly make a TXT entry, correct? Is that the only step I have to do?
@eddie-LA, a lot of people on this forum have suggested the Smallstep tool for making your own internal CA (although you said this "is out of the question", so maybe you won't be interested in this). You can find those recommendations via
The requirement to have a public domain name is not created by Let's Encrypt but imposed by the browsers that preload trusted certificate authorities.
So this requirement applies to each and every publicly-trusted certificate authority. Anyone who did not enforce it could not be part of a browser's root CA program, nor a CA trusted transitively under these programs. The reason for this is that if you have https://mail.local/ or https://mail.internal/ or https://server.lan/ or something, the meaning of that name is different on every local network. So a public CA can't confirm to users of one network that they're connecting to the "right" operator of this service, without also confirming the same for users of another network. But the right answer would be different on every network, and the CA doesn't want to help the operator of network B impersonate a server on network A, whether deliberately or accidentally.
Concretely, if you could get a publicly-trusted certificate for https://mail.internal/ or a similar name, then people visiting you who got online using your wifi might have their computers try to autoconnect to their corporate e-mail service with Outlook or whatever, and (getting what they perceive as a valid HTTPS connection with a certificate they accept!) provide their username and password credentials to your server. But that wouldn't have been what they intended or expected, because it wasn't the same "mail.internal" at all!