Why does SSL renewal fail after adding IPv6?

Why a working website can still fail renewal

A site can look fine on your connection while certificate validation reaches a different server. That often happens when the IPv4 address is correct but an old AAAA record still points elsewhere.

For HTTP validation, Let's Encrypt first tries IPv6 when both address types exist. It can fall back to IPv4 after a connection timeout, but a server that answers with the wrong page is a different problem. A successful connection to the wrong website does not prove you control the domain.

Follow the request to the right server

Check the domain's A and AAAA records, including any hostname used by a redirect. Compare the IPv6 address with the address assigned to your current server. Then confirm that the web server accepts IPv6 connections and selects the correct site for that hostname.

HTTP-01 validation uses port 80 and a file under /.well-known/acme-challenge/. If the request reaches a default welcome page, another tenant's site or a proxy that cannot serve that path, renewal can fail even though the main homepage works over IPv4.

Fix the address before requesting another certificate

If you intend to support IPv6, correct the address, listener and challenge handling. If you do not operate IPv6 for this site, remove the incorrect AAAA record. Allow DNS caches to expire before drawing conclusions from another attempt.

Avoid changing several parts of the setup at once. First establish where the request goes; then check the response. Repeated renewal attempts leave the routing mistake in place and make the logs harder to follow.

DNS-based validation is another option when your certificate client and DNS provider support it. It proves control through a TXT record instead of reaching the web server, but it does not repair broken IPv6 access for visitors.