# Certbot "Timeout during connect (likely firewall problem)" fix

> Let's Encrypt could not reach your server on port 80 for the HTTP-01 challenge. Check DNS (including AAAA), firewalls and geo-blocking, or switch to DNS-01.

Source: https://ssl.sh/errors/certbot-timeout-during-connect/
Last updated: 2026-11-10

**`Timeout during connect (likely firewall problem)` means Let's Encrypt tried to connect to your server on port 80 to fetch the HTTP-01 challenge file and never got a TCP connection.** Something between the internet and your web server drops the traffic: a firewall, a cloud security group, an ISP block, geo-blocking, or a DNS record that points somewhere else.

## Quick fix

Port 80 must answer from outside on every address in DNS, including IPv6.

Check the three things Let's Encrypt checks, from a machine outside your network:

```bash
dig +short A example.com
dig +short AAAA example.com
curl -4 -v -m 10 http://example.com/.well-known/acme-challenge/test
curl -6 -v -m 10 http://example.com/.well-known/acme-challenge/test
```

- Every A and AAAA address must belong to this server. Delete or fix stale records.
- Both `curl` calls must connect (a 404 is fine; a timeout is not).
- Then retry safely with `sudo certbot renew --dry-run` or `certbot certonly --dry-run -d example.com`.

## Causes

A firewall or security group that closes port 80 is the usual cause; a stale AAAA record is a frequent hidden one.

### 1. Port 80 closed in a firewall or security group

- **Confirm:** `curl -4 http://example.com/` from outside times out; on the server `sudo ss -ltnp | grep ':80 '` shows Nginx or Apache listening.
- **Fix:** allow inbound TCP 80 in every layer: the cloud provider's security group or network ACL, then the host firewall:

```bash
sudo ufw allow 80/tcp                      # Ubuntu
sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --reload   # RHEL
```

### 2. A wrong or stale AAAA (IPv6) record

If an AAAA record exists, Let's Encrypt connects over IPv6. A record left over from an old host, or a server that does not listen on IPv6, causes a timeout even though IPv4 works.

- **Confirm:** `curl -6` times out while `curl -4` works; the error detail shows an IPv6 address.
- **Fix:** remove the AAAA record, or make the server listen on IPv6 (`listen [::]:80;` in Nginx) and open port 80 for IPv6 in the firewall.

### 3. DNS points to another machine

The A record may still point to an old server, a CDN or a load balancer that does not forward port 80.

- **Confirm:** the IP in the error detail is not your server.
- **Fix:** update DNS, or run Certbot where traffic terminates. Behind a CDN, make sure it forwards `/.well-known/acme-challenge/` over HTTP to the origin.

### 4. Geo-blocking, IP allowlists, fail2ban or a WAF

Let's Encrypt validates from several network locations at once and does not publish its validation IPs. Blocking foreign traffic or allowing only known IPs makes some or all perspectives time out.

- **Confirm:** firewall or WAF logs show drops from unfamiliar IPs at the time of the attempt.
- **Fix:** exempt `/.well-known/acme-challenge/` on port 80 from geo and IP rules, or switch to DNS-01.

### 5. The ISP blocks inbound port 80

Many residential and some business connections block inbound port 80.

- **Fix:** use DNS-01 (`certbot certonly --manual --preferred-challenges dns` or a DNS plugin) or TLS-ALPN-01 with a client that supports it.

## Fixes by environment

Wherever the server runs, port 80 must be reachable from the whole internet; if it cannot be, switch to DNS-01.

**AWS, Azure, Google Cloud and other clouds:** open port 80 in the security group or firewall rule attached to the instance or load balancer, not only in the OS firewall.

**Docker:** publish port 80 (`-p 80:80`) on the container that answers challenges, and make sure no other container already binds it.

**Standalone mode:** `certbot certonly --standalone` needs port 80 free; stop the web server first or use `--webroot` with your running server instead.

**Kubernetes (cert-manager):** the ingress controller's Service must expose port 80 publicly; see [cert-manager certificate not ready](https://ssl.sh/errors/cert-manager-certificate-not-ready/).

**No inbound access at all:** use the [DNS-01 challenge](https://ssl.sh/glossary/dns-01/) with a Certbot DNS plugin for your provider.

## Don't do this

- **Loop retries from cron.** Each failure counts toward the limit of 5 failed authorizations per identifier per hour, and long-running failures can pause issuance; see [Let's Encrypt rate limits](https://ssl.sh/errors/lets-encrypt-rate-limit/).
- **Disable the whole firewall** to get a certificate. Open only TCP 80, which can redirect to HTTPS.
- **Hard-code "Let's Encrypt IPs" from a forum post.** They are not published and change.