Startseite » Forum » LiveConfig-Foren (deutsch) » Let's Encrypt » Lets Encrypt mit IPv6 oder AWS EC2
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15
  1. #1
    Neuer Benutzer
    Registriert seit
    02.06.2014
    Beiträge
    13

    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.

  2. #2
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    729
    Zitat Zitat von lchel Beitrag anzeigen
    [*]<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.

    <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.

    Auch das hat bis vor ca. einem Monat problemlos funktioniert.
    Ggf. seit dem Update auf LiveConfig 2.8?

  3. #3
    Neuer Benutzer
    Registriert seit
    02.06.2014
    Beiträge
    13
    Zitat Zitat von antondollmaier Beitrag anzeigen
    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.

  4. #4
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    729
    Zitat Zitat von lchel Beitrag anzeigen
    Wie konfiguriere ich denn dann IPS.IP_NAT?
    Siehe hier im Forum: https://www.liveconfig.com/de/forum/...ll=1#post17669

  5. #5
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    111
    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.

  6. #6
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.362
    Ö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

  7. #7
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    111
    @KK Sry für den Schock am Morgen

    Aber:
    https://www.liveconfig.com/de/forum/...ll=1#post17736

    Bei uns kam bei allen NAT Servern, permanent ein "DNS check failed: DNS error: unknown/invalid IP(s) found in DNS".

  8. #8
    Erfahrener Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    111
    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.

  9. #9
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.362
    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

  10. #10
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.362
    Zitat Zitat von TCRserver Beitrag anzeigen
    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.

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •