Read the Detail Line
Certbot prints the reason under each failed domain. The detail tells you which cause to look at:
Certbot failed to authenticate some domains (authenticator: nginx).
Domain: example.com
Type: connection
Detail: 203.0.113.10: Fetching http://example.com/.well-known/acme-challenge/...:
Timeout during connect (likely firewall problem)- Timeout during connect: a firewall, or the wrong IP address.
- Connection refused: nothing listens on port 80 at that address.
- Invalid response … 404: the web server answered, but not from the folder Certbot used.
- DNS problem: NXDOMAIN: the domain has no record yet, or a typo.
Always compare the IP address in the detail line with your server's address. If they differ, the problem is DNS.
1. Check Where the Domain Points
dig +short A example.com dig +short AAAA example.com ip -4 addr show scope global # this server's address
The A record must be this server's address. Watch for an AAAA (IPv6) record left over from a previous host: Let's Encrypt may validate over IPv6 when one exists, so a stale AAAA record fails the check even when the A record is right. Virteche Cloud servers are IPv4 only, so remove any AAAA record when moving a domain to one. After changing DNS, wait for the old record's TTL to expire.
2. Open Port 80
Make sure something listens on port 80, then that every firewall in the path allows it:
sudo ss -tlnp '( sport = :80 )' # nginx or apache2 should be listed sudo ufw allow 80/tcp # if the server uses UFW sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --reload # if it uses firewalld
There may also be a firewall in front of the server. On Virteche Cloud that is the firewall on the server's page in the dashboard: allow TCP 80 there too. Then test from another machine, not from the server itself: curl -I http://example.com/.
3. Serve the Challenge from the Right Folder
A 404 means the request reached a web server that did not have the file. With the --webroot method, the folder you pass must be the one the server block for this domain serves. Test it with a file of your own:
sudo mkdir -p /var/www/html/.well-known/acme-challenge echo ok | sudo tee /var/www/html/.well-known/acme-challenge/test curl -i http://example.com/.well-known/acme-challenge/test # from another machine: expect 200 and "ok"
If you get a 404 or another site's page, the domain is not matching the server block you think it is (check server_name in Nginx or ServerName in Apache), or a redirect sends the request elsewhere. Using --nginx or --apache instead lets Certbot configure the challenge itself.
4. Proxies and CDNs
If the domain is behind a CDN or another proxy, Let's Encrypt connects to the proxy, not to your server. The challenge then works only if the proxy passes /.well-known/acme-challenge/ through to your server over plain HTTP. If it does not, either turn the proxy off for the domain while issuing, or use the DNS challenge, which proves control with a TXT record and needs no open port at all.
Test Without Using Up Your Limit
sudo certbot certonly --nginx -d example.com --dry-run sudo certbot renew --dry-run systemctl list-timers | grep -i certbot # the scheduled renewal
--dry-run uses Let's Encrypt's staging service, which has much higher limits, and changes nothing on the server. For the whole setup from the start, see hosting a website on a VPS.
Let's Encrypt and Certbot are trademarks of their respective owners. Virteche is not affiliated with or endorsed by them. Details about their products come from their public documentation as of the date at the top of this guide.