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: augustusenterprise.com
I ran this command: certbot --apache
It produced this output:
Challenge failed for domain augustusenterprise.com
Challenge failed for domain www.augustusenterprise.com
The operating system my web server runs on is (include version): Ubuntu
My hosting provider, if applicable, is: DigitalOcean
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): No
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
I have a wordpress site that I created a couple days ago, I ran certbot --apache and everything worked perfectly. I deleted the entire server and recreated it again. Only this time, I am getting errors with certbot and things do not work anymore. I am guessing this has to do with the fact that the certificates have already been made or something.
What should I do here to get this working? My domain is augustusenterprise.com and it is running WordPress on Ubuntu.
We need to see the full Certbot output to help you.
To make a guess: the IP address that your domain currently points to (
22.214.171.124), does not respond to HTTP connection requests. It simply times out:
$ curl -m10 -i http://augustusenterprise.com
curl: (28) Connection timed out after 10000 milliseconds
Two possibilities to think about:
- Have you updated the domain's IP address to your new server's IP address?
- Have you port forwarded and opened TCP ports 80 and 443 on any firewalls or routers running on or in front of your server?
- Yes, it is updated:
- No, but this has never ever been a requirement. Either way just to make sure, I ran these two commands:
ufw allow 80
ufw allow 443
to open these up but I got the same error.
Also, 126.96.36.199 is the correct IP that the domain should be pointing to. 188.8.131.52 was the old one, so I'm not sure why it would still be pointing to that one. Again, my guess is the old certificates.
(Most) certificates have absolutely nothing to do with IP addresses. Let's Encrypt certificates are domain-validated (DV) certificates, meaning that they only cover domain names.
Google Dig's findings concur with @_az's:
I think, more importantly, you might want to take a look at the nameserver (NS) records in the screenshot below. They're not DigitalOcean.
Not surprisingly, according to Open Port Check Tool - Test Port Forwarding on Your Router, ports 80 and 443 are closed for augustusenterprise.com (
184.108.40.206) when checked correctly via the domain name, not the IP address. However, port 80 is open for
220.127.116.11, but port 443 is closed. The results showing for
18.104.22.168 may not represent the state well due to being checked via IP address.
Yes, the issue has been solved.
The problem was that my domain's nameservers were switched from DigitalOcean to Domain.com nameservers without my knowledge. A quick ICANN lookup shows this. This is why there was an issue with certbot.
Thank you all!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.