What does 'Timeout during connect (likely firewall problem)' actually mean?

It means the Let's Encrypt validation server tried to open an HTTP connection to your domain on port 80 and got no answer at all — not a 404, not an error, just silence. That's the signature of a network-level block, not a web-server misconfiguration: a cloud security group or firewall that doesn't allow inbound port 80, an A/AAAA record pointing at the wrong IP, or a home connection where the ISP blocks 80. The word 'likely' is doing real work — it's genuinely almost always the firewall or the DNS target, not your Apache or nginx config. Confirm the record points where you think and that port 80 answers from the outside before touching any vhost.

Why does the challenge work when I load the URL in my own browser but still fail?

Two common reasons. First, since September 2025 Let's Encrypt validates from multiple geographically separate network perspectives (MPIC), so a path that works from your location can still fail if a geoblock, GeoIP firewall rule, or region-specific routing blocks one of the remote perspectives — your browser only tests one path. Second, your browser might be hitting a cached response, a CDN edge, or HTTPS on port 443, while validation starts from a plain HTTP request on port 80. 'Works for me' tests a different route than the one the CA uses.

Should I switch from http-01 to dns-01?

Switch if you need a wildcard certificate (dns-01 is the only challenge that can issue *.example.com), if the host can't accept inbound connections on port 80, or if you're issuing for many names behind a firewall. dns-01 proves control by publishing a TXT record at _acme-challenge, so nothing needs to reach your server from outside. The tradeoff is that it needs a DNS provider with an API your ACME client can drive, and it inherits DNS's own timing problem: the TXT record has to actually propagate to the authoritative servers before validation runs, or you get 'NXDOMAIN looking up TXT'.

Views: 19

Certbot challenge failed (http-01 / dns-01)

Certbot 'challenge failed'? Split by type: check port-80 /.well-known for http-01, or the _acme-challenge TXT record for dns-01. Free instant check.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Certbot got most of the way through, printed something about a challenge, and then stopped with Some challenges have failed or Failed authorization procedure. No certificate. The frustrating part is that this one line covers two completely different validation methods that fail for completely different reasons — and the fix for one is useless for the other. Before you change anything, figure out which challenge you were running, because http-01 and dns-01 break in opposite places.

The two challenges prove control two different ways

Certbot has to prove to the CA that you actually control the domain. It does that one of two ways, and the error you got depends on which:

http-01 — the CA hands your client a token, and Certbot writes it to a file the CA then fetches over plain HTTP at http://your-domain/.well-known/acme-challenge/<TOKEN>. If the CA reads back the right token, you pass. This proves you control what answers on port 80 for that hostname.
dns-01 — Certbot computes a value and you publish it as a TXT record at _acme-challenge.your-domain. The CA queries DNS for that record. This proves you control the DNS zone, and it’s the only method that can issue a wildcard certificate. Nothing has to reach your web server at all.

Same “challenge failed” message, but one is a reachability problem on your web server and the other is a records problem in your DNS. Sort that first.

When http-01 fails

http-01 is a fetch of a file over HTTP, so failures are almost always about that fetch not landing where it should:

Timeout during connect (likely firewall problem) — the validation server couldn’t even open a connection on port 80. This is a network block or a wrong DNS target, not a vhost issue. Check that your A/AAAA records point at the right server and that port 80 is open to the world. Cloud firewalls that only allow 443 are the classic cause; people forget the CA needs 80 even when the site itself is HTTPS-only.
A 404 on the challenge path — the connection worked, but the token file wasn’t where the CA looked. The request hit the wrong document root, a different vhost than the one serving .well-known, or a rewrite/redirect rule that swallowed the path. Certbot’s redirect handling is generous here — Let’s Encrypt follows up to 10 redirects, but only to http: or https: and only to ports 80 or 443 — so a redirect to some other port breaks validation even though a browser would follow it.
It works from your browser but fails anyway — since September 2025, Let’s Encrypt corroborates every validation from multiple network perspectives (MPIC), and the requirement scales toward five perspectives by the end of 2026. A firewall or GeoIP rule that blocks traffic from some regions will fail the ones it blocks even if your own path is fine. If validation is intermittent or region-dependent, look for geoblocking, not for a broken config.

The rule of thumb: http-01 problems live between the internet and your web server — DNS target, port 80, firewall, the exact path — not usually inside the application.

When dns-01 fails

dns-01 never touches your server, so its failures are all about the TXT record — whether it exists, whether it’s correct, and whether it has propagated:

DNS problem: NXDOMAIN looking up TXT for _acme-challenge... — the record isn’t visible to the CA yet. Either the API call that was supposed to create it didn’t (wrong zone, bad credentials, a plugin writing to a provider that isn’t authoritative for the name), or it was created but hasn’t propagated to the authoritative nameservers by the time validation ran. DNS-01 automation that doesn’t wait long enough between publishing and validating hits this constantly.
Wrong or stale TXT value — the record exists but doesn’t match. Old challenge values from a previous failed run left behind, or a provider that appended instead of replaced, so multiple TXT records confuse the check. The record must be at exactly _acme-challenge.<the-name-being-validated>, and for a wildcard it’s the base domain’s _acme-challenge, not a per-subdomain one.
The record is right but issuance still fails on CAA — separate from the challenge, the CA checks your CAA record and refuses to issue if it’s present and doesn’t list the CA. A CAA record permitting only one CA will block Let’s Encrypt even when your dns-01 challenge validates perfectly. This is easy to miss because the challenge itself passed.

Diagnose with DechoNet

DNS Lookup checks whether the _acme-challenge TXT record is actually visible and what value it holds — the fastest way to confirm a dns-01 record was published correctly and to spot leftover or duplicate TXT records. It also shows your A/AAAA records so you can confirm http-01 is pointed at the right server, and your CAA record so you can rule out a CAA block.
HTTP Check fetches a URL the way the CA does, so you can see whether /.well-known/acme-challenge/ is reachable over plain HTTP on port 80 and whether a redirect is sending the path somewhere validation won’t follow.
SSL Check confirms, once issuance succeeds, that the new certificate is actually being served on 443 — and its Certificate Transparency view helps if you also suspect you’re near a rate limit from repeated failed attempts.

Resolution Checklist

Identify the challenge type from the error. .well-known/acme-challenge or a port-80 timeout = http-01; a _acme-challenge TXT / NXDOMAIN message = dns-01.
For http-01: confirm A/AAAA points at the right server, port 80 is open from the outside, and the token path isn’t 404ing or redirecting to a non-80/443 port.
For dns-01: confirm the _acme-challenge TXT record exists, holds the current value, has no stale duplicates, and has propagated before validation runs.
Rule out CAA: if a CAA record is set, it must permit your CA (letsencrypt.org for Let’s Encrypt), or issuance fails regardless of the challenge.
If it works locally but fails from the CA, suspect multi-perspective validation — check for geoblocking or region-based firewall rules.
Need a wildcard, or can’t open port 80? Use dns-01; http-01 can’t do either.

When to Escalate

If port 80 genuinely can’t be exposed (some managed platforms, internal-only hosts), move to dns-01 with an API-driven plugin rather than fighting http-01.
If dns-01 keeps hitting NXDOMAIN despite the record clearly existing, the plugin may be writing to a zone that isn’t authoritative — check where the name is actually delegated before blaming propagation.
If repeated failed attempts have you bouncing off issuance limits, stop retrying and read too many certificates already issued before you make it worse.