Clarification needed on how TXT record verification works when renewing a certificate generated via dns challenge

I keep running into this error:

certificate request for resulted in error
type urn:ietf:params:acme:error:unauthorized with No TXT
record found at

when attempting to renew a certificate/create a new order.

In digitalocean panel, I see that a new TXT record is addd for the domain in question. Also running dig -t TXT shows

According to this response, a new certificate order creates 2 new
TXT values.

1). by 2 new TXT values, does the previous old existing TXT value as
1 of 2? Or are we saying that 2 completely new TXT values are
generated and have to be added to the previous existing TXT value?

Because I am currently getting back only 1 token for TXT, which is then used to create a new TXT record.

Hi @pnotes

please share your complete command.

Perhaps use --debug-challenges, then Certbot should wait. Then post an update, so it's possible to check your domain. Or check your domain with online tools.

You may have one value per domain name. So there are not always 2 or more TXT values.

I am using my own wrapper around ruby’s acme-client so :

My assumptions:
1). --debug-challenge option will not help in this case

2). the domain in question is offline as this is a dns request and only need to prove control over the domain name in question.

Is that correct?

Do you want to create one certificate with one or two domain names? That's important -> two domain names -> two challenges -> two TXT entries.

So this

in general is wrong. One certificate order may create one, two or 100 new TXT values.

So your question - there is no 1 or 2, there are correct or wrong TXT entries.

Only in the case where you're requesting a cert for a base domain and its wildcard: somedomaind.tld and *.somedomain.tld.


> Do you want to create one certificate with one or two domain names?*

I want to create 1 certificate for the domain in question.

> two domain names -> two challenges -> two TXT entries.

Thanks for clarifying the above. I asked about the number of TXT entries because I was trying to ensure that I was updating my records correctly.

This bring me back to trying to figure out why I am getting this error:

certificate request for resulted in error
type urn:ietf:params:acme:error:unauthorized with No TXT
record found at

Am I correct to suspect that this issue has something to do with the fact that certbot finds in CNAME

Full output of dig -t TXT below:

; <<>> DiG 9.10.6 <<>> -t TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37640
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4000


;; AUTHORITY SECTION: 300 IN SOA 7 21600 3600 1209600 300

;; Query time: 68 msec
;; WHEN: Sat Jul 20 15:55:16 EDT 2019
;; MSG SIZE rcvd: 158

Probably. Why is that CNAME record there? For this to work, you'll need to either:

  • Add the TXT record for, or
  • Remove the CNAME record.

Edit: But to be precise, it doesn't sound like certbot is involved at all--it would be the Let's Encrypt servers that are finding that CNAME, following it, and not finding the expected response.

Why is that CNAME record there?

@danb35 the cname record is used to redirect to Is there another way to do this?

So the wildcard is * CNAME That won't redirect anything, but will make anything * the same IP address as You'd need to properly configure your web server to do what you're talking about, whether that be to redirect the apex to www., or www. to apex. But in any event, the only CNAME you need is www CNAME If you want other hostnames (mail., ftp., etc.)to point there as well, add them individually.

Or, as I mentioned above, add the TXT record for the apex domain, because Let's Encrypt will follow the CNAME record.

I am a bit confused as I am not using a wildcard at all.

Do you mind explaining how wildcards come into play here?

A wildcard CNAME was the only thing I could think of that would:

  • Be a CNAME record,
  • Affect the _acme-challenge label (though it still wouldn't affect the _acme-challenge.staging label), and
  • Have anything to do with the apex/www issue you mention.

So, if you aren't using a wildcard CNAME, we're back to my earlier question: why do you have a record in place of 3600 IN CNAME What do you think it does to accomplish this:


Because, to borrow the words of Inigo Montoya, I do not think it means what you think it means.

There definitely was a wildcard CNAME record – I queried for a random subdomain that couldn’t possibly exist.

But now the domain has moved from Google’s DNS service to DigitalOcean’s, and most of the records in this conversation no longer exist…

Both you and @mnordhoff are correct about the presence of wildcard CNAME record and my confusion was justified because none of the certs order were for wildcard CNAME record.

@danb35 's comment did prompt me to check the domain registration.Turns out that domain renewal had failed due of change in financial records.

I think this led to change in name servers (DO -> Google Domains) and loss of defined resource records for the subdomain in question. Since the subdomain in question did not have defined recource records, DNS lookup for it resolved to wildcard record in the domain register (Google domains) and also led to Let’s Encrypt returning the reported error urn:ietf:params:acme:error:unauthorized with No TXT record found at

And yes, my use of CNAME record for redirection was not appropriate :slight_smile:

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