Lets Encrypt mit IPv6 oder AWS EC2

    Hi,


    ich habe seit etwa einem Monat Probleme bei der automatischen Verlängerung oder der Neuanlage von LE-Zertifikaten. Die Fehlermeldung ist:

    Code
    [20.10.2019 15:38:19] ACME2: <DOMAIN>: DNS check failed: DNS error: unknown/invalid IP(s) found in DNS: <ADDRESS>


    Dabei habe ich zwei Szenarien ausgemacht, die Probleme machen. Habe aber nur bedingt ein Verständnis oder eine Lösung des Problems.

    1. <ADDRESS> ist eine IPv6 Adresse. Der Server hat eine IPv4 und eine IPv6 Adresse. Wenn ich die IPv6-Adresse auf dem DNS lösche, funktioniert die automatische Verlängerung. Aber das ist nicht der wahre Jakob. Schließlich soll auch IPv6 funktionieren und hat auch bis vor ca. einem Monat funktioniert.
    2. <ADDRESS> ist eine IPv4 Adresse und der Server ist eine AWS EC2 Instanz. <ADDRESS> ist die externe IP-Adresse des Servers, die aber naturgemäß nicht der lokalen IP des Servers entspricht. Hier habe ich keine Idee, wie das zu lösen ist. Auch das hat bis vor ca. einem Monat problemlos funktioniert.


    Hat hier jemand eine Idee, wie man das lösen kann. Beides ist sehr ärgerlich.

    Zitat von lchel

    [*]<ADDRESS> ist eine IPv6 Adresse. Der Server hat eine IPv4 und eine IPv6 Adresse. Wenn ich die IPv6-Adresse auf dem DNS lösche, funktioniert die automatische Verlängerung. Aber das ist nicht der wahre Jakob. Schließlich soll auch IPv6 funktionieren und hat auch bis vor ca. einem Monat funktioniert.


    Sind Port 80 und 443 auf der IPv6-Adresse offen? Wenn nein: öffnen.


    Zitat

    <ADDRESS> ist eine IPv4 Adresse und der Server ist eine AWS EC2 Instanz. <ADDRESS> ist die externe IP-Adresse des Servers, die aber naturgemäß nicht der lokalen IP des Servers entspricht.


    IPS -> IP_NAT. Wurde hier im Forum bereits beschrieben.


    Zitat

    Auch das hat bis vor ca. einem Monat problemlos funktioniert.


    Ggf. seit dem Update auf LiveConfig 2.8?

    Zitat von antondollmaier

    Sind Port 80 und 443 auf der IPv6-Adresse offen? Wenn nein: öffnen.


    IPS -> IP_NAT. Wurde hier im Forum bereits beschrieben.


    Ggf. seit dem Update auf LiveConfig 2.8?


    Hi,


    die Ports sind offen.


    Wir betrieben das DNS vollständig disjunkt von Liveconfig, d.h. ich habe in Liveconfig keine DNS-Konfiguration. Wie konfiguriere ich denn dann IPS.IP_NAT? Im Handbuch habe ich nur was gefunden, für den Fall das Liveconfig einen BIND konfiguriert.
    Die AWS EC2 Instanz ist ein lcclient.


    Das mit dem Update auf 2.8 könnte passen.


    Besten Dank im Voraus.

    Mir ist nicht bekannt, dass LiveConfig + let's Encrypt + NAT (+ konfigurierter IPS.IP_NAT) im Moment funktioniert!
    Bei unserem letzten vServer mit NAT konnte bis zum letzten 2.8.4 Release kein Zertifikat mehr erstellt werden. Und laut Changelog wurde auch nichts mit NAT + Let's Encrypt geändert.


    Wir haben mit dem aufkommen des Problems unsere betroffenen Server mit NAT alle auf eine Instanz ohne NAT umgezogen. Was eh schon längst überfällig war.

    Öh, mir ist nicht bekannt dass LiveConfig + Let's Encrypt + NAT im Moment nicht funktioniert...


    In die Tabelle IPS muss in die Spalte IPS.IP_NAT die "öffentliche" IP (zu jeweiligen privaten IP) hinterlegt werden, damit die DNS-Prüfung erkennen kann ob die jeweilige Domain korrekt konfiguriert ist.


    Ich gebe zu, dass wir überrascht sind wie viele Server tatsächlich hinter NAT betrieben werden. Daher soll LiveConfig künftig automatisch erkennen, wenn es mit "privaten" IPs läuft; die Konfiguration der NAT-IPs soll künftig direkt über die GUI möglich sein.


    Viele Grüße


    -Klaus Keppler

    Das ist dann äußerst merkwürdig - weil nämlich viele Anwender hinter NAT nun die öffentlichen IPs in IP_NAT hinterlegt haben und damit alles funktioniert...
    (unsere CI-Test-Server hängen auch in einem privaten Subnetz, auch da klappt's mit IP_NAT problemlos).


    Falls das Problem aktuell noch besteht, könnten wir das anhand konkreter Daten mal prüfen (also Domainname mitsamt den zugehörigen Einträgen in IPS.IP_ADDRESS and IPS.IP_NAT).


    Viele Grüße


    -Klaus Keppler

    Zitat von TCRserver

    Meine Vermutung war, dass der LC DNS-Resolver bei Servern mit NAT gegen die interne IP-Adresse geprüft hat und nicht gegen die öffentliche Adresse.
    Ich habe es aber nicht weiter verfolgt, da wir eh umstellen wollten.


    LC führt ein ungecachtes Resolving (also ohne "externe" DNS-Resolver) durch, um die öffentlich hinterlegte IP einer Domain herauszufinden.
    Wenn LC keine eigenen DNS-Anfragen ausführen kann (z.B. weil Port 53 outbound blockiert), dann nutzt es den im System konfigurierten DNS-Resolver.


    Eine mögliche Erklärung wäre natürlich, dass der DNS-Resolver andere Daten zurückliefert als erwartet - in diesem Fall also z.B. die private statt der öffentlichen IP-Adresse. Das müsste man mal im konkreten Einzelfall prüfen.

    So habe ich das auch aus der Doku raus gelesen.
    Aber gegen welche IP Adresse validiert LC es, also welche http-Server Adresse?


    Mein Verdacht war hier eben, dass hier die private IP-Adresse angezogen wird.


    Oder wie ist die Fehlermeldung zu verstehen?
    DNS check failed: DNS error: unknown/invalid IP(s) found in DNS


    Für mich war das ein Hinweis auf ein Abgleich zwischen DNS und konfigurierter Apache-IP-Adresse.
    Und in der Serverkonfiguration bei IP-Adresse wurde ja auch die private IP-Adresse angezogen und nicht die öffentliche.


    Das der Resolver falsche Daten geliefert hat, ist auch nicht ganz ausgeschlossen. Kann ich aber auch nicht mehr nachvollziehen.


    Ich bin aber ziemlich warscheinlich sowas von auf dem Holzweg und interpretiere es völlig falsch.
    Da ich keinen passenden Server mehr habe, kann ich es auch leider auch nicht mehr nachvollziehen.

    Zitat von TCRserver

    Aber gegen welche IP Adresse validiert LC es, also welche http-Server Adresse?


    Wenn LiveConfig ein automatisiertes SSL-Zertifikat für "example.org" einrichten soll, passiert Folgendes:


    • LiveConfig prüft, ob die Domain "example.org" überhaupt angelegt ist (also irgendein Vertrag mit dieser Domain existiert).
    • Wenn ja, dann wird geprüft, ob der zugehörige Kunde/Vertrag/Webspace auch aktiviert ist.
    • Wenn ja, dann sucht LiveConfig die IP-Adressen dieses Webspaces heraus (also die Adressen, mit denen effektiv die vHost-Konfiguration erzeugt wird).
    • dann macht LiveConfig eine "externe" DNS-Abfrage (sprich: nutzt den eingebauten Resolver oder - falls nicht möglich - den Resolver des Servers) um herauszufinden, mit welchen IPs denn der verantwortliche DNS-Server tatsächlich antwortet.
    • Zum Schluß wird abgeglichen, ob die Liste der tatsächlichen IPs mit der Liste der konfigurierten IPs (bzw. der NAT-IPs) übereinstimmt. Wenn nicht, dann gibt es eine entsprechende Fehlermeldung.


    Der durch LiveConfig durchgeführte DNS-Check hat mehrere Vorteile, u.a.:

    • sollte eine Domain falsch konfiguriert sein (die Klassiker: falsche IP-Adresse hinterlegt, Domain inzwischen umgezogen, Tippfehler im Domainnamen, ...) dann hat man gleich eine brauchbare Fehlermeldung
    • die Anzahl der ungültigen Domainvalidierungen bleibt somit gering, die Gefahr in Probleme seitens Let's Encrypt zu rauschen wird somit verringert.


    Viele Grüße


    -Klaus Keppler

    Zitat von lchel

    <ADDRESS> ist eine IPv6 Adresse. Der Server hat eine IPv4 und eine IPv6 Adresse. Wenn ich die IPv6-Adresse auf dem DNS lösche, funktioniert die automatische Verlängerung. Aber das ist nicht der wahre Jakob. Schließlich soll auch IPv6 funktionieren und hat auch bis vor ca. einem Monat funktioniert.


    Da wird es höchstwahrscheinlich eine Inkonsistenz gegeben haben.
    Am einfachsten Fall können Sie das prüfen, indem Sie im LiveConfig (als "Kunde") auf "Hosting" -> "Domains" gehen und dort die betroffene (Sub)Domain anklicken.
    Es öffnet sich das Popup mit den (Sub)Domain-Einstellungen. Dort wird angezeigt, mit welchen IP-Adressen die Domain im LiveConfig konfiguriert ist (über die entsprechenden IP-Gruppen). Eventuell war die IPv6-Adresse nicht in der gewählten IP-Gruppe enthalten.


    Zitat von lchel

    <ADDRESS> ist eine IPv4 Adresse und der Server ist eine AWS EC2 Instanz. <ADDRESS> ist die externe IP-Adresse des Servers, die aber naturgemäß nicht der lokalen IP des Servers entspricht.


    Das lässt sich über die LiveConfig-Datenbank (Tabelle IPS, Spalte IP_NAT) lösen. Wir werden das Verhalten mit LiveConfig v2.9 aber so ändern, dass bei erkanntermaßen "privaten" IPv4-Adressen kein DNS-Check mehr ausgeführt wird, sofern keine NAT-IP konfiguriert ist.


    Falls Sie aktuell noch Probleme haben, schicken Sie uns bitte mal einen betroffenen Domainnamen samt exakter Fehlermeldung an support@liveconfig.com, dann werfen wir da auch mal ein Auge drauf.


    Viele Grüße


    -Klaus Keppler

    Zitat von antondollmaier

    Kann der Post so ins Handbuch? ;)


    Hmm, guter Hinweis - ich gebe das gleich weiter.


    Zitat

    Und: danke für die Preview - auch wenn ich den Versions-Sprung auf 2.9 (im Vergleich zu den gravierenden Änderungen 2.7->2.8) nicht so ganz nachvollziehen kann.


    Mit v2.9 gab es auf unserer Seite gravierende Änderungen, u.a. haben wir die komplette Codeverwaltung von SVN auf Git umgestellt - an den Build-Prozessen hat sich also viel geändert. Details dazu plane ich nächste Woche (mit dem nächsten Preview-Update) ausführlicher zu beschreiben.
    Und 'n paar weitere nette Features stecken auch gerade in der Release-Pipeline für v2.9. ;)


    Viele Grüße


    -Klaus Keppler

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden