Error with generating Let's Encrypt certificate for www version of web using CNAME to non-www version

Help
#1

My domains are:
www.internal.cz
www.cyprich.cz
www.lumen1.wd7.cz
… and much more, about 30 domains

I ran this command:
Certbot renew

It produced this output:

Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: No valid IP addresses found for www.internal.cz

My web server is (include version):
Apache + Nginx rproxy
The operating system my web server runs on is (include version):
Debian
My hosting provider, if applicable, is:

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):
Plesk
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

Hello,

we have problem with generating Let’s Encrypt certificates. For example domain internal.cz. We can generate certificate for domain internal.cz, but not for www.internal.cz. When I try to generate both of versions, I get error message:

Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: No valid IP addresses found for www.internal.cz

DNS records are set well - www.internal.cz is CNAME for internal.cz and internal.cz has DNS A record with IP of server with vhost.

We tried to change CNAME record to A record ( by another domain ) and it works well - certificate is possible to regenerate. But it’s not solution, because the issue with generating certificate we have on >30 domains.

Can you help me, how to solve this problem?

Thank you

Query timed out looking up A for - wildcard CNAME problem
#2

There does seem to be a DNS problem:
https://letsdebug.net/www.internal.cz/132035

It seems the WWW doesn’t exist.
And you have a wildcard CNAME back to the base domain:
[I guess not all systems like that]
image

#3

Try adding an explicit CNAME for WWW.
[not just covering it via the wildcard]

#4

While the suggested workaround with some chance may work, I think in that case the DNS configuration of the domain www.internal.cz isn’t incorrect. There might be some other reason for the domain name lookup failure.

#5

Hi @kubavsh

I think, the configuration is correct. But the configuration is really big - https://check-your-website.server-daten.de/?q=internal.cz

You have 5 name servers with 22 different ip addresses. And DNSSEC

Checked yesterday with Unboundtest, first a Servfail

https://unboundtest.com/m/A/www.internal.cz/3VSENFGG

then a NoError:

https://unboundtest.com/m/A/www.internal.cz/V3NPLCLR

Looks like the high number of ip addresses produces a “too long running query”. So if no results are cached, Unboundtest crashes.

Letsencrypt uses an unbound-instance with the same configuration, so that’s critical.

#6

The failed query took 4 seconds, the successful 6. So it doesn’t look like query time-out. The failure is an explicit error:

May 04 23:52:34 unbound[16162:0] info: 127.0.0.1 www.internal.cz. A IN SERVFAIL 2.590906 0 33

but unfortunately I cannot interpret the trace log without looking at the code. Someone who has already experience with the unbound code may tell immediately what does the error precisely mean, I mean what is its context.

#7

I know. But: First test online - Servfail. Some tests with my local Unbound instance - NoError, but a very long output.

Then again online - NoError.

Looks like some ip addresses answer too slow, results not cached etc. - Servfail.

22 name server ip addresses from different locations are a little bit too much.

#8

It looks like two different errors then. One is timing out on a name server, other error might be an incorrect name server.

#9

https://ednscomp.isc.org/ednscomp/0eb1e0b0ac

1 Like
#10

That should now work.

Read

Your domain uses ns.gransy.com, but that name server had a buggy configuration. Missing Glue records, instead something like a “name server loop”.

So Unbound stopped, too much time to find ip addresses.

CNAME should now work, now it’s enough time to check that.

#11

Hello,

thank you very much, now it’s working well, we are able to regenerate certificate.

2 Likes
#12

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