Validation of the required challenges did not complete successfully. No TXT record found at

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain

I ran this command:CertifyTheWeb dns-01 Amazon Route 53 DNS API

It produced this output: The test completed successfully The request certificate failed

My web server is (include version):

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

My hosting provider, if applicable, is: Windows Server 2012R2

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): Certify SSL/TLS Certificate Manager

I have tried both by manually creating an DNS record and without. Any assistance would be appreciated.

1 Like

Could you please take a screenshot of the NS record in your Route 53 interface?

Sometimes users have ended up in a situation where they’re trying to validate using the wrong zone in the wrong account. That’s the first thing that comes to mind, anyway.

1 Like

Thanks for your prompt reply: I can see the TXT record as automatically been created:

But it only has a TTL of 5 seconds it disappears very quickly.

The debug output states it doesn’t exist:

2020-09-18 13:04:27.300 +09:30 [INF] Performing automated challenge responses (
2020-09-18 13:04:27.302 +09:30 [INF] DNS: Creating TXT Record ‘’ with value ‘6SFGTaKFHicalfyH1GTjBtIaL4ECI2ePrG9hZrsomd8’, in Zone Id ‘/hostedzone/Z02508492RWOXJ1VQOBK7’ using API provider ‘Amazon Route 53 DNS API’
2020-09-18 13:05:01.925 +09:30 [INF] DNS change completed.
2020-09-18 13:05:01.925 +09:30 [INF] DNS: Amazon Route 53 DNS API :: Dns Record Created/Updated:
2020-09-18 13:05:01.925 +09:30 [INF] Requesting Validation:
2020-09-18 13:06:02.207 +09:30 [INF] Attempting Challenge Response Validation for Domain:
2020-09-18 13:06:02.207 +09:30 [INF] Registering and Validating
2020-09-18 13:06:02.207 +09:30 [INF] Checking automated challenge response for Domain:
2020-09-18 13:06:03.027 +09:30 [WRN] Challenge response validation still pending. Re-checking [10]…
2020-09-18 13:06:05.066 +09:30 [INF] No TXT record found at
2020-09-18 13:06:05.530 +09:30 [INF] DNS: Deleting TXT Record ‘’, in Zone Id ‘/hostedzone/Z02508492RWOXJ1VQOBK7’ using API provider ‘Amazon Route 53 DNS API’
2020-09-18 13:06:05.718 +09:30 [INF] Validation of the required challenges did not complete successfully. No TXT record found at

I understand. Could you take a screenshot of the NS record in particular?

With Route 53 it’s possible to accidentally end up with multiple hosted zones for the same domain, and I wanted to eliminate that possibility.

1 Like

Sorry is this what you mean - thanks for your help.

1 Like

Ah, if it was created by Route 53 Registrar, that’s probably fine then.

I meant this interface, for what it’s worth:


@webprofusion do you have any ideas? The propagation delay shouldn’t matter right, since Certify waits for the the changeset to complete?

1 Like

Hi. We wait for route53 to say it’s finished doing it’s update but you can also modify the propagation delay time (for instance set to to 120 seconds instead of 60).

Note that the TTL of the record isn’t what makes it disappear, it’s the cleanup phase of the challenge response validation in Certify that’s removing it.

I think the problem may be the wrong Zone ID selection? In Certify when you choose Route 53, then choose the API credentials to use you can select from the Zone ID dropdown list to pick which specific DNS zone you want to update (perhaps you have more than one zone with the same name?). I notice in your log it says the zone id is Z02508492RWOXJ1VQOBK7 but in your screenshot the zone id is Z08...PASK165

1 Like

Ha, I was looking at @_az screenshot, doh. Anyway check the zone ID is correct.

1 Like

Thank you guys for your time.

After you add your Credentials I am only offered one selection and after selecting it is automatically populated by the ID that matches the Host Zone ID.


I have tried with and without the /hostedzone/ tag removed without success.

I can confirm that it is the script that removes the acme txt listing I increased the pause to 90 seconds and the acme test listing was not removed until after that pause.

:confused:. It’s a long shot, but can you also screenshot the “Hosted zone details” interface from my earlier comment? Or anywhere else you can see the nameserver list.

No problem thanks.

Ahhh, I should have pressed you for that information earlier. That’s definitely the problem.

Here is the actual list of nameservers of your domain: 86400   IN      NS 86400   IN      NS 86400   IN      NS 86400   IN      NS

See how none of them match with what’s in your user interface?

I think this domain might be managed from a different AWS account and different Route 53 zone. Are you aware of any other accounts, or other people who configured this domain?

If you instead want to use the this Route 53 zone (as shown in your screenshot), I think you will have to go to Route 53, go to the “Registered Domains” list, and change the nameservers of the domain so they match the ones in your screenshot.

1 Like

Well thank you so much - I am the only account for this domain - it was started as a light sail network. Just out of interest how do you know which are the correct nameservers I am having no issues with dns lookups?

I suppose that “correct” is a matter of interpretation.

Your intent is that the nameservers should be the ones in the Route 53 screenshot.

In reality, a different set of nameservers is in effect. I check this by doing an iterative DNS query (dig +trace ns). Or you can check with a website like

I guess something went wrong during your Lightsail setup? Maybe some things got added and deleted, and then the domain’s configuration got out of sync with your Route 53 configuration somehow.

Either way, you should be able to fix it by following the last paragraph in my previous reply.

1 Like

So the bottom ns servers are the correct ones I need to alter the HOST zone ID ns servers?
Thanks again you are stars.

Those are meant to be identical to each other :frowning: . I’m not sure why they are not, but it does explain why things are not working for you.

I think you need to go to , click, click Add or edit name servers, and then change the list to match the bottom list in your screenshot.

They look like they are to me obviously I need to read up a bit more- thank you for pointing me in the right direction.

No, you’re right, that looks correct.

Earlier, I thought I checked that the two sets of nameservers were producing different results. But double checking, I was mistaken.

I can’t explain why the hosted zone details show a different nameserver list.

If I were you, I’d try to delete and create the hosted zone again - see whether it makes that difference go away.

Otherwise, I’m afraid I’m out of ideas.

Maybe just individually add and remove the nameservers that it thinks it should have (to see if it forces the top level UI to update): 0       IN      NS 0       IN      NS 0       IN      NS 0       IN      NS

It looks like the main AWS UI at the top level is confused (so possibly a bug in how AWS has configured the domain), but that could mean that when the AWS SDK tries to make the TXT record change that the wrong servers are updated? It may even be worth contacting AWS support to get them to check, in case it’s a fundamental bug that could affect other users.

As suggested I have edited the ns entries and it hasn’t altered the Hosted Zone ns. I went to delete the Hosted zone but it wants me to remove all my ns entries before doing that.

It is a bit crazy as I actually see the _acme-challenge entry being added and removed so you would think it is correctly resolved.

Thank you once again for time and suggestions.