Says TXT record is invalid

Hello

For the second time I am running into this problem

I want to issue a cert using the dns method using that command:

certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d *.example.com -d example.com

It asked for a CNAME rec, which I wrote in the dns zone.

but then

Challenge failed for domain example.com
dns-01 challenge for example.com
dns-01 challenge for example.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: example.com
    Type: unauthorized
    Detail: Incorrect TXT record
    "GB6Y067-a3KfsYPSuy8OzaRaWHbfOyiA8hDj8U-GPQs" (and 1 more) found at
    _acme-challenge.example.com

    Domain: example.com
    Type: unauthorized
    Detail: Incorrect TXT record
    "uA1slcB6PGhxkI8l_OdLWKD9JE3QMyFKfdH4vWv3tpQ" (and 1 more) found at
    _acme-challenge.example.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

So, I don't even have those TXT rec in the DNS zone. And I don't see why it is checking for TXT while initially it asked for a CNAME record?
And more importantly, how to fix this and somehow reset the challenge ?

LE asks a new txt record per challenge so not sure about what cname you wrote to where. what's your dns provider?

5 Likes

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

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

5 Likes

No, it asked for a CNAME rec and same happened to the others 20+ certificates I m using on around 5 servers.

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.example.com CNAME e042000-629d-4ba4-a9ad-0e82ada69000.auth.acme-dns.io.

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

that's you are using GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. , but that holds something else(old auth or someone else's) but you don't need to if your main dns provider gives API to update.

5 Likes

thanks.
It cannot really be an old auth since it's a new domain?

1 Like

At least new to you.

DNS-01 challenge

1 Like

let's say it's possible even if I highly doubt given the domain and extension it is.

then I wouldn't be able to recover ownership of my now "own" domain.. looks like there is a flaw somewhere!

Can you show where "it" asks for that?

4 Likes

My bet is on your DNS server implementation (including configuration, including DNSSEC) and/or your DNS records being served to the Public Internet.

I quoted the shell output above ?

I have around 10 others LE certificates on this server, it always went fine (the other I had issue with once is on another server and after a month while trying again, it just worked out of the box without doing anything)

OK, so I loose the bet; I just went with the information I had.
Best of luck to you.

2 Likes

yea. it s quite strange. As a workaround I just used the http verification since I needed the certs fast so I could deploy the nginx host configuration.
I ll try again later

Thanks

1 Like

still it's possible my domain was "too" fresh and dns propagation not quite finished.
but that doesn't answer the original question which is why to tell me to put a cname to verify then complaining about incorrect txt rec (actually non existent in my zone, again). ?

Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server.

Most DNS providers have a “propagation time” that governs how long it takes from the time you update a DNS record until it’s available on all of their servers. It can be hard to measure this because they often also use anycast, which means multiple servers can have the same IP address, and depending on where you are in the world you might talk to a different server (and get a different answer) than Let’s Encrypt does. The best DNS APIs provide a way for you to automatically check whether an update is fully propagated. If your DNS provider doesn’t have this, you just have to configure your client to wait long enough (often as much as an hour) to ensure the update is propagated before triggering validation.

You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.

1 Like

@campones sharing the Domain Name in question may allow the community to assist better. Tools (espically DNS for this Topic) from remote locations from around the globe can help in showing and locating problems.

4 Likes

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