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 duocloud.net.nz
Details
Could not request a Let's Encrypt SSL/TLS certificate for duocloud.net.nz.

Go to http://smartlivingspaces.com/.well-known/acme-challenge/0JoYIR6ItUQ7roXzBQscUe4W8xfJdQASy-qAfhBGEzY

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: 103.18.56.178.

103.18.56.178 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)

duocloud.net.nz is the main domain name and there are several domain alias that all can be secured apart from smartlivingspaces.nz. Even www.smartlivingspaces.nz 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 smartlivingspaces.nz 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]:

Name:    smartlivingspaces.com
Address: 103.18.56.178

The DOT NZ domain does have another IP:

Name:    smartlivingspaces.nz
Address: 112.109.83.72
3 Likes

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

Could not issue an SSL/TLS certificate for duocloud.net.nz
Details

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

Details

Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/279105458256.

Details:

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

Status: 400

Detail: no valid A records found for smartlivingspaces.nz; no valid AAAA records found for smartlivingspaces.nz

The Internet shows these nameservers:

smartlivingspaces.nz    nameserver = ns1.dnspackage.com
smartlivingspaces.nz    nameserver = ns2.dnspackage.com

But when you ask those servers, they show:

smartlivingspaces.nz    nameserver = ns1.dnspackage.com
smartlivingspaces.nz    nameserver = ns2.dnspackage.com
smartlivingspaces.nz    nameserver = ns3.dnspackage.com
smartlivingspaces.nz    nameserver = ns4.dnspackage.com

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

3 Likes

Let's Debug shows the same error:

Let's Debug (letsdebug.net)

3 Likes

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 www.smartlivingspaces.nz can be secured but not smartlivingspaces.nz

You have to start at the DNS tree root:
nslookup -q=ns smartlivingspaces.nz a.root-servers.net
That output gets you closer.
Pick one of those nameservers and ask it:
nslookup -q=ns smartlivingspaces.nz ns1.dns.net.nz
That output shows:

smartlivingspaces.nz    nameserver = ns2.dnspackage.com
smartlivingspaces.nz    nameserver = ns1.dnspackage.com
3 Likes

The problem I'm referring to:
smartlivingspaces.nz | DNSViz
image

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

2 Likes

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.

3 Likes

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: 8.8.8.8 or 1.1.1.1

2 Likes

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

From
https://dnsviz.net/d/www.smartlivingspaces.nz/dnssec/

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:

3 Likes

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...

2 Likes

You could try switching the DSP:

smartlivingspaces.com   nameserver = ns1.crazydomains.com
smartlivingspaces.com   nameserver = ns2.crazydomains.com

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.

2 Likes

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 "admin@sectigo.com" as admin email: it surly wouldn't be yours

3 Likes

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.

4 Likes