Let’s Encrypt scheitert am AAAA-Eintrag

Die Website ist erreichbar, aber Let’s Encrypt meldet beim HTTP-Nachweis einen Fehler zur IPv6-Adresse oder zum AAAA-Eintrag. Ein konkreter Bericht beschreibt genau diese Trennung: IPv4 funktionierte, der veröffentlichte IPv6-Weg nicht. Die eingesetzten Programmversionen machen daraus noch keinen allgemeinen Softwarefehler. Q1

Warum ein funktionierender Browser nicht reicht

Bei vorhandenen A- und AAAA-Einträgen bevorzugt Let’s Encrypt zunächst IPv6. Ein Rückfall auf IPv4 erfolgt nicht bei jeder Art von Fehler; insbesondere eine falsche HTTP-Antwort über IPv6 ist anders zu behandeln als ein Verbindungs-Timeout. Q2 Du brauchst daher einen Vergleich desselben Ziels über beide Adressfamilien.

So wird der Unterschied sichtbar

1. Veröffentlichte Adressen erfassen. Frage A und AAAA für den exakt beantragten Namen ab. Prüfe auch Weiterleitungsziele. Eine alte IPv6-Adresse kann auf einen früheren Server oder auf einen Router statt auf den vorgesehenen Webserver zeigen.
2. Von außen testen. Verwende ein Netz mit funktionierendem IPv6. Rufe einen harmlosen Testpfad im vorgesehenen Challenge-Verzeichnis einmal gezielt über IPv4 und einmal über IPv6 ab. Behalte Hostname und Inhalt bei; teste keine fremden Systeme.
3. Antworten unterscheiden. Timeout spricht für einen anderen Prüfzweig als 404, die Standardseite eines anderen Virtual Hosts oder eine Anmeldung. Notiere Status, Antwortinhalt und Zieladresse. „Port offen“ allein genügt nicht.
4. Serverprotokoll zuordnen. Suche die Testzeit in den Zugriffslogs. Fehlt nur der IPv6-Aufruf, untersuche Routing, Listener und gezielte Firewall-Regeln. Erscheint er im falschen Virtual Host, korrigiere die Zuordnung des Namens.
5. Weiterleitungen verfolgen. Kontrolliere, ob ein zweiter Host oder HTTPS-Ziel eine zusätzliche falsche IPv6-Adresse einführt. Ein sauberer erster Aufruf beweist nicht die ganze Kette.

Passende Korrektur wählen

Ist IPv6 vorgesehen, repariere den veröffentlichten Weg einschließlich des Nachweispfads. Ist die Adresse versehentlich veröffentlicht und IPv6 wird nicht betrieben, kann ihre kontrollierte Entfernung richtig sein. Prüfe vorher abhängige Dienste und Cache-Zeiten. Das ist eine bewusste DNS-Entscheidung, kein universeller Trick zur Zertifikatserneuerung.

Halte für eine Übergabe die beiden Antworten, DNS-Werte, das Testnetz, die Serverversion und den Zeitpunkt fest. Nach der Korrektur sollten der Nachweis und der normale Seitenaufruf über jede veröffentlichte Adressfamilie funktionieren. Ein neuer Testlauf kontrolliert genau diese Annahme.

Häufige Fragen

Kann ich Let’s Encrypt einfach auf IPv4 festlegen?

Die dokumentierte Lösung ist ein korrekter veröffentlichter Adressbestand und erreichbarer Nachweisweg, keine Auswahl im Zertifikatsantrag. Q2

Soll ich AAAA immer löschen?

Nein. Ein beabsichtigter IPv6-Dienst sollte repariert werden. Löschen ist nur bei einer bewusst zurückgenommenen Veröffentlichung sinnvoll.

Fall beschreiben