403 unauthorized + Incorrect TXT record

My domain is:
I ran this command:
sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d *.bpm-micro.com -d bpm-micro.com -v

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Certificate is due for renewal, auto-renewing...
Renewing an existing certificate for *.bpm-micro.com and bpm-micro.com
Performing the following challenges:
dns-01 challenge for bpm-micro.com
dns-01 challenge for bpm-micro.com
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA.

The following FQDNs should return a TXT resource record with the value

FQDN: _acme-challenge.bpm-micro.com
Expected value: vltkBQBMdQRkvJKWryl1PbfqX38lP2lkqNNh9QT8Crk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Challenge failed for domain bpm-micro.com
dns-01 challenge for bpm-micro.com

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
  Domain: bpm-micro.com
  Type:   unauthorized
  Detail: Incorrect TXT record "vltkBQBMdQRkvJKWryl1PbfqX38lP2lkqNNh9QT8Crk" found at _acme-challenge.bpm-micro.com

Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and that it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.

Cleaning up challenges
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.

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 2.6.0

A month ago I installed certs and now:

bpmmicro@bpm-dev:~$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: auth.dev.bpm-micro.com
    Serial Number: 4bf44a149d30863828fc9f8bf27bc1e556c
    Key Type: ECDSA
    Domains: auth.dev.bpm-micro.com
    Expiry Date: 2023-11-12 14:19:11+00:00 (VALID: 55 days)
    Certificate Path: /etc/letsencrypt/live/auth.dev.bpm-micro.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/auth.dev.bpm-micro.com/privkey.pem
  Certificate Name: bpm-micro.com
    Serial Number: 3d801c1985356fc2a9fd91997e9c759ebd1
    Key Type: ECDSA
    Domains: *.bpm-micro.com bpm-micro.com
    Expiry Date: 2023-09-13 08:10:06+00:00 (INVALID: EXPIRED)
    Certificate Path: /etc/letsencrypt/live/bpm-micro.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/bpm-micro.com/privkey.pem
  Certificate Name: dev.bpm-micro.com
    Serial Number: 39f714bf5ccbd58752aeba397ad7a0a76bf
    Key Type: ECDSA
    Domains: dev.bpm-micro.com
    Expiry Date: 2023-11-12 14:19:20+00:00 (VALID: 55 days)
    Certificate Path: /etc/letsencrypt/live/dev.bpm-micro.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/dev.bpm-micro.com/privkey.pem

*.bpm-micro.com bpm-micro.com is expired. I tried to get a new one but it is failing. I double-check before I press enter if dns record is updated:

bpmmicro@bpm-dev:~$ dig -t txt _acme-challenge.bpm-micro.com +short

I also tried with CNAME but the result is the same. What did I do wrong?

Huh, I don't see why that DNS Challenge fails for that reason. Hopefully someone will have better insight

Sometimes people have gotten faulty data in their TXT record from copy/paste but I don't see that as a problem here.

But, did you know your server is actually using the cert that expired on July 21 ? You show a cert that expired just a few days ago but your server is not using it. See this SSL Checker site (link here). I am guessing you also have a manual step to copy the cert to your Apache setup but did not do that the last time.

Some other general comments ...

Do not use CNAME unless you are pointing to another domain that has the TXT value

You should be checking against the authoritive servers as these are the ones Let's Encrypt will be checking. You don't have to wait for your resolver TTL.

dig txt _acme-challenge.bpm-micro.com +short @ns01.one.com
dig txt _acme-challenge.bpm-micro.com +short @ns02.one.com

You can use https://unboundtest.com to check too

You also got a cert on Aug26 but are not using that either. If you could apply that one to your Apache you could get running now and give time to figure out why DNS Challenge failing


This would only be appropriate if you were using the acme-dns service--either the one hosted by acme-dns.io (not recommended) or one you host yourself (a much better plan). But nothing else you're saying, or showing in any of your command output, is consistent with this. This is something different from merely using DNS authentication. Are you using acme-dns? Because if not, this shouldn't be part of your command line.


Also, that was run twice.
But only one TXT record is shown.


that script 'update' the txt record, so second command likely removed txt record from first one

so script using that lib should do challange one by one for wildcard and base domain


Thank you for all your responses. Our setup is that we have an internal service(you can connect only using VPN) where the requirement is to have HTTPS. To achieve this goal a month ago I followed instructions from this site: How To Acquire a Let's Encrypt Certificate Using DNS Validation with acme-dns-certbot on Ubuntu 18.04 | DigitalOcean. And now I just would like to renew my cert. If you think that I could do that in a different way then please provide me some instructions.

Well I did a workaround and just removed the cert:

$ sudo certbot delete --cert-name 

and then get a new cert by typing the command from an article that I sent in the previous post.

So... you don't need a wildcard cert?


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