The system failed to fetch the DCV file

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: gulfview.org

I ran this command: AutoSSL from WHM

It produced this output: WARN Local HTTP DCV error (gulfview.org): The system failed to fetch the DCV (Domain Control Validation) file at β€œhttp://gulfview.org/.well-known/acme-challenge/P_572QBK9UM8D01U-4ZXPEFEZSZPHKH5” because of an error: The system failed to send an HTTP (Hypertext Transfer Protocol) β€œGET” request to β€œhttp://gulfview.org/.well-known/acme-challenge/P_572QBK9UM8D01U-4ZXPEFEZSZPHKH5” because of an error: Could not connect to 'gulfview.org:80': No route to host. The domain β€œgulfview.org” resolved to an IP address β€œ173.231.228.16” that does not exist on this server.

My web server is (include version): AlmaLinux v8.9.0 With cPanel [120.0.5]

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

My hosting provider, if applicable, is: Inmotionhosting

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): cPanel/WHM

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A

I would like to add that the IP address shown in the logs (173.231.228.16) is NOT the IP address gulfview.org resolves to. It is the IP of the previous server.

But your host still seems to be resolving your hostname to that old IP address locally. This error is actually not caused by Let's Encrypt, but some "check locally first before bothering the ACME server check" by AutoSSL/WHM. See Let's Debug for a successful http-01 check for example.

You need to figure out why your local server is using the old IP address for the local pre-test. E.g., is the IP address hardcoded in /etc/hosts perhaps? Or are you running a local DNS server?

3 Likes

It is not in the /etc/hosts file. The DNS zone file shows the correct zone, and if I ping the hostname from the command line I get the correct IP

Maybe get in touch with the support of your hosting provider / AutoSSL/ WHM?

It's kinda strange because it's "just" a "WARN", suggesting it should continu and not error out. Also, it looks like you've never gotten a certificate from Let's Encrypt before: crt.sh | gulfview.org. Are you specifically trying to issue a Let's Encrypt certificate this time? What changed with regard to the previous certificates?

2 Likes

The sectigo cert was expiring, and I made the mistake of deleting it hoping that would resolve this faster.

sectigo is no longer available in WHM on this server.

for just avoiding panel error but not fixing actual problem: just add that ip to a loopback/dummy interface:
not like it need to connect to old server right?

3 Likes

Now it hits the right server, but Apache responds with a 404
17.58.57.4 - - [15/May/2024:03:23:00 -0700] "GET /.well-known/acme-challenge/P_572QBK9UM8D01U-4ZXPEFEZSZPHKH5%E2%80%9D HTTP/1.1" 404 1136 "-" "AppleNewsBot"

.well-known/acme-challenge/ is an empty folder.

applenewbot is just what that, a newsbot from apple: could you upload some test file in .well-known/acme-challenge so we can test if outsider can see it?

5 Likes

http://gulfview.org/.well-known/acme-challenge/this.txt

It was trying to redirect http to https, but fixing that hasn't allowed the SSL to install.

Nevermind. It seems just my IP is being blocked by your system now. Let's Debug and others can still see it.

You may want to review your firewall. It seems very sensitive.

3 Likes

I will, and for the moment I've flushed all blocks, and made a few sensitivity adjustments.

You may need to ask your hosting service why that is resolving to the wrong IP. They provided the infrastructure and should know the answer.

I will point out that we have seen a number of people with problems switching their cPanel from Sectigo CA to Let's Encrypt. I don't think your error is related to this but you might run into it after resolving the above. These are instructions to "reset" the authorization for Let's Encrypt. It seems cPanel tries to use the older Sectigo account info for LE sometimes.

3 Likes

Strangely enough, I cannot get the server (or even my PC) to resolve to that IP at any other time. Not with ping, dig or any resolver checker, but setting the IP as a loopback "seems" to have gotten a workaround for that part.

Maybe your cPanel system needs some sort of reset. I am no expert in cPanel.

But, it is one of its own requests that is resolving that way and failing. It does not look like a request that came from the Let's Encrypt server

3 Likes