SSL-Probleme seit gestrigem Update

    Ich denke wir brauch hier keine weitere Diskussion.


    Im vorliegenden Fall war zum Zeitpunkt der SSL-Bestellung noch die alte IP (.42) im DNS hinterlegt. LiveConfig prüft seit v2.8.0 die DNS-Einträge - hat hier also einen Fehler festgestellt (erwartet wurde die .45). Die DNS-Daten werden bislang aber durch die von LiveConfig verwendete Resolver-Software (unbound) gecached. Da die falsche Antwort mit einem TTL von 24 Stunden ausgeliefert wurde, hing die "alte" Antwort also entsprechend lange in LiveConfig fest.
    Das war und ist also kein Fehler in LiveConfig, sondern schlicht eine seeehr ungünstige Domainkonfiguration.


    In LiveConfig v2.8.1 werden DNS-Antworten nur noch maximal für 60 Sekunden gecached - damit können SSL-Bestellungen also sofort fortgesetzt werden, nachdem die DNS-Daten aktualisiert wurden.
    Dass der Endkunde bei einem Umzug mit großen TTL-Werten (egal ob 3 oder 24 Stunden) ganz andere Probleme hat, habe ich nun auch schon oft genug erklärt - das liegt aber außerhalb des Einflussbereichs von LiveConfig.

    So, ich antworte mir selbst einmal :)


    Ich habe nun die NAT-IPs (externe IPs) als zusätzliche IP-Adressen unter /etc/network/interfaces konfiguriert.
    Danach konnte ich diese IP-Adressen in der Serververwaltung den IP-Gruppen von Apache und NGINX zuordnen. Die internen IP-Adressen habe ich zuvor in den IP-Gruppen deaktiviert.


    Schlussendlich war dann die anschließende Zertifikatsbeantragung und -ausstellung über Lets Encrypt eine Sache von wenigen Sekunden, nachdem ich die bereits gestellten Zertifikatanforderungen gelöscht und nochmals neu angelegt hatte.


    Grüße
    Feuernatter

    Zitat von Feuernatter

    Ich verwende LiveComnfig noch nicht so lange, daher nun meine Frage:
    Wo finde ich diese Tabelle IPS?


    In der LiveConfig-Datenbank. Standardmäßig läuft diese mit "SQLite", liegt dann unter /var/lib/liveconfig/liveconfig.db (zum Bearbeiten das Paket "sqlite3" installieren - aber IMMER vorher ein Backup machen!)


    [quote[Wenn ich das richtig verstanden habe, müssen die öffentlichen IPs nach einer Eintragung in dieser Tabelle nicht mehr direkt am Interface konfiguriert werden. Ist das so richtig?[/QUOTE]


    Exakt.


    Da es diese Rückfragen (aufgrund NAT) inzwischen häufiger bei uns gab, werden wir das mit einem der kommenden Updates direkt in die Oberfläche integrieren.

    Zitat von kk

    Da es diese Rückfragen (aufgrund NAT) inzwischen häufiger bei uns gab, werden wir das mit einem der kommenden Updates direkt in die Oberfläche integrieren.


    Das wäre und ist natürlich die allerbeste Lösung :)
    Eine direkte Bearbeitung ist mir dann doch ein wenig "zu heikel" - Backup hin, Backup her.
    Nachdem die Lösung mit der direkten Konfiguration der IPs am Interface für mich funktioniert, würde ich auf eines der nächsten Updates warten.


    kk:
    Ich finde es super, dass Sie hier direkt auf Kundenwünsche eingehen und diese dann bei entsprechender Nachfrage auch zeinah umsetzen.

    Es gibt wahrlich wichtigeres als dies in die Weboberfläche zu bringen.


    "Eine direkte Bearbeitung ist mir dann doch ein wenig "zu heikel" - Backup hin, Backup her."
    Wer dies nicht beherrscht sollte imho keinen Server betreiben.

    # Das Gras wächst nicht schneller wenn man daran zieht # Bitte keine inflationären Vollzitate #

    Zitat von lebenszeit

    Wer dies nicht beherrscht sollte imho keinen Server betreiben,


    Sehr geehrte(r) Herr/Frau Lebenszeit,


    vielen Dank für Ihren produktiven Beitrag zu diesem Thema. Ihre Meinung hierzu respektiere ich. Allerdings möchte ich hierzu anmerken:


    Von einem Support-Forum und dessen Mitgliedern erwarte ich ein wenig mehr kooperatives und gemeinschaftliches Verhalten. Ihr Beitrag trägt innerhalb der geführten Diskussion nicht zur Lösung des Sachverhaltes bei.


    Wenn Sie sich über den Kenntnisstand und Kompetenz Anderer eine Meinung erlauben, ohne diesen selbst zu kennen, vermitteln Sie nicht gerade den Eindruck einer bei Ihnen vorhandenen Kompetenz, sondern eher von einer tatsächlich vorhandenen Überheblichkeit.


    Ihrer Signatur ist in jedem (!) Ihrer Beiträge zu entnehmen, dass Vollzitate die Lesbarkeit der Threads erschweren. Gerade hier sollten Sie sich - bei einer Tasse Kaffee oder Tee im stillen Kämmerlein - die Frage stellen, ob die dauerhafte Wiederholung einer immer gleichen Aussage die von Ihnen selbst so betonte Lesbarkeit erhöht. Gleiches gilt - meiner Meinung nach - auch für Ihren gesamten gehalt- und sinnvollen Beitrag.


    Mit freundlichen Grüßen
    Feuernatter

    Hallo


    seid der Version 2.8.3 RXXXX werden keine Let´s Encypt Zertifikat mehr verlängert.


    OS: Debian 10.1


    LiveConfig: 2.8.3 r5651 (Business Server mit MySQL Backend)


    Fehlermeldung:


    [2019/09/28 12:11:28.126780] [13309|13366] Database exception: Table 'LIVECONFIG.SSLCERT' doesn't exist


    Die Datenbank ist auch nicht vorhanden, nur die Datenbank SSLCERTS!


    Mit freundlichen Grüßen
    Martin Krüger

    Danke für den Hinweis.
    Der o.g. Fehler tritt auf, wenn eine identische Bestellung für das selbe SSL-Zertifikat vorliegt. Prüfen Sie daher mal die Log-Meldung und die Liste der SSL-Zertifikate, ob es "doppelte" Aufträge gibt.
    Wir werden den Fehler der o.g. Meldung kurzfristig beheben.


    Viele Grüße


    -Klaus Keppler

    Und ich stelle gerade fest, dass sich der Fehler heute morgen von alleine behoben haben muss - wöchentlich laufender Cronjob oder sowas? Ich hatte tagelang eine ziemlich lange Liste von laufenden SSL-Aufträgen in der GUI und im Liveconfig-Log war die Fehlermeldung, die von Martin Krüger beschrieben wurde. Heute morgen scheint sich das warum auch immer aufgelöst zu haben, keine entsprechende Fehlermeldung mehr im Log, die Liste im GUI ist leer und die Zertifikate wurden anscheinend nun auch alle verlängert.


    Ich hab weiter nichts gemacht, keinen Dienst oder gar den Server neugestartet :confused:

    Das ist ein nagelneues Feature in LiveConfig. Automatische Problembehebung (Feenstaub und so...).


    ;)


    Spaß beiseite. Die eigentliche Ursache für die o.g. Fehlermeldung ist, dass bei Let's Encrypt für die selben Domains mehrere Aufträge existiert hatten. Ab der ACMEv2-API fasst LE diese Aufträge automatisch zusammen, was bei LiveConfig bis dahin aber zu einem Problem geführt hatte (LiveConfig ging davon aus, dass es sich um verschiedene Aufträge handelte).
    In Ihrem Fall werden die offenen Bestellungen einfach abgelaufen (expired) sein, und somit konnten die Bestellungen "ganz normal" (neu) abgearbeitet werden.

    Das Feature gefällt mir zwar - aber: das betraf bei mir mehrere duzend LE-Zertifikate, und ich bin der einzige der auf dem Server dazu was einstellt. Was auch immer die Ursache war - doppelte Aufträge sehr sicher nicht, in dem Umfang müsste ich das wissen ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden