HTTP-01 and TLS-ALPN-01 both fail with “Error getting validation data,” but no validator traffic reaches server

Help
1

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: auth.tcn33.fyi

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

My domain is: auth.tcn33.fyi

I ran this command: caddy reload --config /[path]/Caddyfile --adapter caddyfile. This caused Caddy to automatically request a new certificate for auth.tcn33.fyi.

It produced this output:

  2026-08-16 22:52:14 UTC

  trying to solve challenge
  identifier: auth.tcn33.fyi
  challenge_type: http-01
  ca: https://acme-v02.api.letsencrypt.org/directory

  challenge failed
  identifier: auth.tcn33.fyi
  challenge_type: http-01

  103.252.194.211: Fetching
  http://auth.tcn33.fyi/.well-known/acme-challenge/0C_L0NYzJM3C5p1o4sRFFb76oCz6AsqLqu2Q53Xnp4Q:
  Error getting validation data

  Order:
  https://acme-v02.api.letsencrypt.org/acme/order/2120071235/545845421531

Caddy then automatically tried TLS-ALPN-01:

  2026-08-16 22:52:18 UTC

  trying to solve challenge
  identifier: auth.tcn33.fyi
  challenge_type: tls-alpn-01


  ca: https://acme-v02.api.letsencrypt.org/directory

  challenge failed
  identifier: auth.tcn33.fyi
  challenge_type: tls-alpn-01

  103.252.194.211: Error getting validation data

  Order:
  https://acme-v02.api.letsencrypt.org/acme/order/2120071235/545845443171

The final Caddy error was:

  [auth.tcn33.fyi] authorization failed:
  HTTP 400 urn:ietf:params:acme:error:connection -
  103.252.194.211: Error getting validation data

My web server is (include version): Caddy v2.11.4

The operating system my web server runs on is (include version): Ubuntu 24.04 LTS

My hosting provider, if applicable, is: Self-hosted on a residential connection from Neptune Internet, AS151660. Public prefix 103.252.194.0/23.

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): Caddy v2.11.4, using Caddy’s built-in ACME client.

Additional information:

  • auth.tcn33.fyi has one A record pointing to 103.252.194.211.
  • It has no AAAA record and no CAA record.
  • The same Caddy instance manages more than 40 other *.tcn33.fyi names on the same IP and ports.
  • Let’s Encrypt successfully issued the existing certificates. The newest appear to have been issued on August 1–2, 2026.
  • Another newly created hostname, auth2.tcn33.fyi, produced the same failure during testing.
  • Both production and staging Let’s Encrypt environments have failed.
  • UFW permits incoming TCP ports 80 and 443.
  • There is no source-address or geographic filtering.
  • NAT forwards ports 80 and 443 to the Caddy server.
  • Both ports are reachable from numerous external networks in Australia, India, Europe and the United States.
  • My ISP’s Melbourne and Sydney looking glasses reach the public address without loss.
  • The ISP’s BGP looking glass shows valid return routes to the external test networks.
  • Let’s Debug report: Let's Debug

I temporarily configured this exact external test path: http://auth.tcn33.fyi/.well-known/acme-challenge/codex-connectivity-test - it returned HTTP 200 from 29 of 30 Check-Host locations. (Removed after testing.)

I also ran a packet capture covering both challenge attempts:

sudo timeout 10m tcpdump -ni any -s 0 -U \
    -w /tmp/auth-acme.pcap \
    '(tcp port 80 or tcp port 443)'

No external validator SYN or challenge request arrived during either the HTTP-01 or TLS-ALPN-01 attempt. Other external test requests did appear in captures and server logs.

Because tcpdump captures packets before UFW input filtering, the local firewall doesn't seem to have dropped these validation requests.

Question: Could this be a multi-perspective validation reachability problem affecting one or more Let’s Encrypt validation locations?

Specifically:

  1. Can the order IDs reveal which validation perspective failed?

  2. Does this generic error mean the validator could not establish a connection, or can it represent another internal validation failure?

  3. Is there a known reachability problem between Let’s Encrypt’s validation infrastructure and
    103.252.194.0/23?

  4. Is there another server-side capture or test I can perform to identify the failing path?

2

Thanks for the great report @tcn33 I wish I had something more helpful to say. But, I can answer some questions and offer findings which others may find helpful to diagnose or help.

I can see your cert history from the public logs. As you note the most recent were from Aug1-2. I looked at all the others and none were due to renew after that so we don't know when the problem began apart from sometime after Aug2.

I thought Caddy automatically reverted to ZeroSSL if Let's Encrypt failed. Do you know why that isn't working? If it does that doesn't resolve the issue with LE but it would be helpful info. And, would avoid you suffering an outage.

Given all your domain names I'd think a wildcard cert would be a good candidate. But, that may take some care to get right in your Caddy config. I am not a Caddy expert so can't be of much help with specifics. A wildcard cert uses a DNS Challenge which means LE does not send you any HTTP (or TLS-ALPN) requests for validation. It uses just the public DNS. I mention it only as consideration for the future.

Well, it is a reachability issue from the primary center. (see next question)

The order was helpful to see more details. And, I suppose it confirms the problem was happening from the primary LE validation center (because the detailed failure message did not say "Secondary"). If the primary fails the secondaries do not attempt. When one or more secondary fail you at least see some attempts arrive in your local logs. If the failure was due to secondaries failing it says "secondary" in the message.

It actually is not a "generic" error message. It is specifically an HTTP 400 error code with that specific error message from the LE server. It means the request failed so is somewhat generic in the sense it isn't all that useful :slight_smile: But, it is different than when we see "timeout" in the error so that's something. And, it doesn't say it's a secondary failure.

None reported by LE at this time. But, there are lots of hops between the US primary center and you. The problem could be known to one of those backbone providers but it isn't known to LE. The general status page is: https://letsencrypt.status.io/

3

Thanks - confirmation that this isn't going any further than the primary validation centre is helpful.

I had a look at why caddy isn't falling back to ZeroSSL. My Caddy build includes the ZeroSSL issuer, but my Caddyfile has no global email option. With no explicit automation policy, Caddy 2.11.4 ultimately calls DefaultIssuers(""); - and because userEmail is an empty variable, only the default ACME/Let’s Encrypt issuer is returned:

This seems to explain why no ZeroSSL attempt appeared in the logs.

For now I've disabled the new hostname to avoid any more continuous retries and failed-auth rate limits. Curious whether you think the global email issue here is relevant, but in the meantime I’ll have a chat with my ISP about a potential routing issue between the primary US validation centre and me.

4

Update: no useful info from my ISP, but when I re-enabled that host in my Caddyfile it worked :person_shrugging:

I guess we can consider this one resolved for now... I hope.

5

The log shows both HTTP-01 and TLS-ALPN-01 failing before any validator SYN reaches tcpdump, despite the Check-Host test succeeding from 29 of 30 locations. A low-risk next check is a simultaneous capture on the router's WAN interface and the Caddy host during one retry, which can distinguish an upstream path issue from packets being lost or filtered between the edge and the server.