Local HTTP DCV error: does not resolve to any IP addresses on the internet.

wedwards

• February 04, 2022 04:24

Hello, Since this morning, a server is having trouble renewing certificates. `/usr/local/cpanel/bin/autossl_check --all` outputs "Local HTTP DCV error: ... does not resolve to any IP addresses on the internet." and "DNS query error (CAA): SERVFAIL (2)" for 8 domains. tcpdump does not show any SERVFAILs or even CAA lookups. I just see a few AAAA and A lookups, which all succeed. So, I guess AutoSSL queries the authorative nameservers directly. But those return NOERROR. Anyway, this doesn't seem to be matter, as the DCV is still performed without/with faulty CAA records. What I tried:

• There was still a faulty NAT configuration. Removed /var/cpanel/cpnat
• DNSViz, DNSSpy and Verisign don't see any DNSSEC troubles
• I saw some posts regarding issues with Sectigo, so switched from Sectigo to Let's Encrypt as AutoSSL provider
• Switch from BIND to PowerDNS to no DNS server (even though the local resolver doesn't seem to be used)
• Updated resolvers in /etc/resolv.conf from Google to local ones
• Disabled firewalld (all chains in `iptables -nvL` had no rules)
• Ensured that default DNS records such as 'ipv6', 'webdisk' and 'webmail' are present
• `upcp`
• Reboot

Here's one of the failing domains for inspection: REDACTED PUBLIC DOMAIN INFO The subdomains for which the 'local HTTP DCV' fails is not consistent. Actually, it seems completely random: REDACTED PUCLIC DOMAIN INFO After re-running `autossl_check --all` a few times, without making any changes, 3 of 11 domains suddenly passed the DCV validation out of nowhere. This leads me to believe that the cPanel Store is experiencing issues.

• 

  cPRex Jurassic Moderator

  • February 04, 2022 14:07

  Hey there! I edited your post to remove the public domain info for security reaons. The SSL provider, Secitgo, has been having issues for several weeks now. More details on that can be found here:

  0
• 

  wedwards

  • February 04, 2022 15:38

  Hi,

  Hey there! I edited your post to remove the public domain info for security reaons. The SSL provider, Secitgo, has been having issues for several weeks now. More details on that can be found here:

  0
• 

  cPRex Jurassic Moderator

  • February 04, 2022 16:56

  It definitely will make the issue harder to debug. However, there have been instances where bots scan forums looking for domains or IP addresses, and then attack those sites through automated means. Rare...but it can happen. If there is an issue where the domain name is critical to the problem, such as this, especially where you've already performed a good chunk of troubleshooting, it's best to open a support ticket with our team directly. Could you do that and then post the number here?

  0
• 

  wedwards

  • February 05, 2022 16:14

  If there is an issue where the domain name is critical to the problem, such as this, especially where you've already performed a good chunk of troubleshooting, it's best to open a support ticket with our team directly. Could you do that and then post the number here?

  
  I've created a ticket through the cPanel partner, so I don't have access to the ticket number. I'll make sure to update this thread, though.

  0
• 

  wedwards

  • February 08, 2022 14:01

  cPanel support worked around the issue by touching `/var/cpanel/dns_flags/has_broken_ipv6`. I am not sure yet why this workaround works. Nothing seems to be wrong with IPv6. I do observe that many of the connections from the authorative nameservers are RST'ed by the server after a SYN+ACK, so something else might be up with the networking stack there. Anyway, if anyone else comes across this post in the future, try checking your IPv6 configuration. (And don't just touch that file and forget about it; IPv6 is the future.)

  0
• 

  cPRex Jurassic Moderator

  • February 08, 2022 16:16

  @wedwards - I'm glad we were able to help with this!

  0
• 

  BlueOcean

  • May 16, 2022 14:51

  cPanel support worked around the issue by touching `/var/cpanel/dns_flags/has_broken_ipv6`.

  
  Our regular servers running on several datacenters had no issues. (IPv6 taken care of properly) We have one older on-site development server that was running into AutoSSL renewal issues. There are plenty of DNS isues and solutions provided in th eforum regarding AutoSSL. None of the provided solutions worked, except this one! Older server, no IPv6 setup ever done that we are aware off. Touching the file gave us back all the green success messages in the AutoSSL logs! Thanks for posting!

  0

Please sign in to leave a comment.