Wildcard certficate with split-horizon DNS

#1

My domain is: int.reboot3times.org

I ran this command:

sudo certbot --server https://acme-v02.api.letsencrypt.org/directory -d '*.int.reboot3times.org' --manual --preferred-challenges dns-01 certonly

It produced this output:

Failed authorization procedure. int.reboot3times.org (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.int.reboot3times.org

My web server is (include version): N/A

The operating system my web server runs on is (include version):

~  cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"

My hosting provider, if applicable, is: DNS provider is internal bind9 deployment.

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): No

Comments:

I have a split-horizon DNS deployment, where some software deployments have two DNS domains: reboot3times.org and int.reboot3times.org - the latter being internal focused where traffic is limited solely to the internal network. The internal DNS is managed by bind9 and the external DNS is managed by Azure DNS. I’ve been having problems with HSTS and self-signed certificates recently, so I wanted to leverage LE to deploy a wildcard certificate to my internal-only domain. I can resolve the TXT record certbot tells me to create on multiple machines, so I know it’s not a resolving issue. It says it’s an NXDOMAIN error, which means that it’s trying to resolve my domain from a remote DNS server somewhere. What is the best way to move past this error?

#2

You need to deploy the DNS challenge TXT record on the externally facing Azure DNS server. The purpose of the challenge is to allow the CA to verify that you control the domain, so it has to be requested externally. You can still use the resulting certificate internally of course.

#3

Yes. That’s the idea behind validation: Let’s Encrypt needs to validate those TXT records so Let’s Encrypt will try to access the DNS from their servers. Needless to say those servers will be remote :wink:

#4

I didn’t know this was how it worked, I thought it was any DNS server that holds SOA. That’s good to know, and I will see about the best way to go about it, thanks!

#5

How do you mean? That the client run on your PC checked the DNS server and told Let’s Encrypt “all is good, you can trust me, honestly! whitehouse.gov is really my domain! Trust me on my blue eyes!”? :wink:

#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.