Automatische Erneuerung der LE-Zertifikate

    Wenn die automatische Erneuerung der LE-Zertifikate aus welchen Gründen auch immer fehlgeschlagen ist - versucht Liveconfig das dann später nochmal oder muss ich mich manuell drum kümmern?


    Hintergrund der Frage ist, dass ich hier eine Handvoll Zertifikate habe, die aus mir noch unbekannten Gründen nicht verlängert wurden - im ACME-Tab steht auch eine Fehlermeldung drin bzw. im liveconfig.log ebenfalls (das ist der Schwung von der DSGVO-"Panik" - ich hoffe nicht, dass das zuviele auf einmal waren, dann habe ich das Problem ansonsten alle 3 Monate.....


    Nun sind die Zertifikate noch fast 30 Tage gültig, es ist also noch genügend Zeit. Versucht Liveconfig die Erneuerung später nochmal, oder kann / sollte ich schon manuell tätig werden (ich habe eins mal getestet, einfach nochmal auf "speichern" klicken reicht)

    Zitat von aziegler

    was ist denn die konkrete Fehlermeldung?
    es gibt Fehler da hilft einfach erneut versuchen nichts ;)


    Naja, bei vielen (den meisten, würde ich sagen) hat es ja geklappt, manuell funktioniert es auch. Nur bei einigen wenigen ist da ein


    HTML
    Invalid response from http://domain.de/.well-known/acme-challenge/VKqmkl70BSwL40Rz63Wl3vwUdHFPqGsuRMsNsA8Xqac: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html "


    (domain.de ersetzt die eche Domain)


    Deswegen fürchte ich eine temporäre Überlastung (wobei es da kein anderes Anzeichen für gäbe, die Munin-Graphen z.B. sind in Ordnung und es gibt auch keine Einträge im Error-Log oder sowas) oder ein Timing-Problem oder sowas


    Wobei mir gerade auffällt, dass der HTML-Code, der sich da in der Fehlermeldung andeuet nicht von der fraglichen Domain stammt, da geht es anders los.

    Zitat von aziegler

    DNS-Einträge verändert worden? Domain umgezogen?


    Nene, die habe ich unter eigener Kontrolle ;) Die Homepage lässt sich ja auch normal aufrufen


    Es gibt aber einen korrespondierenden Eintrag im Apache-Error-Log - das HTML-Fragment dürfte von einem 404er stammen. Die ACME-Challenge wird nicht gefunden, dann geht es an der Stelle natürlich nicht weiter.


    Das wiederrum könnte damit zusammenhängen, dass in dem Web beinahe 3000 Domains sind - es dauert eine Weile die .conf-Datei zu schreiben (runde 3 Minuten, trotz SSD). Deswegen ist meine Vermutung ein Timing-Problem, vermutlich wird die Verifizierung versucht wenn die Konfiguration noch nicht verfügbar ist. Ich hab schon die Apache.MINLOAD und MAXLOAD-Werte angepasst bzw. deutlich höher gesetzt, der Dokumentation nach sollte das die LE-Verifizerung auch berücksichtigen, aber entweder das passiert nicht oder da ist noch ein anderer Faktor, auf den ich noch nicht gekommen bin

    Zitat von mhagge

    es dauert eine Weile die .conf-Datei zu schreiben (runde 3 Minuten, trotz SSD).


    Bitte? Da stimmt dann aber was mit der Hardware nicht...
    Wir fahren mit LiveConfig auch regelmäßig mal Lasttests mit >10.000 Domains in einem Vertrag, auch da dauert die Erstellung der .conf-Dateien keine Sekunde.
    Steht der Server vielleicht recht "unter Dampf"? Ein hoher I/O auf dem Server insgesamt wäre die enizige Erklärung, warum das so lange dauert.


    Zitat

    Deswegen ist meine Vermutung ein Timing-Problem, vermutlich wird die Verifizierung versucht wenn die Konfiguration noch nicht verfügbar ist.


    Nach dem Erstellen eines ACME-"Auftrags" werden automatisch ein CSR erzeugt sowie die ACME-Challenges beauftragt - das geschieht quasi in Echtzeit. Die Challenges werden anschließend in die Webserver-Konfigurationen übernommen und ein Reload angetriggert.
    Frühestens 90 Sekunden nach dem Aktualisieren der Konfigurationsdateien wird dann bei Let's Encrypt die Prüfung der Challenges angestoßen (der Apache-Reload findet ja "normalerweise" nach max. 60 Sekunden statt). Bei größeren Werten für RELOAD_MAX müsste das (wenn ich mich richtig erinnere) entsprechend auch höher sein (also RELOAD_MAX+30sek).
    In der Tat kann es dann also zu Timing-Problemen kommen, wenn der tatsächliche Reload entsprechend länger dauert. Wurde ein Challenge-Request mit einer endgültigen (also nicht temporären!) Fehlermeldung beantwortet, erfolgt keine automatische Wiederholung. In der Regel müsste es aber genügen, bei den Zertifikaten einfach erneut auf "speichern" zu klicken, dann müsste LC offene Challenges erneut anstoßen.


    Wir haben bereits einen Konfigurations-Prototypen entwickelt, mit dem die Challenges ohne Reload des Apache verwaltet werden können (während gleichzeitig sichergestellt ist, dass Challenges nur für die jeweiligen Domains erreichbar sind). In LiveConfig v2.7 werden wir das nicht mehr hinein bekommen, aber bis v2.8 (Herbst) sollte es fertig sein.

    Zitat von kk

    Bitte? Da stimmt dann aber was mit der Hardware nicht...
    Wir fahren mit LiveConfig auch regelmäßig mal Lasttests mit >10.000 Domains in einem Vertrag, auch da dauert die Erstellung der .conf-Dateien keine Sekunde.
    Steht der Server vielleicht recht "unter Dampf"? Ein hoher I/O auf dem Server insgesamt wäre die enizige Erklärung, warum das so lange dauert.


    Naja gut, er ist im laufenden Betrieb, aber hat eigentlich reichlich Reserven und mit den restlichen Systemdiensten gibt es auch keine Probleme - die .conf mit dem Web hat 12 MB Größe.


    Ein Apache-Reload dauert etwa 10 Sekunden. Ich hab mal ein Tempfile mit DD geschrieben:


    Code
    # dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 3,88818 s, 276 MB/s


    Nicht überragend, aber auch nicht grottig schlecht würde ich sagen.


    Warum hier 1 GiB keine 4 Sekunden dauert, die web.conf von Liveconfig mit 12 MB Größe aber solange braucht wüsste ich allerdings auch gerne ;) Wie könnte man das genauer eruieren bzw. wo könnte da ein Ansatz für eine Bremse sein?

    /.well-known/acme-challenge/VKqmkl70BSwL40Rz63Wl3vwUdHFPqGsuRMsNsA8Xqac


    Ordner und Datei auf dem ftp vorhanden?


    Oder eine Permanente Weiterleitung unter Domains gestellt?


    Wenn z.B Domain.d auf http://www.domain.de weiterleitet kommt es auch zu diesem Fehler wie ich feststellen musste.


    Mein Problem, alles leitet auf https weiter :


    domain.de -> https://domain.de
    http://www.domain.de -> https://domain.de
    https://www.domain.de -> https://domain.de


    und dadurch kann das Zertifikat nicht verifiziert werden da LE unter domain.de sucht und nicht mit https. ;)


    Hoffe du verstehst was ich meine.


    Gruß WU

    >> Manchen gab Gott die Kraft Dinge zu verändern, mir gab er die Kraft zu ertragen was ich nicht ändern kann! <<

    Das geht doch an der Weiterleitung vorbei. Vereinfacht gesagt wird alles weitergeleitet ausser die Challenge. Die Weiterleitung spielt also keine Rolle.

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

    Bei mir nicht.
    Ich muss jedes mal die Weiterleitung auf https weg nehmen damit ich die Zertifikate aktualisieren kann.


    Gruß WU

    >> Manchen gab Gott die Kraft Dinge zu verändern, mir gab er die Kraft zu ertragen was ich nicht ändern kann! <<

    Debian 9. Mit apache. Zertifikate mache ich aber über console da nur Grund Version von liveconfig und nutze Wildcard zertifikate.


    Gruß WU

    >> Manchen gab Gott die Kraft Dinge zu verändern, mir gab er die Kraft zu ertragen was ich nicht ändern kann! <<

    Meinst du die Basic-Version? Die unterstützt automatisiertes LE nicht. So wie ich KK verstanden habe ist das auch nicht vorgesehen. Das wurde hier schon öfter besprochen.

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

    Die "Überbrückung" der Weiterleitung macht ja Liveconfig, wenn ich das richtig sehe - insofern kann das mit der Basic-Version wohl so auch nicht klappen (evtl. wenn man manuell eine "Dauerausnahme" für die ACME-Konfigurations-URL in die Apache-Config schreibt, das müsste eigentlich gehen).


    Das ist aber hier auch nicht das Problem, ich kann mir die ACME-Bestätigungs-URLs wenn ich sie mir aus dem Protokoll rauskopiere sogar manuell aufrufen. Nur im Moment der Verifizierung klappt das anscheinend manchmal nicht. Ich habe jetzt die RELOAD-Zeiten enorm hochgestellt ("min" auf 500), da sich da ausser den SSL-Zertifikatsverlängerungen nicht groß was ändert ist die Verzögerung akzeptabel, seit dem ist das Problem nicht mehr aufgetreten - obwohl ich mir das nach der Erklärung von Herrn Keppler so recht nicht erklären kann. Schaun wir mal.

    Ich denke, ich weiß inzwischen wie das Problem entsteht. Und zwar passiert es immer dann, wenn Liveconfig viele Zertifikate auf einmal erneuern will - dann kommt es zu Timing-Problemen.


    Das "Problem" ist, dass Liveconfig für jede einzelne Änderung die webx.conf neu schreibt. Pro SSL-Zertifikat sind das 2 Änderungen (einmal für die Domain mit www und einmal für die ohne). Werden jetzt z.B. 10 Zertifikate auf einmal erneuert dauert es bei einer "Schreibezeit" von 2-3 Minute pro webx.conf also minimum 20 Minuten, eher mehr, bis der Apache sämtliche für die Veränderung erforderlichen Config-Änderungen überhaupt erst zur Verfügung hat. Selbst mit meinem deutlich verlängerten RELOAD.min bzw. RELOAD.max fallen dann welche hintenrüber, weil bei den Domains die Konfiguration für das ACME-Challenge halt noch nicht geschrieben ist.


    Ich könnte nun also entweder die Zeit nochmal deutlich verlängern (das würde theoretisch gehen, an der Config ändert sich ansonsten so häufig auch nichts, nur halt gerade dann ist es nervig so lang warten zu müssen), ich könnte einstellen, dass nie mehr als 2-3 Zertifikate auf einmal verlängert werden (das geht aber IMHO derzeit nicht) oder aber Liveconfig müsste dazu gebracht werden, die Config nicht für jede Änderung neu schreiben zu müssen (bei manuellen Änderungen kann ich das ja nachvollziehen, dass das erforderlich ist, aber bei solch Dingen wie Zertifikatsverlängerungen weiß LE doch dem Grunde nach, dass da jetzt x Änderungen aufeinmal kommen - warum werden diese Änderungen dann nicht auch auf einmal in die Config geschrieben?)


    Daneben suche ich noch einen Weg, die Apache-Config zu verschlanken - ich nutze Liveconfig nur als Verwaltungs-Tool für mich selber, aus der Config könnte also allerhand entfernt werden, weil ich es gar nicht nutze (die Einträge für mod_php z.B. oder mod_compat und was da sonst noch so standardmäßig drin ist). Ich vermute mal damit liesse sich das Problem auch deutlich entschärfen. Vermutlich muss ich dafür irgendeine .lua-Funktion überschreiben, nur geht das ohne Nebenwirkungen?

    Zitat von mhagge

    [...] dauert es bei einer "Schreibezeit" von 2-3 Minute pro webx.conf also minimum 20 Minuten, eher mehr,[...]


    Da scheint mir an dem System eher grundsätzlich etwas nicht zu stimmen. Eine komplette vHost-Konfiguration ist üblicherweise in wenigen Millisekunden komplett geschrieben, auch wenn die mehrere MB groß ist.


    Verwenden Sie SQLite oder MySQL als Backend-Datenbank für LiveConfig?
    Wie viele VirtualHost-Abschnitte enthält eine Apache-Konfiguration bei Ihnen?

    Hallo Herr Kepler,


    Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf


    Die SSD hatte ich neulich ja schon mal getestet, zwar nicht überragend, aber auch nicht Mega-schlecht (und auf jeden Fall deutlich schneller als eine HDD) - an der sollte es also nicht liegen. Woran könnte es noch liegen?


    Mir fällt ansonsten gerade noch auf, dass im /conf/acme-Verzeichnis fast 13000 Dateien sind - muss das so sein?

    Zitat von mhagge

    Hallo Herr Kepler,
    Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf


    Als Ergänzung: 4 Kerne Intel CPU (also 8 virtuelle Kerne) und 36 GB Speicher. Das System rennt ansonsten wie eine 1, keinerlei Probleme mit Geschwindigkeit oder Auslastung (die Domains gehören zu einem Webbaukasten-System, welches ich hoste. Dessen Datenbanken sind allerdings auf einem anderen Server, nicht auf dem gleichen, dort ist nur "Web") - nur eben halt an dieser einen Stelle hakelt es.

    Zitat von mhagge

    Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf


    Wir werden mal ein Testsystem aufsetzen und versuchen das zu reproduzieren (inkl. ACME-Zertifikate). Dauert aber vermutlich 2-3 Tage, bis wir soweit sind.


    Zitat

    Die SSD hatte ich neulich ja schon mal getestet, zwar nicht überragend, aber auch nicht Mega-schlecht (und auf jeden Fall deutlich schneller als eine HDD) - an der sollte es also nicht liegen. Woran könnte es noch liegen?


    Auf den ersten Blick vermute ich, dass irgendeine SQL-Abfrage, die zum Aufbau der vHost-Konfiguration verwendet wird, langsam ist. Eine "durchschnittliche" vHost-Konfiguration hat ja nur eine überschaubare Zahl an VirtualHosts, daher fällt es meistens nicht auf wenn vielleicht ein Datenbankindex fehlt.


    Zitat

    Mir fällt ansonsten gerade noch auf, dass im /conf/acme-Verzeichnis fast 13000 Dateien sind - muss das so sein?


    Sie können alle alten ACME-Authz problemlos löschen:

    Code
    find conf/acme -type f -mtime +30 -delete


    Ich dachte eigentlich dass LiveConfig das erledigt, werden wir prüfen...

    Zitat von kk


    Auf den ersten Blick vermute ich, dass irgendeine SQL-Abfrage, die zum Aufbau der vHost-Konfiguration verwendet wird, langsam ist. Eine "durchschnittliche" vHost-Konfiguration hat ja nur eine überschaubare Zahl an VirtualHosts, daher fällt es meistens nicht auf wenn vielleicht ein Datenbankindex fehlt.


    Das könnte hinkommen - mysqltuner beschwert sich über eine hohe Zahl von "Joins performed without indexes" und schlägt vor, das zu optimieren

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden