DNS Challenge only works for root name


I’ve been looking at manual DNS challenges to automate my renewals with my DNS providers api.
What I have found is that if the domain name is “mydomain.com” I can successfully authenticate for a certificate request for “mydomain.com”. The DNS challenge record looks like this:

_acme-challenge TXT 0 " " 600

But I am not able to do the same for a certificate for www.mydomain.com. The challenge record looks like this:

_acme-challenge.www TXT 0 "<VALIDATION_SRING> " 600

The instructions from certbot were:
Please deploy a DNS TXT record under the name
_acme-challenge.www.mydomain.com with the following value:
Before continuing, verify the record is deployed.

Doing a DNS query of the TXT record tells me it looks like it should.
I’m guessing I am doing something wrong but I’m not sure what it is…

without the actual domain name it is difficult for anyone to help

Here’s the full output from certbot and my auth script.
Domain is eyedrink.net

Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for www.eyedrink.net
Output from authscript.sh:
CERTBOT_DOMAIN      = www.eyedrink.net
CERTBOT_VALIDATION  = hMaI_3s8Rp0V2invPg3vDfmBtQW7H_mZ1mg7t9EnC2Q

Old Zone:
@ TXT 0  "v=spf1 a mx -all " 86400
@ MX 20 kookaburra.dannysplace.net 
www CNAME 0 eyedrink.net 
@ A 0 900
_acme-challenge.www TXT 0  "dg4Z_34a7VeWpyzTogcAWh0YfpV_f_rgr2DtRx8kZ-Y " 600

New Zone:
@ TXT 0 "v=spf1 a mx -all " 86400
@ MX 20 kookaburra.dannysplace.net 86400
www CNAME 0 eyedrink.net 86400
@ A 0 900
_acme-challenge.www TXT 0 "hMaI_3s8Rp0V2invPg3vDfmBtQW7H_mZ1mg7t9EnC2Q" 600

DNS Zone Update: Status-Code: 0
DNS Zone Update: Status-Text: Command completed successfully
Sleeping for 60 seconds to enable DNS update.

Waiting for verification...

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
Skipped user interaction because Certbot doesn't appear to be running in a terminal. You should probably include --non-interactive or --force-interactive on the command line.
Cleaning up challenges
Failed authorization procedure. www.eyedrink.net (dns-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct value not found for DNS challenge
 - The following errors were reported by the server:

   Domain: www.eyedrink.net
   Type:   unauthorized
   Detail: Correct value not found for DNS challenge

   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.

the client you are using is getting the right record setup

I think it may be a DNS propagation delay issue

The easiest way to check this is run the command again and then try to do the DNS lookup if it fails to check if the record is available.


I am sure it’s not a delay issue. It works repeatedly for the root DNS (_acme-challenge.eyedrink.net) even with a 20 second delay, but never for a certificate in front of the domain.

I’ve also tried putting in a delay of 2 minutes to no avail.

Looking at the debug log I see this:

For a cert request for www.eyedrink.net (i.e. failed)

  "type": "dns-01",
  "status": "pending",
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/7r77i-uUOZdTjuz-KsA1QA2C54qH6K14IIRuSltIEcY/2161482728",
  "token": "lgZ_iTQ9N0dudTLwEpWezDDwQOwrc-YiY_2AZKlaurk"

For the eyedrink.net (target @) which succeeds:

  "type": "dns-01",
  "status": "valid",
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/y9f9ygjR5TojtAvjjvF7jq0EXu2mQJpguV3ahJttgJg/2159789004",
  "token": "2jLCZvxF5M1d1dcohya6tK-den7ig9xSUZcZQfg1Dr4",
  "keyAuthorization": "2jLCZvxF5M1d1dcohya6tK-den7ig9xSUZcZQfg1Dr4.ao--w1Naw7ai9ZvcV6cTCAbbPc2t1FLUs8jX1a0q7pg",
  "validationRecord": [
      "Authorities": [
      "hostname": "eyedrink.net",
      "port": "",
      "addressesResolved": [],
      "addressUsed": "",
      "addressesTried": []

I know the DNS is OK, because I’m doing manual DNS queries and they are returning OK well before the validation occurs.

It would be nice to see why the request is pending. What sort of response the ACME server got from DNS.

comment removed (replied to an old comment that was edited and changed).

Hi @MrFollies,

Do you ever get an ACME error back from Certbot at the end of the process?


Like this:

  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Correct value not found for DNS challenge",
    "status": 403
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/7iYpVqVjcQbFO0ZdFn_ni7UXxffiROFjj5mpIkhi3pQ/2160309325",
  "token": "f_k5aRijaOhgjZn4KBiT8A5XfZJLmAGxVxZJhtnkGb8",
  "keyAuthorization": "f_k5aRijaOhgjZn4KBiT8A5XfZJLmAGxVxZJhtnkGb8.ao--w1Naw7ai9ZvcV6cTCAbbPc2t1FLUs8jX1a0q7pg"

I have a clean debug file for both a good and a bad attempt. It would be nice to see what the letsencrypt acme server is getting back from it’s DNS check and what it was expecting…

@cpu, is there a way you could see if anything weird is coming back in response to this DNS challenge?

@MrFollies, you didn’t happen to copy and past the exact same TXT record for both domains, right? They would be different for the main domain and the subdomain, but I’m assuming you noticed that.

Nope,… Literally the last test I did was using certbot -manual -certonly and following certbots own instructions.
It works for _acme-challenge.eyedrink.net but not for _acme-challenge.www.eyedrink.net.

I’m certainly no expert on certbot but given that I’ve done what certbot has asked me to do, it seems to me to be a problem with how certbot and my DNS provider are working together.

It would be really great if I could find out what the ACME Letsencrypt server is seeing so I can diagnose further.

Is there a way to do that?

Maybe @cpu can help out somehow.

This issue looks similar.

@schoen, (or anyone else) perhaps to see if this is a certbot issue, you might be so kind as to test this on one of your own domains?

I get the problem with or without the manual auth hook so if you just do a “certonly --manual --preferred-challenges dns” you should see the same behaviour… So long as you do it on a subdomain (host) and not the ‘@’ target of your domain.

I am not going to have an opportunity to do this because I’m going on holiday, but I hope someone else can help you experiment with it! Maybe @bmw could help try it out?

certbot renew --dry-run” works for me, with Certbot 0.19.0 and a bespoke Cloudflare DNS manual hook. For both root domains and subdomains.

Thanks @mnordhoff… I started checking other domains (at other DNS providers and I’ve found the problem.
My providers zone editing API forces me to write the entire zone each time. For TXT records it was sending me back the text in the form"

_acme-challenge TXT 0  "VALIDATIONSTRING " 600

Notice the space before the second quote?

So it wasn’t a case of the root update working and the non-root updates failing… It’s a case of only the last update working… (Because I was creating the quoted string manually instead of just copying what the DNS provider gave me back…)

I’ve changed my hook code to perform a regexp search and replace to remove the whitespace and it’s working just fine!


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