Could not issue an SSL/TLS certificate

My domain is: bawmotorsport.com

I ran this command:

It produced this output:
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/318148822927.

Details:

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

Status: 400

Detail: DNS problem: server failure at resolver looking up A for bawmotorsport.com; DNS problem: server failure at resolver looking up AAAA for bawmotorsport.com

My web server is (include version): nginx

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

My hosting provider, if applicable, is: PT. Arupa Cloud Nusantara

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

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

Per the error you shared, your hostname is not resolving. Let's Debug is having a similar DNS resolution failure.

You may want to talk with your host or move to a more resilient DNS provider.

3 Likes

You should check your DNS name servers and make sure you are updating the right ones. Your DNS tree is mis-configured

https://dnsviz.net/d/bawmotorsport.com/dnssec/

Review all 6 warnings at DNS viz

5 Likes

DNSviz is now all good. DNSSEC activated along with registrar .com DS key as well.
https://dnsviz.net/d/bawmotorsport.com/dnssec/

letsencrypt and letsdebug still saying the same thing about A record.

DNS propagation checker ok too:

What else can we check? Why would let's encryp server unable to resolve for A record.

1 Like

There are 2 Nameserver Errors here
https://zonemaster.net/en/result/082d902ae0053e20

And here Hardenize Report: bawmotorsport.com

I suggest resolving them might help.

2 Likes

Ack, fixed the recursive noted in zonemaster. Hardenize does not update.
We can't fix the nameserver on same ip.
However, when we check, the domain resolves, but why does letsencrypt shows it unable to resolve, or does it mean something else behind the error of not resolving A record?

1 Like

Here is what the online tool https://unboundtest.com/ reports https://unboundtest.com/m/A/bawmotorsport.com/FSN2QLPJ

It is long; I didn't read through all of it.

2 Likes

I also see that single lookups for your A and AAAA records give the correct response on various tools.

Do your DNS servers have any kind of firewall / DoS settings? The Let's Encrypt servers make rapid and numerous queries and can sometimes be blocked by such things.

I see the IP for your DNS server is the same as for your web domain. Is this your long-term plan? Because such a limited presence for DNS servers is not good practice.

3 Likes

It is running on simple web panel plesk, both dns and web are on it.
Works fine with let's encrypt for almost 6 years, somehow broken with that same let's encrypt error for about 20 domains that are on it. Not sure if it is changes or update on plesk side or the let's encrypt (LE) side. Through it all resolving for A record is not a problem which is conflicting with the LE error message

Thanks to all the guide from various site above posts, we are able to fix all, including the recursive as noted on hardenize, so now it is all orange/yellow status.
https://www.hardenize.com/report/bawmotorsport.com/1708795748#domain_dns_zone

4 Likes

@arupa, you name servers have poor responsiveness.

3 Likes

Well this really depends on where that dnsspy is located, which I assume in US.
We are in Indonesia, so locally is great.
But we can see the performance here, of course for Asia it varies a lot.
But it is reachable, and it will responds.

About

The Let's Encrypt server farms are in the US and Europe (today). It uses multipoint validation from various global points which may change in future.

What does your dnsperf test show when using more distant locations?

Are you able to view your DNS logs? You should see many from Let's Encrypt when you request a cert that needs fresh validation. Do you notice odd lags or behavior in the lgos?

A cert request that is a duplicate of a recent one may cache the validation for 30 days so then only the CAA lookup may be done (to ensure you still allow LE). Best to do these tests with --dry-run to avoid that.

3 Likes

Yes; I measure from the USA.

Also note Let's Encrypt uses Multi-Perspective Validation Improves Domain Validation Security - Let's Encrypt

2 Likes

DNSPerf on distant seems to be inline with ping time, so typically USA is about 200-300msec.
https://www.dnsperf.com/dns-speed-benchmark?id=c716e6hlt0yhmuu

I am monitoring the dns error log which on plesk is /var/log/messages showing no errors on those domains we are trying to renew.
The LE requests are logged on /var/log/plesk/panel.log, these shows the same error as letsdebug.
Here is a recent one:
https://acme-v02.api.letsencrypt.org/acme/authz-v3/319170246337

I am completely dumbfounded here looking to find the cause.
It was working fine for many years, only to stop in late January 2024 for all of the domains. I am not sure if Plesk or LE changes something which I do not know that I should comply to.

2 Likes

To me, that seems like the most likely reason for an LE failure [at this time].
Given that:

  • Two nameservers are being used:
bawmotorsport.com       nameserver = ns1.axisprima.com
bawmotorsport.com       nameserver = ns2.axisprima.com

But both resolve to the same IP:

ns1.axisprima.com       internet address = 103.90.248.97
ns2.axisprima.com       internet address = 103.90.248.97

[that means that the (already somewhat heavy) LE DNS requests would be doubled (to that single IP)]

  • No other tools can find a DNS issue [while using single/low DNS query rates]
3 Likes

Oh well...so we did it using a separate IP for NS here. Full green now, I think IPv6 is not necessary as we are not even ready for that one.

Hardenize Result:
https://www.hardenize.com/report/bawmotorsport.com/1708838738#domain_dns_zone

Zonemaster ok too: https://zonemaster.net/en/result/ab4bf6f6a46e3c05

DNSPerf ok too: https://www.dnsperf.com/dns-speed-benchmark?id=mt8b4ylt12r5zw

LetsDebug still shows the sames.
Funny enough on DNS inquiry it is able to find the A record shown here in the first red arrow.
But on the acme, it is unable to resolve for A record, second red arrow.
https://letsdebug.net/bawmotorsport.com/1814896?debug=y

Almost at wits end here...

2 Likes

What systems/programs are used to secure/protect your DNS servers from the Internet?
[anything like: IPS, Firewalls, Fail2Ban, Geo-Location / IP Blocking, etc.]

Also, what does the routing table look like on those DNS servers [and also on the routers immediately in front of the DNS servers]?

3 Likes

We have firewall, nat, and fail2ban.
Monitoring fail2ban blocked IPs, we do think those are from LE. We could flush these and see if it makes any effect.
Firewall external and nat also pass thru all.
We test it from local PCs doing normal nslookup for A, SOA, TXT records.

But all seems to point towards the BIND NS.

1 Like

Definitely worth a try.

2 Likes

We did:

  • turn off firewall on plesk
  • remove all IPs from ban list and turn off fail2ban
  • turn off WAF (I know has nothing to do, as the HTTP portion works on LE)

still comes up with the A record error on LE, like it is unable to resolve bawmotorsport.com.

Is there a way to test LE's own DNS lookup, does it try to hit our DNS authorized server? or does it resolve else where, we did check with google dns and it is fine there.

1 Like