Issuing * wildcard domain returns unauthorized but the record read is exact

Help
1

I am trying to issue *(wildcard) certificate for mentioned domain using acme-dns-auth.py to make sure that the renew happens automatically without needing any human help. It seems that it is able to read the domain TXT record it is as it should be but still not able to authorize.

My domain is:
hexorial.studio

I ran this command:
sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d *.hexorial.studio -d hexorial.studio

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for hexorial.studio
dns-01 challenge for hexorial.studio

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.hexorial.studio CNAME ca84ec58-2c53-429d-b226-4fba20ff0a56.auth.acme-dns.io.

Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue                              
Challenge failed for domain hexorial.studio
Challenge failed for domain hexorial.studio
dns-01 challenge for hexorial.studio
dns-01 challenge for hexorial.studio
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: hexorial.studio
   Type:   unauthorized
   Detail: Incorrect TXT record
   "ca84ec58-2c53-429d-b226-4fba20ff0a56.auth.acme-dns.io." found at
   _acme-challenge.hexorial.studio

   Domain: hexorial.studio
   Type:   unauthorized
   Detail: Incorrect TXT record
   "ca84ec58-2c53-429d-b226-4fba20ff0a56.auth.acme-dns.io." found at
   _acme-challenge.hexorial.studio

   To fix these errors, please 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.

My web server is (include version):
nginx version: nginx/1.18.0 (Ubuntu)

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

Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal

I can login to a root shell on my machine (yes or no, or I don't know):
yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 0.40.0

2

This isn't a TXT record, and it sounds like you fundamentally misunderstand how acme-dns is supposed to work. Review the output of the script again:

Please add the following CNAME record to your main DNS zone:
_acme-challenge.hexorial.studio CNAME ca84ec58-2c53-429d-b226-4fba20ff0a56.auth.acme-dns.io.
3

Ahh, that is a message from the script, I think the script prints CNAME instead of TXT. I tried CNAME that way the certbot is not even finding anything to verify. so I checked the guide and changed CNAME to TXT in my websites DNS and it now says that certbot is able to read the correct TXT record here

"ca84ec58-2c53-429d-b226-4fba20ff0a56.auth.acme-dns.io." found at
   _acme-challenge.hexorial.studio

I ran the command again and did not change TXT record then it finds an old one so the certbot is actually using TXT records

4

Again, that isn't supposed to be a TXT record. The script prints CNAME instead of TXT because you're supposed to be creating a CNAME record, not a TXT record. The script then creates a TXT record for ca84ec58-2c53-429d-b226-4fba20ff0a56.auth.acme-dns.io matching the validation token. Though it really isn't expected that you'd be using that acme-dns host for your production use.

acme-dns confused me for a bit at first--here's the topic I created a while back that got me some answers:

5

@itsmnthn I think I'm missing some information here, because I don't really understand what you're doing here.

You mention you're using the acme-dns-auth.py script. But you didn't tell us why you're using it and which steps you've followed which lead you to the usage of that script.

Are you actually using the acme-dns application? If so, how did you install it, run it, et cetera? Or are you only trying to use the acme-dns-auth.py script, without the acme-dns application?

6

@Osiris @danb35 Thanks for the comments

So I was using acme-dns-auth.py for skipping the CNAME configuration while renewing the cert. so the script caches the params in file and uses it while renewing the cert.

I followed this article How To Acquire a Let's Encrypt Certificate Using DNS Validation with acme-dns-certbot on Ubuntu 18.04 please check the article and let me know if the article assumes anything or missing anything so I can refer to that and would love to write a better version of the article to guide from scratch.

I think I do not have acme-dns application.

I think I do not need *(wildcard) cert, I wrote the script to generate separate for each subdomain I need with specific usage with server configs. I'll maybe share the script as soon as I think it works(stable) best.

7

It looks like the biggest thing the article misses is a fundamental understanding of the purpose of acme-dns. Its author (@joohoi) does operate a public acme-dns instance (which is what's used if you follow that guide), but the intent of that software is that it would be self-hosted, so you maintain control over the DNS system used to validate your domain control. The public instance he operates isn't really intended to be used in production, as its docs make clear:

image
image833×187 12.6 KB