SSL Install fails, challenge using old IP address?

Hi all, I'm migrating some sites to a new server. They have all gone perfectly fine until this site. When I try to install a certificate it returns the following.

Could not issue an SSL/TLS certificate for
Could not request a Let's Encrypt SSL/TLS certificate for

Go to

and сheck if the authorization token is available.

If it is, try to request the certificate again. If the token is not available, there may be an issue with your DNS configuration.

Your domain in Plesk is hosted on the IP address(es): , but the DNS challenge used another IP: is the old server IP. How is the challenge trying to look up on the old server IP if the domain DNS records are set to the new server IP?

I'm using Plesk on Windows Server 2019 (shared hosting) is the main domain name and there are several domain alias that all can be secured apart from Even will work but not the non www version. I've double checked DNS settings and everything points to the right IP address. I originally had set as the main domain but got the same result. I'm pretty stumped as to where I'm going wrong as the configuration is the same as all the other sites I've migrated.

Thanks for any assistance.

Hi @andyduo, and welcome to the LE community forum :slight_smile:

Because that is the IP the Internet sees [for the DOT COM name]:


The DOT NZ domain does have another IP:


Ok I see. If I exclude the .com I still get a fail on as follows:

Could not issue an SSL/TLS certificate for

Could not issue a Let's Encrypt SSL/TLS certificate for Authorization for the domain failed.


Invalid response from


Type: urn:ietf:params:acme:error:dns

Status: 400

Detail: no valid A records found for; no valid AAAA records found for

The Internet shows these nameservers:    nameserver =    nameserver =

But when you ask those servers, they show:    nameserver =    nameserver =    nameserver =    nameserver =

You might want to update the nameserver list at the registrar to include all four.


Let's Debug shows the same error:

Let's Debug (


Hmm can you clarify a bit? When I do a lookup I get all 4 NS records returned.

The strange thing here is that the domain does resolve to the correct IP and can be secured but not

You have to start at the DNS tree root:
nslookup -q=ns
That output gets you closer.
Pick one of those nameservers and ask it:
nslookup -q=ns
That output shows:    nameserver =    nameserver =

The problem I'm referring to: | DNSViz

It might not fix your problem; But it is worth fixing [none-the-less].


So is this something that registra needs to fix at their end? The domain is held by the client so I have to instruct them to make changes or request support. Sorry I'm not too sure what you are meaning regarding the NS records needing to be added.

This is something the domain owner can usually modify themselves.


The actual reason this is failing has yet to be determined.

I'm thinking/guessing that maybe the authoritative nameservers are returning different values to different requestors [globally].
That sounds odd - but possible when they are running Anycast type IPs and more than one system responds to any single IP.
Like with: or


I'm waiting on the client to respond re the Nameservers. Interesting thought that this domain would secure fine on the previous Plesk server with the same DNS settings. Only change has been the A records to point at the new server.

@rg305 knows these better than I but this doesn't look right either


I don't know why the www subdomain would pass Let's Debug tests but the root domain doesn't. But, part of the DNSSEC setup looks wrong. See dnsviz:


DNSViz does not reveal the problem at hand.
ID 13646 is one of three set in the root zone for .nz to use.
.nz is using the other two without a problem - but not that one.

Even unbound is not really showing us much of any error detail.

My guess is that the authoritative nameservers are behind some kind of IPS/FW that is blocking LE and Let's Debug [specifically by IP; OR generally - based on the networks that they currently reside in].

Nothing else seems to add up...


You could try switching the DSP:   nameserver =   nameserver =

If that one works, then it might be because it is a different DNS provider.

Compare the ones that work with the ones that fail.
There has got to be a clue there.


I wonder though, if it is the DNS server at fault why it was working before I migrated the site.

Also, thanks everyone for the suggestions so far!

1 Like

There seems to be poor propagation of the domain vs the www sub domain according to whatsmydns: DNS Propagation Checker - Global DNS Testing Tool I wonder if this is a factor?

1 Like

it surely won't help
btw SOA record have "" as admin email: it surly wouldn't be yours


The Let's Debug initial test is fine it is only when it tries the staging system that it fails. So it is consistently affecting just the Let's Encrypt servers.