Das werden wir uns mal anschauen - eigentlich darf pro TLS-Auftrag nur ein Eintrag in der SSLFILEAUTH pro Zertifikat existieren. Das betraf alles noch LiveConfig 2.x, korrekt?
Korrekt, die "Aufräumarbeiten" waren alle unter LC2. Dass das ein gewisses Risiko war, war mir bewusst – aber wie es so ist, wenn man erst mal angefangen hat. Ich hatte aber ein "Brandaktuelles" Backup, ohne hätte ich das auch nicht gemacht
Das mache ich auch - nur ein paar 100 SSL-Zertifikate auf diesem Wege zu überwachen ist logistisch schwierig 
Ich habe es jetzt hinbekommen, LC3 scheint reibungslos zu laufen.
Falls jemand das gleiche Problem hat (aktuelles Backup empfiehlt sich selbstverständlich):
Mir fiel im Log (von LC2) auf, dass regelmäßig für eine Domain neue Validierungsdateien angelegt und wieder gelöscht werden (und dass 100te von Malen) - ohne dass was passiert und ohne dass das entsprechende LE-Zertifikat zur Verlängerung anstehen würde. Dann habe ich mir mal die Datenbank angeschaut, dass in der Tabelle SSLFILEAUTH in der Tat 100te Einträge zu dieser Domain vorhanden sind. Ich habe die Tabelle daraufhin geleert, das Problem hörte damit auf (vermutlich hat irgendwo mal was gehakt und LC2 hat sich weiter nicht dran gestört).
Mag sein, dass das für LC3 schon gereicht hätte, aber da hier ja auch der Hinweis auf mehrere LE‑Accounts war und da bei mir 2 davon existierten, habe ich die Domains vom 2. LE-Account auf den ersten LE-Account "umgezogen" (ergo SSL-Zertifikat gelöscht und wieder neu mit "richtigem" Account ausstellen lassen). Das waren bei mir "nur" 14, also überschaubar (ich weiß gar nicht mehr, warum ich diesen 2. Account überhaupt angelegt habe).
Die SSL-Accounts findet man in der Tabelle SSLACCOUNTS, die betroffenen Domains unter SSLCERTS - SA_ID von SSL-Accounts entsprechen der SSL_PRODUCTID in SSLACCOUNTS, darauf also filtern ergibt die Domains, die über den entsprechenden Account laufen.
Nachdem alle Domains umgestellt waren (vorsichtig, nicht zu schnell hintereinander löschen und wieder neu ausstellen lassen, das führt zu Fehlermeldungen), habe ich dann noch den überflüssigen LE-Account gelöscht (die entsprechende Reihe in der DB in SSLACCOUNTS löschen, eine Menüfunktion dazu scheint es nicht zu geben).
Anschließend LC3 installiert. Bis jetzt läuft es reibungslos, keine komischen Fehlermeldungen zu laufenden TLS-Jobs mehr, ich habe schon Zertifikate neu ausstellen lassen und die ersten Verlängerungen sind auch problemlos durchgelaufen.
Moin,
mit neuem Anbieter hatte ich das probiert - ohne Erfolg.
Rückmeldung kann es bei mir insofern nicht geben, als dass ich nicht direkt gemailt hatte. Die Domain musste / sollte gestern Abend funktionieren, insofern hatte ich da keine große Wahl, als zu hoffen, dass es dann mit LC2 geht (was dann ja auch problemlos geklappt hat).
Ob es wirklich problemlos funktioniert – ich würde da empfehlen, sehr genau hinzuschauen. Dass LC3 (von der Menge her müssten es alle seit der Umstellung auf LC3 gewesen sein) die LetsEncrypt-Zertifikate nicht verlängert hat, wird dort in der Oberfläche nirgends angezeigt, das habe ich erst mit der Rückstellung auf LC2 dort in der Oberfläche gesehen – und die Umstellung ist halt hier auch bisher nicht so lange her, als dass da schon eins wirklich ausgelaufen gewesen wäre. Insofern: Ich war auch davon ausgegangen, dass soweit alles problemlos läuft, weil halt nirgendwo ein Problem angezeigt wurde.
Ich habe aber definitiv auch nach der Umstellung auf LC3 neue LetsEncrypt-Zertifikate erfolgreich beziehen können. Wenn es jetzt nicht bei dieser einen Domain, warum auch immer, nicht geklappt hätte, wäre mir das vermutlich erst aufgefallen, wenn die ersten LE-Zertifikate aufgrund fehlender Verlängerung tatsächlich ausgelaufen wären... Möglicherweise also ein Problem, was sich erst mit irgendeinem .-Update eingeschlichen hat, wobei ich, wie gesagt, bei Verlängerungen ziemlich sicher bin, dass die mit LC3 bei mir jedenfalls noch nie funktioniert haben.
Viele Grüße
Markus
Alles anzeigenHabe jetzt mit der aktuellen Version 3.0.3 unter Debian bookworm folgendes Problem mit den Zertifikaten.
Die automatische Verlängerung von Liveconfig hat nun bei den zu verlängernden Zertifikaten den Job doppelt angelegt.
Das führt zu dem Fehler das die Verlängerung nicht ausgeführt wird und in der liveconfig.log folgender Fehler protokoliert wird.
CodeAlles anzeigen[3519098] [2025-08-26 12:36:54.077276] [INFO] [LUA] Detected 'Debian GNU/Linux 12 (bookworm)' [3519097] [2025-08-26 12:37:52.503274] [EMERG] Uncaught exception in ChildManager: tlsjob already exists [3519097] [2025-08-26 12:37:52.503314] [EMERG] Got exception: WebSession::AuthRequiredException [ 0] 0x177fab [ 1] 0x274d48 [ 2] 0xf7d05 /usr/lib/liveconfig/libk.so.0.9 [ 3] 0x125eca /usr/lib/liveconfig/libk.so.0.9 [ 4] 0x3b0ac0 [ 5] 0xd44a3 /lib/x86_64-linux-gnu/libstdc++.so.6 [ 6] 0x891f5 /lib/x86_64-linux-gnu/libc.so.6 [ 7] 0x10989c /lib/x86_64-linux-gnu/libc.so.6
Selbiges Problem hier auch – bis auf dass der Job hier nicht doppelt angelegt wird. Das Bild im Liveconfig.log ist aber das gleiche.
Domain neu abspeichern, SSL-Zertifkat neu abspeichern, Liveconfig neu starten, Server neu starten - nichts hilft.
Neu austellen von Zertifikaten hat aber auch mit Version 3 definitiv schon geklappt – ob Verlängerung auch kann ich nicht sicher sagen, denn:
Ich wusste mir jetzt nicht weiterzuhelfen, zumal ich schnell eine Lösung brauchte – also bin ich zu LC2 zurück.
Dort ist jetzt eine relativ lange Liste von SSL-Zertifikaten, die nicht verlängert wurden – die scheint LC2 gerade abzuarbeiten, wenn ich mir die liveconfig.log so anschaue
Irgendwo steckt da aber mit LC3 und LetsEncrypt noch ziemlich der Wurm drin, befürchte ich
Hallo
hast du mal die Konfigurationen neuschreiben lassen?
Laufen alle Dienste?
Vielen Dank! Nein, das war es nicht. mod_security war der Übeltäter 
in die .httpd-conf des betreffenden Webs
<IfModule security2_module>
SecRuleEngine Off
</IfModule>eintragen, dann funktioniert alles.
Hallo zusammen,
Ich habe Liveconfig mit "LetsEncrypt-Proxy" nach diesem Muster eingerichtet: https://www.liveconfig.com/en/kb/liveconfig-lets-encrypt/ und nun das Update LC2 -> LC3 durchgeführt.
Das funktioniert auch so weit, ich kann mich mit LC3 einloggen und es werden auch alle Informationen (Domaineinstellungen etc.pp) angezeigt.
Allerdings kann ich keinerlei Änderungen vornehmen, egal was ich ändern will (ob jetzt an den Einstellungen von Liveconfig, oder an Domains etc.) kommt immer eine kleine Meldung "No JSON response from server" und die Änderung wird nicht gespeichert.
Mache ich das gleiche allerdings ohne Proxy (also Aufruf über Port 8443) klappt alles reibungslos, alle Änderungen werden gespeichert.... Wäre jetzt nicht so dramatisch, weil ich der einzige Nutzer bin, aber wundern tut es mich schon (zumal ich einen 2. Server umgestellt habe, wo alles reibungslos funktioniert, auch mit Proxy - und ich kann partout keinen Unterschied zwischen der Serverkonfiguration erkennen)
Im liveconfig.log steht da nichts zu. Hat jemand evtl. eine Idee, woran das liegen könnte
Viele Grüße
Markus
Ich glaube, das geht sowieso am Thema vorbei. Eine Kündigungsmöglichkeit im Webhosting-Panel wäre zwar nett für den Kunden, geht aber am Thema vorbei und ist nicht das, was mit dem (seit 1.7. schon) verpflichtenden Kündigungsbutton gemeint ist - der darf sich nämlich nicht hinter einem Login verstecken, sondern muss öffentlich erreichbar sein. Ganz grob also ein Formular mit einem weitgehend vorgegeben Inhalt, dessen Empfang umgehend bestätigt werden muss
Details z.B. https://datenschutz-generator.de/kuendigung-button/
Das Problem scheint mir zu sein, dass LetsEncrypt "ISRG Root X1" weiterhin mit ausliefert (neben dem R3), wenn auch als abgelaufen. Da z.B. ältere Android-Geräte das nicht prüfen, ist da die Kompatibilität weiterhin gegeben.
Neuere Clients sollten in der Theorie wenn sie bemerken dass ISRG Root X1 abgelaufen ist auf R3 zurückgreifen, so dass da kein Problem entsteht. In der Praxis passiert das scheinbar nicht in jedem Fall
Kann ich bestätigen - hier war nur " 8d33f237.1 " vorhanden, nach dem löschen hat es tatsächlich wieder geklappt
Auf einem zweiten Liveconfig-Server (beides gleicher Versionsstand, von Liveconfig wie auch Debian) gab es allerdings überhaupt keine Probleme :confused:
Der Titel sagt dem Grunde nach schon alles
Ich lege Domains per API an (das klappt auch wunderbar) und würde gerne für diese Domains LetsEncrypt gleich mit beantragen / einrichten (dazu muss ich mich bislang dann doch wieder in die Liveconfig-GUI einloggen).
Nun gibt es ja seit einiger Zeit durchaus Methoden in der API dazu, z.B.
https://www.liveconfig.com/de/…ce.HostingDomainAdd.xhtml
Allerdings geht das ja davon aus, dass man man den Key, das Zertifikat und evtl. Zwischenzertifikate mit übergibt. Damit komme ich aber ja via LE so gar nicht in Berührung (und via API dass dann abrufen und wieder zu übergeben geht auch nicht, würde aber ja auch spätestens bei einer Verlängerung Probleme geben).
Insofern: habe ich da was übersehen oder gibt es da tatsächlich derzeit keinen Weg? Ich stelle mir ja einfach einen Schalter "le = true" oder sowas in der Parameterliste vor.
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
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:
Hier das gleiche Problem - doppelte Bestellungen liegen ebenfalls nicht vor
Ich tippe mal darauf, dass /tmp mit dem Flag "noexec" gemountet ist?
Da wird es dann auch bei anderen Paket-Updates krachen.
noexec - In der Tat, warum auch immer.... Vielen Dank!
Bei mir (aktuelles Debian 9) kommt nach dem apt-get upgrade da ein
ZitatCan't exec "/tmp/liveconfig.config.IHxnTX": Keine Berechtigung at /usr/share/perl/5.24/IPC/Open3.pm line 178.
open2: exec of /tmp/liveconfig.config.IHxnTX configure 2.7.2-r5133 failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
Funktionierend (zumindestens das sichtbare) tut es aber anscheinend, Liveconfig lässt sich aufrufen und benutzen
Ah, ok - wohl das hier: https://www.liveconfig.com/de/…6667&viewfull=1#post16667
Irgendwas scheint beim Update auf 2.7.1 kaputt gegangen zu sein..
Ich erhalte beim anlegen einer Sub-Domain immer (egal was ich eingebe, selbst mit dem simplen "www") die Fehlermeldung "Ungültiger Subdomain-Name")
Das gleich passiert auch, wenn ich eine bestehende Sub-Domain bearbeiten will
Naja, aber so ein abgelaufenes Zertifikat da zu haben ist auch unschön - ausserdem ist "opportunistisches HTTPS" manchmal ja auch nützlich.
Soweit klappt das auch - nur der Schritt 4 (abspeichern) klappt nicht und da könnte ich mir vorstellen besteht sogar ein Allgemeineres Problem - das neue "Zertifikat" wird erzeigt, lässt sich aber nicht abspeichern - in der liveconfig.log steht dann
ZitatUnknown CGI variable 'comment' -> always call initForm() before checkForm()!
Ich glaube das geht um das Default Server-Zertifikat für SSL für den Webserver - steht in der Liste der SSL-Zertifikate mit der Bemerkung "Default SSL-zertifikat für SNI"
Bei mir läuft das demnächst auch aus, insofern würde mich das auch interessieren Zumal (bei mir ist es Debian)
sudo make-ssl-cert generate-default-snakeoil --force-overwrite
und anschließendes Neustarten von Liveconfig und Apache an diesem Zeritfikat irgendwie nichts geändert hat, das steht da immer noch mit Ablaufdatum Anfang Dezember.
Preview wurde auf v2.7.0-r5076 aktualisiert, da stimmt die SSL-Zuordnung wieder.
Wir haben die Erzeugung der vHost-Konfigurationen massiv optimiert - in einem Testfall mit 3000 vHosts in einem einzelnen Vertrag (ca. 15 MB Konfigurationsdatei) dauert das aktuell nur noch 5 Sekunden statt vorher tatsächlich einigen Minuten.
Super, das freut mich! 