Let’s Encrypt · IPv6 · Help

Let’s Encrypt validation fails on the AAAA address

Compare IPv4 and IPv6 on the same challenge path when the website works but certificate renewal fails.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

A published AAAA record can direct Let's Encrypt validation to an IPv6 endpoint with a different or incorrect configuration. IPv4 reachability alone is therefore insufficient. Compare the same hostname and challenge path externally over both address families, including response content and redirects. An incorrect HTTP response differs from a connection timeout; fallback to IPv4 is limited rather than universal.

Source basis: Q1 · Q2

Applies to
Applies to HTTP validation for domains publishing both A and AAAA records. The original case used Apache 2.4.68 and Certbot 4.0.0.
How to verify the result
Every intentionally published address family returns the expected content for the same challenge path, followed by a successful controlled certificate validation test.
Your first check

Does the published IPv6 endpoint serve the same challenge content?

Request the same hostname and path separately over IPv4 and IPv6. Working IPv4 access does not verify the AAAA route.

The website opens, but Let’s Encrypt reports an HTTP validation failure involving its IPv6 address. A documented incident shows this split between working IPv4 access and a broken published IPv6 endpoint. The software versions mentioned in that report do not establish a general Certbot defect. Q1

Why the browser is not a sufficient test

When both address families are published, Let’s Encrypt initially prefers IPv6. Falling back to IPv4 depends on the failure: receiving an incorrect HTTP response is not equivalent to a network timeout. Q2 Your useful comparison is therefore one hostname and one harmless challenge-path resource reached through each address family.

Make the difference observable

  1. Record the published addresses. Query A and AAAA for the exact requested hostname, including any redirect destinations. An obsolete IPv6 address may lead to a previous server or a router rather than the intended application host.
  2. Test from outside the local network. Use a network with working IPv6. Request a harmless test file in the intended challenge directory explicitly over IPv4 and then IPv6, keeping hostname, path and expected content the same. Limit the test to systems you administer.
  3. Classify the response. A timeout requires different investigation from a 404 response, a default virtual-host page or a login screen. Record the status, content and destination address. An open port alone does not establish correct challenge handling.
  4. Correlate server logs. Find both requests by timestamp. If only the IPv6 request is missing, examine routing, listeners and the relevant firewall rules. If it reaches the wrong virtual host, correct hostname selection rather than changing the certificate account.
  5. Follow the redirect chain. Check whether a second hostname or HTTPS destination introduces another incorrect IPv6 endpoint. Success at the first URL does not establish that the entire chain works.

Repair the intended service

If IPv6 is part of the service, repair that path, including challenge handling. If the address was published accidentally and no IPv6 service is intended, removing that specific record may be appropriate after checking dependencies and cache lifetimes. Treat this as a deliberate DNS change rather than a routine certificate workaround.

For handoff, keep both response results, DNS values, the test network, server version and timestamps. Once corrected, verify ordinary access and the validation path through every address family you continue to publish. A new controlled renewal test should confirm the actual intended configuration.

Frequently asked questions

Can I instruct Let’s Encrypt to prefer IPv4?

Its documented approach is to correct the published address information and validation endpoint, rather than select an address family in the certificate order. Q2

Should I always delete AAAA?

No. Repair an intentionally provided IPv6 service. Remove the record only when that publication is deliberately being withdrawn.

Describe your case

Support with this issue

We can investigate IPv6 routing, virtual-host selection and the certificate challenge.

Describe your case →Related service: Data & improvements

Sources