Cannot pass DNS-01 challenge despite TXT record being correct

Help
1

Problem Description:

Currently, I am in the process of moving a website from a source domain, to a target domain. I wanted to get a wildcard SSL certificate for the target domain, so the website from the source domain can be on a sub-domain.

During the process of issuing a wildcard domain, I am asked to complete a DNS-01 challenge, and for the life of me, I cannot seem to get it right, I got rate-limited once already.

Not to mention, that I accidentally deleted my cert files in the process as I ran my purge macro while uninstalling certbot.

Right now, all I want to do is, get a new set of certificates both for root and wildcard domains. I wish to move a website from a Freenom domain to my Porkbun domain.

SSL certificates are still being delivered, while the NginX server is running, the files are gone. So it's not that bad but I'd like to get this off my agenda and enjoy my few days off.

TXT fields returned the correct response every time but despite that I never passed the challenge.

My domain is: sas41.com

I ran this command:

sudo certbot certonly --preferred-challenges dns

and

sudo certbot certonly \
  --non-interactive \
  --agree-tos \
  --email XXXXXXX@XXXX.XXX\
  --preferred-challenges dns \
  --authenticator dns-porkbun \
  --dns-porkbun-credentials apikeys.ini \
  --dns-porkbun-propagation-seconds 300 \
  -d "sas41.com" \
  -d "*.sas41.com"

It produced this output:

Failed authorization procedure. sas41.com (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.sas41.com

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

   Domain: sas41.com
   Type:   unauthorized
   Detail: No TXT record found at _acme-challenge.sas41.com

   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.

and

Certbot failed to authenticate some domains (authenticator: dns-porkbun). The Certificate Authority reported these problems:
  Domain: sas41.com
  Type:   unauthorized
  Detail: No TXT record found at _acme-challenge.sas41.com

  Domain: sas41.com
  Type:   unauthorized
  Detail: No TXT record found at _acme-challenge.sas41.com

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-porkbun. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-porkbun-propagation-seconds (currently 300 seconds).

Encountered exception during recovery: certbot.errors.PluginError: ERROR: DNS delete api call was not successfully
Status code: 400
Message: Invalid record ID.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): Nginx/1.14.0 (Ubuntu)

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

My hosting provider, if applicable, is: N/A

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

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

2

Please use the staging environment for testing.

Sometimes it takes longer to propogate to all world wide DNS servers than the time when you can see the results for yourself. DNS often uses anycast for the nameservers. So even when you see a valid result, other DNS clients using the same IP address somewhere else in the world see something differently entirely.

Please increase the --dns-porkbun-propagation-seconds option to something ridiculously large to confirm this (for example, an hour, although even 24 hours has been necessary by some people here on the Community...) and if that works, decrease the propagation time until it stops working. You can use --dry-run to both use the staging environment to begin with and test with decreasing propagation times. You need to use --dry-run, because otherwise the Let's Encrypt validation server will use a cached previously succesful validation, so it won't try again. Using --dry-run enforces the use of a new validation attempt.

3 Likes
3

I already started using the --staging flag and will now use --dry-run as well, I will try to start at an hour, see how that goes.

1 Like
4

Two hours (7200 seconds) did the trick!
Thank you!

1 Like
5

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