TL;DR; is it possible to use certbot with dns-01 authentication on one computer (a Jenkins slave) to renew a certificate for a publicly available name, where the certificate will be copied to another computer (an ESXi server) that isn’t able to run certbot and doesn’t have any inbound or outbound internet connectivity?
I’m attempting to automate the process of renewing my certificate:
certbot runs in manual mode with various flags to stop interactive behaviour.
certbot calls an auth-hook to generate the necessary TXT record with my DNS provider (CloudFlare)
certbot performs its magic
certbot calls a cleanup hook that will remove any temporary files and the TXT record from DNS.
cerbot does all this inside a docker container because magical unicorns.
I’m using a dns-based challenge because the host that will receive the SSL certificate is firewalled. Further, the machine in question can’t run the certbot client directly (or the others) because it has a limited/stripped operating system (ESXi).
Failed authorization procedure. liquistate.net (dns-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.hostname.mydomain.net
- The following errors were reported by the server:
Detail: DNS problem: NXDOMAIN looking up TXT for
Can anyone elaborate on that error - server could not connect to the client to verify the domain - who is the server and client in this scenario? And what type of connection is it talking about? Ping? HTTP?
There is some useful advice given:
make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. - its the right name, and has the correct (firewalled) IP address.
check that your computer has a publicly routable IP address - which computer? The computer I’m using to make the request is NAT’d, so has outbound internet connectivity, but not inbound. The machine that will be using the certificate has no outbound or inbound internet connectivity (hence why I want to use dns-01 auth and not web-based).
It’s a misleading error message category that was written before Let’s Encrypt implemented DNS-01. The critical part is the error itself:
Let’s Encrypt queries your domain’s DNS servers, and the necessary TXT record doesn’t exist.
You’re right. It’s general advice that doesn’t really apply when using DNS-01.
Could you provide more information? Are you sure the TXT record is being created with the right name? How does the script work?
Does it wait after the API call to create the DNS record? Cloudflare usually deploys DNS changes in like a second, but not always. Maybe everything’s right, but it’s going too fast, and asking Let’s Encrypt to check the challenge before Cloudflare is ready.
Maybe the domain is actually using a different DNS provider! (letsencrypt.log will confirm that, actually.)
Thanks to everyone for the help; particularly @mnordhoff
I think I’ve narrowed my problem down to some unreliable DNS caching “somewhere” - most likely my ISP because manually looking up using Google’s DNS server (184.108.40.206) in another terminal while my hook script is in progress returns the correct result.
To answer a few queries for future visitors:
I’m using the CloudFlare example hook scripts provided in the certbot documentation. I had to tinker with them a little bit to make them work, but I’ve confirmed that they are creating the correct TXT record in CloudFlare okay.
I did hit the issue that @MrFollies mentioned, whereby the TXT record would get created with portions of my domain name. I set the correct name manually in the hook script to get past this.
So, rather than go to too much heroics trying to solve this DNS caching issue, I’ll take some time to identify a way of getting HTTP based auth to work for my scenario.