certificate request for staging.msuzoagu.com resulted in error
type urn:ietf:params:acme:error:unauthorized with No TXT
record found at _acme-challenge.staging.msuzoagu.com
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 _acme-challenge.staging.msuzoagu.com shows ;_acme-challenge.staging.msuzoagu.com. IN TXT.
According to this response, a new certificate order creates 2 new
TXT values.
Question:
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.
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.
> 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 staging.msuzoagu.com resulted in error
type urn:ietf:params:acme:error:unauthorized with No TXT
record found at _acme-challenge.staging.msuzoagu.com
Am I correct to suspect that this issue has something to do with the fact that certbot finds _acme-challenge.staging.msuzoagu.com in CNAME msuzoagn.com?
Full output of dig -t TXT _acme-challenge.staging.msuzoagu.com below:
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.
So the wildcard is * CNAME apexdomain.com? That won't redirect anything, but will make anything *.apexdomain.com the same IP address as apexdomain.com. 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 apexdomain.com. 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.
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 _acme-challenge.staging.msuzoagu.com. 3600 IN CNAME msuzoagu.com? 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.
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 _acme-challenge.staging.msuzoagu.com.
And yes, my use of CNAME record for redirection was not appropriate
