Error during automated certificate renewal

micheld

micheld

Verified User
Joined
Apr 5, 2006
Messages
55
Location
NL
I previously reported about the error with automated certificate renewal due to DNS servers that are in the script, and not using the system's DNS. Meanwhile, I received daily errors Error during automated certificate renewal. Opened DNS 8.8.8.8 en 1.1.1.1 servers for directadmin, but still get the message.
And if I do it manually great new cert via the directadmin web interface it works fine. (its new or renew a different script?)

It is now almost a daily task to renew the domain, I don't think it's the intention

See the error what i (and the users)

acme: error: 400 :: urn:ietf:params:acme:error:dns :: During secondary validation: DNS problem: query timed out looking up A for ******.nl; DNS problem: query timed out looking up AAAA for ******.nl
[www.******.nl] acme: error: 400 :: urn:ietf:params:acme:error:dns :: During secondary validation: DNS problem: networking error looking up A for www.******.nl; DNS problem: query timed out looking up AAAA for www.******.nl
Certificate generation failed.

(DA_IPV6=false)
 
Last edited by a moderator:
micheld said:
DNS problem: query timed out looking up AAAA for www.******.nl
Click to expand...
So it's everytime for ipv6 is that correct?

micheld said:
(DA_IPV6=false)
Click to expand...
You mean you don't have/use ipv6? If that is the case, is ipv6 totally disabled like should be? So also in network/OS?
Best also disabled in bind/named.

Also try here and see result:
 
Last edited by a moderator:
Hi Richard,

No its not always IPv6 problem see here:
2022/11/16 00:11:52 [INFO] [****.com, www.****.com] acme: Obtaining SAN certificate
2022/11/16 00:11:53 [INFO] [****.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/175864518787
2022/11/16 00:11:53 [INFO] [www.****.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/176635068717
2022/11/16 00:11:53 [INFO] [****.com] acme: authorization already valid; skipping challenge
2022/11/16 00:11:53 [INFO] [www.****.com] acme: Could not find solver for: tls-alpn-01
2022/11/16 00:11:53 [INFO] [www.****.com] acme: use http-01 solver
2022/11/16 00:11:53 [INFO] [www.****.com] acme: Trying to solve HTTP-01
2022/11/16 00:12:46 [INFO] Skipping deactivating of valid auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/175864518787
2022/11/16 00:12:46 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/176635068717
2022/11/16 00:12:46 Could not obtain certificates:
error: one or more domains had a problem:
[www.****.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: query timed out looking up CAA for ****.com
Certificate generation failed.

The DNS server 1.1.1.1 and 8.8.8.8 are working for this server i use both on /etc/resolv.conf now
In script /usr/local/directadmin/scripts/letsencrypt.sh i see there is this : DA_IPV6=false
But i not understand when i create new cert for the domein ****.com using the webinterface of directadmin is working fine.
But renew not, do the use a other DNS servers or script?
 
Last edited by a moderator:
micheld said:
But renew not, do the use a other DNS servers or script?
Click to expand...
Not that I'm aware of, but I'm not 100% sure. It might be the input is different, or maybe it's caused by some other reason.

I've seen if I visit your domain, then I can visit it either way, with our without www in front, so that should also not cause any issues.

It's indeed the CAA fail, we've seen that here before.
Looks like for some reason on a renew, the CAA record is not created or not in time.

Do you have this in your directadmin.conf file?
dns_caa=1

and this empty file present:
/usr/local/directadmin/data/templates/dns_caa.conf

Do you have DNSSEC in affect?

I once had this issue and solved it by adding these records into my DNS:
Code: 
domain.com.  3600    IN      CAA     128 issue "letsencrypt.org"

You could try that.

@zEitEr maybe on clue on this issue?
 
Seen this before on only one server. All attempts of renewals failed with cron, but succeeded when triggered manually. Don't have an access to this server already. And don't have in my records on how we solved it.

My guess is that we changed public DNS in the script letsencrypt.sh
 
Oke it's still an odd issue.
But if you don't use ipv6, I would suggest starting to completely remove it from your system.

It seems the dns_caa=1 is not mandatory if you don't intend to use such records.

Do you use cloudflare and/or external nameservers?

Might be best you send in a ticket for this so somebody can have a look in your system.
 
zEitEr said:
p.s. DirectAdmin and letsencrypt will need to be updated.
Click to expand...
Yes indeed.

However:
This issue is fixed by adding additional fallback logic to Cloudflare DNS, if there was an issue accessing Google DNS
Click to expand...
It's known that Google DNS has/uses certain limits, so why not using Cloudflare DNS as first and Google as second/fallback. Something I suggested to DA earlier (around 2 years ago).
 
micheld said:
Best way is to use our own dns server the never block.
Click to expand...
No that wouldn't be good, because the use of external DNS is to guarantee that it works from outside. Which is explained in the thread you point to.

micheld said:
On debian 10 i disabled IPv6 on that server. <- Why should work manually? (try something) haha..
Click to expand...
Exactly. I've seen more odd more or less unexpected things happen over the years. ;)
 
usually datacenter has own DNS resolvers, so put them first, than, as additional - open resolvers. its best idea. local resolver at least 10 times faster (usually 50-100 times faster) because it nearest, literaly on next-hop + it has cache so websites you own, works faster if they include data from other sources and must resolve them each time for each user's request.
 
You must log in or register to reply here.
Back
Top