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 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?
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?
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?
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"
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?
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.
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.