Froxlor 0.10.20 neue Domain anlegen, SSL voreingestellt

[df8oe]

Das Neuanlegen einer Domain führt jetzt oft dazu, dass der Webserver nicht mehr startet.

 

Wie kommt das zu Stande?

Beim Neuanlegen einer Domain wird, wenn in den Webserver-Grundeinstellungen SSL enabled ist, in der Sektion "Webserver SSL-Einstellungen" bei "Aktiviere Nutzung von SSL:" generell ein Haken gesetzt. Bei "SSL Zertifikat erstellen (Let's Encrypt):" ist dagegen kein Haken gesetzt. Das führt dazu, dass beim nächsten Cron-Lauf die Konfiguration so geschrieben wird, dass von einem lokal vorhandenen Zertifikat ausgegangen wird. Das ist aber nicht vorhanden - und damit startet der Webserver nicht mehr.

Dieses Verhalten war nicht immer so - erst seit einiger Zeit laufen mehr und mehr Nutzer in diese "Falle". Wer ein wenig Kenntnisse von der Konsole hat und einen ssh-Zugriff, kann sich leicht selbst helfen. Das hat aber nicht jeder...

Lösungsvorschlag:

- SSL wird nicht generell aktiviert. Ich glaube das war bis vor ??? auch der Default

oder: Wenn SSL aktiviert wurde wird überprüft, ob der Haken bei Letsencrypt auch gesetzt ist ODER ein Zertifikat existiert. Wenn nicht, wird die Aktivierung von SSL nicht ausgeführt und eine Warnung angezeigt

LG

DF8OE

[d00p]

Das is so nicht korrekt nein. Du hast 3 Stellen an denen Zertifikate möglich sind. Systemweit, auf Basis der IP und auf Basis der Domain. IP ist Fallback wenn es für die Domain keins gibt und System ist Fallback wenn es für die IP keines gibt. Gibt es egal wie keins deaktiviert froxlor automatisch den SSL-Vhost. 

[df8oe]

Leider wird der Vhost bei drei unterschiedlichen Server nicht deaktiviert.  Es wird ein Vhost angelegt dessen Zertifikat in /etc/ssl/apache/apache.crt / /etc/ssl/apache/apache.key liegen soll. Da liegt aber keines (es gibt noch nicht mal den Ordner /etc/ssl/apache) und das wars dann mit dem Webserver...
 

[d00p]

Stell doch bei solchen Meldungen bitte auch logs und deine configs bereits, nur "das wars dann mit dem Webserver" ist wirklich wenig hilfreich

[df8oe]

Hier die beiden relevanten Zeilen aus der erstellten ssl-Vhost-conf:

  SSLCertificateFile /etc/ssl/apache/apache.crt
  SSLCertificateKeyFile /etc/ssl/apache/apache.key
 

Ich habe es vermieden die gesamte conf zu posten da das Unkenntlichmachen der 30 für dieses Problem absolut irrelevanten Stellen sinnlos Arbeit erzeugt. Der Knackpunkt wurde klar beschrieben:

Es ist default "SSL aktivieren" ausgewählt. Es gibt kein systemweites oder IP-basiertes Zertifikat. Letsencrypt ist nicht angehakt. Dann erstellt Froxlor einen ssl-Vhost mit den oben aufgeführten Zeilen und startet den Webserver neu. Der Start des Webservers schlägt fehl weil die Zertifikatsdateien (oben aufgeführt) nicht exitieren - ein Zugriff via Web ist ab sofort nicht mehr möglich. Einzige Lösung ist den ssl-Vhost via Konsole zu löschen, dann den Webserver neu zu starten (dann startet er natürlich), dann via Froxlor die betreffende Domain zu bearbeiten und entweder den Haken bei "aktiviere SSL" rauszunehen ODER einen Haken bei "Letsencrypt" zu setzen.

[d00p]

Also /etc/ssl/apache/apache.crt existiert definitiv nicht auf deinem system ja? Ganz sicher? Eigentlich prüft froxlor die existenz und wenn nicht vorhanden nutzt er es auch nicht, genau aus dem grund

[df8oe]

Bei Arch Linux gibt es keine Ordner oder Dateien die mit"apache*" benannt sind. Die haben alle ein "http*" im Namen - ganz sicher. Es gibt weder einen Unterordner "apache" noch irgendwo Zertifikatsdateien die mit "apache" benannt sind.

[d00p]

Es ist ja auch eine EINSTELLUNG die du anpassen musset auf dein system...Weiss halt nicht was ich sagen soll, froxor prüft für den ip/port vhost hier https://github.com/Froxlor/Froxlor/blob/master/lib/Froxlor/Cron/Http/Apache.php#L418 und für die kunden domains an verschiedenen stellen (z.B. https://github.com/Froxlor/Froxlor/blob/master/lib/Froxlor/Cron/Http/Apache.php#L465 und https://github.com/Froxlor/Froxlor/blob/master/lib/Froxlor/Cron/Http/Apache.php#L955) ob das zertifikat überhaupt existiert und wenn nicht sollte es keinen content dafür geben. Auch drückst du nicht nach wie vor einfach mal den vhost und die VOLLSTÄNDIGE apache fehlermeldung zu posten - es ist dezent nervig und du behinderst so die Hilfestellung abgrundtief - vllt siehst du etwas nicht was andere sehen...also halte doch nicht mit den infos nach denen du gefragt wirst hinterm berg - ich frag doch nicht aus spaß

[df8oe]

Die ganzen Einstellungen kann ich nicht unverändert posten weil da Kundendaten drin sind (DSGVO). Und die ganzen Stellen unkenntlich zu machen ist eine Heidenarbeit. Aber wir nähern uns. Es ist auf allen drei Servern auch eine IP/Port-Kombination für Port 443 in Froxlor eingetragen - aber es soll kein Vhost dafür erstellt werden. Dementsprechend stört es auch nicht, dass die dort eingetragene Pfad/Zertifikat-Kombination nicht existiert. Alle drei Server laufen seit Äonen - bis Mai mit Debian, seit Mai mit Arch Linux. Das Problem, dass ssl-Vhosts erstellt werden ohne existente Zertifikate ist erst vor ein paar Tagen zum ersten Mal aufgetaucht. Ich habe das letzte Mal vor ca. 1 Jahr eine neue Domain eingetragen - das verlief ohne Probleme. Das ist leider zu lange her und ich weiß nicht mehr ob da

- kein automatischer Haken bei "aktiviere ssl" gesetzt war

- der Haken zwar gesetzt war aber mangels Zertifikat kein Vhost erstellt wird.

Es wird wohl nicht explizit geprüft ob die Zertifikatsdateien existieren - es wird geprüft ob ein Pfad in den IP/Port Einstellungen eingetragen ist und wenn ja, wird das benutzt - auch, wenn die Dateien nicht existieren.

Kann man denn die IP/Port Kombination für SSL gefahrlos löschen ohne dass der Rest auseinanderfliegt? Ein Vhost wird dafür sowieso nicht erstellt. Vielleicht löst das das Problem.

[d00p]

6 minutes ago, df8oe said:

Die ganzen Einstellungen kann ich nicht unverändert posten weil da Kundendaten drin sind (DSGVO).

dann pseudoanonymisiere ips und domains? Wie das alle hier tun?

7 minutes ago, df8oe said:

für Port 443 in Froxlor eingetragen - aber es soll kein Vhost dafür erstellt werden.

wieso? kein ssl für froxlor selbst? 

 

7 minutes ago, df8oe said:

kein automatischer Haken bei "aktiviere ssl" gesetzt war

Möglich, den status von vor einem jahr weiss ich auch nicht auswendig. Wenn du global ssl aktiviert hast und es ssl-ips gibt, setzt er das häkchen ja

 

10 minutes ago, df8oe said:

Es wird wohl nicht explizit geprüft ob die Zertifikatsdateien existieren - es wird geprüft ob ein Pfad in den IP/Port Einstellungen eingetragen ist und wenn ja, wird das benutzt - auch, wenn die Dateien nicht existieren.

Dann sag mir doch bitte genau wo damit ich das prüfen kann

12 minutes ago, df8oe said:

Kann man denn die IP/Port Kombination für SSL gefahrlos löschen ohne dass der Rest auseinanderfliegt?

Nur wenn die IP nicht in verwendung ist (also mind. einer domain zugeordnet ist)

[df8oe]

Froxlor läuft nicht über IP (weil ich kein teures IP-Zertifikat habe), sondern auf einer Subdomain. Und die hat ein Letsencrypt-Zertifikat.

Das manuelle Anonymisieren frisst jede Menge zeit (ich schrieb es bereits).

Ich kann also die IP/Port-Kombination für SSL nicht löschen, wenn irgend eine Domain via SSL läuft. So gut wie niemand dürfte ein IP-Zertifikat haben. Wie lange es sowas überhaupt noch gibt ist auch fraglich. Aber es werden sehr viele Leute auch ohne existentes IP-Zertifikat Domains mit SSL genutzt werden.

Man *MUSS* also eine IP/Port-Kombination für SSL anlegen - auch, wenn man kein IP-Zertifikat besitzt. Kein Problem, weil man ja den IP-Port-ssl-Vhost nicht erstellen lassen muss. Denn einfach "irgendein anderes" oder ein selbsterstelltes Zertifikat dort einzutragen ist kontraproduktiv. Damit würde ja jede neu erstellte Domain "versorgt" werden, bei der Letsencrypt nicht angewählt ist! Folglich dürfte bei den meisten dort ein ungeeignetes Zertifikat oder eben ein ungültiger Pfad drinstehen.

Beim Anlegen einer neuen Domain sollte nicht geprüft werden ob beim IP/Port-ssl-Vhost ein Pfad eingetragen ist, es sollte beim Anlegen der Domain geprüft werden ob die im IP/Port-ssl-Vhost eingetragenen Zertifikatsdateien auch existieren. Das jetzt vorliegende Verhalten erzeugt Arbeit und beim ein oder anderen der weniger Kenntnisse vom System hat auch größere Probleme, wie er den Webserver wieder zum Laufen bekommt nach dem Anlegen einer neuen Domain mit den Default-Einstellungen.

[d00p]

4 minutes ago, df8oe said:

Froxlor läuft nicht über IP (weil ich kein teures IP-Zertifikat habe), sondern auf einer Subdomain. Und die hat ein Letsencrypt-Zertifikat.

hä? Ja das ist das normale setup, froxlor sollte auch nivh via IP aufgerufen werden, dennoch ist der IP/Port Vhost aber der von froxlor selbst genutzte Vhosts...der heisst nur so. Ich glaub du verwechselst da ein bisschen was...

6 minutes ago, df8oe said:

Man *MUSS* also eine IP/Port-Kombination für SSL anlegen - auch, wenn man kein IP-Zertifikat besitzt.

Froxlor macht absolut NIX mit ip-zertifikaten...siehe oben, der ip/port vhost ist der domain-vhost für FROXLOR

[Shortie]

10 minutes ago, df8oe said:

Das manuelle Anonymisieren frisst jede Menge zeit (ich schrieb es bereits).

Den Unix-Befehl sed kennst du aber als Linux-Administrator schon oder?

Ganz ehrlich in der Zeit in der Du das hier immer wieder herunter betest wärst du damit lange durch...

[df8oe]

Ich denke ich verschwende meine Zeit nicht Logs zu verändern oder hier das Fehlverhalten zu posten, sondern den Fehler selbst zu fixen und in mein Froxlor-Github einzufügen. Es existiert auch ein Pull-Request für meine Implementierung von DKIM, der aber schwebt, weil der Part für die Erstellung der DKIM-Serverkonfigurationen fehlt (und ich keine Zeit habe ihn zu erstellen). Aktuell gibt es aber noch keine Merge-Konflikte

Alles, was zum Verstehen der Fehlfunktion nötig ist, steht hier bereits. Und dass eine IP/Port-Kombination für den Vhost von Froxlor verwendet wird kann ich weder nachvollziehen noch wäre das ein für mich erwünschtes Verhalten. Ich muss nicht gleich jeden Hacker der auf meine IP zugreift auf Froxlor stupsen. Und ein Aufruf einer IP mittels ssl ist nur sinnvoll und möglich, wenn man ein IP Zertifikat hat. Sorry wenn ich euch aufgehalten habe und danke für die Hilfe. Leider ist es mir nicht gelungen, das Problem deutlich zu machen. Die geposteten Stellen, an denen die Zertifikate geprüft werden, helfen aber bei einer schnellen Fehlerbehebung defintiv weiter!

[d00p]

5 minutes ago, df8oe said:

Ich muss nicht gleich jeden Hacker der auf meine IP zugreift auf Froxlor stupsen.

Du hast eindeutig nicht verstanden wie es funktioniert und lässt dich lediglich von Bezeichnungen verwirren und verstehst nicht was dahintersteckt. Der IP/Port Vhost mit entsprechendem vhost-container und aktiviertem Froxlor-Vhost sorgt eben genau dafür das froxlor nur über den froxlor-hostnamen erreichbar ist. Und wenn du so viel panik hast das "hacker" auf deiner IP direkt auf froxlor zugreifen, dann leg einen vhost mit leerem ServerName als ersten vhost an und lass nichts oder eine leere seite anzeigen.

Und joa: wenn du keine infos liefern willst, dann kann dir hier auch nicht anständig geholfen werden. Senkt halt direkt meine Ambition dir bei der nächste Frage zu helfen wenn das jedes mal so ausartet (ist ja auch nicht das erste mal)

Und sorry, dein DKIM pull request hat ja wohl hier mit absolut gar nichts zu tun....

[df8oe]

Nein, hat er nicht. Und Flames sind auch unnütze Zeitverschwendung - genauso wie Diskussionen. Ich werde mich nachher drum kümmern und hier entweder die Lösung in Form geänderter Einstellungen oder in Form eines Patches veröffentlichen. Vielleicht macht das dann das Problem transparenter. Das Ziel ist die Behebung einer Fehlfunktion, die für weniger versierte Nutzer zu einem Problem führen kann, das sie nicht ohne weiteres wieder beheben können.

[df8oe]

Fazit:

Wenn bei jemandem dieses Problem auftritt kann man sich mit einem Workaround helfen. Vermutlich sind bei denen, die das Problem haben, im IP/PORT-SSL-Vhost  die beiden Pfade "Pfad zum Zertifikat" und "Pfad zum SSL-Private-Key" nicht leer, sondern haben eine Pfad/Dateikombination, die auf dem Server nicht existiert. Löscht einfach die dort vorhandenen Einträge und lasst die Felder leer. Dann erkennt Froxlor beim Neuanlegen einer Domain mit den Defaulteinstellungen ("aktiviere SSL" gesetzt, "Letsencrypt" nicht gesetzt) dass es kein gültiges Zertifikat gibt und erstellt einen leeren SSL-Vhost für die neue Domain (wie es sein sollte). Nicht existente Zertifikatsdateien im IP/PORT-SSL-Vhost werden nicht als "fehlend" erkannt - im Gegensatz zu leeren Pfadangaben, dort funktioniert die Erkennung!

Es gibt nur eine logische Erklärung für das bei mir beobachtete Fehlverhalten (Erstellung eines SSL-Vhosts mit nicht existentem Zertifikat): Die Überprüfung ob eine Zertifikatsdatei existiert wird nicht durchgeführt.

Für mich ist das Ganze gelöst - ihr könnt selbst entscheiden ob ihr mit diesem Hinweis irgendwas anfangt oder nicht. Das, wozu ich mich als Nutzer verpflichtet fühle (Fehlfunktionen nicht einfach schulterzuckend hinzunnehmen, sondern das Fehlverhalten zu benennen, zu beschreiben, wie man es reproduziert, wo vermutlich die verursachende Stelle im Code liegt), habe ich hiermit getan!

EDIT:

korrigierte Zeile 416 aus lib/Froxlor/Cron/Http/Apache.php:

if ($row_ipsandports['ssl_cert_file'] == '' ||  ! file_exists($row_ipsandports['ssl_cert_file'])){

Ich wünsche allen einen entpannten Restsonntag

DF8OE

[d00p]

perfekt...änderung macht sinn, defintiv. Ist im repository und im nächsten release dabei

[df8oe]

Wir reden einfach eine andere Sprache. Ich will niemanden ärgern  Und Froxlor ist echt Klasse. Dann ändere ich es bei mir nicht sondern mache einfach ein rebase.

 

EDIT:

Ich nutze ja sowieso die Dateien von Github und nicht die eines Releases - weil ich meine Server mit Arch betreibe.

DF8OE

Edited September 6, 2020 by df8oe
additional

[d00p]

9 minutes ago, df8oe said:

Ich nutze ja sowieso die Dateien von Github und nicht die eines Releases - weil ich meine Server mit Arch betreibe.

und was dabei hält dich ab ein .tar.gz zu entpacken statt git? ich mein, grundsätzlich ist git immer besser und aktueller ... mich interessierts einfach, weil es gibt eigentlich keinen grund warum arch das nicht können sollte

[df8oe]

Solange ich Debian hatte habe ich die fertigen .deb-Pakete genommen - das war für mich "das Release". Seit ich Arch habe nehme ich git - weil es sowieso auf dem Server läuft und ständig aktuell ist. Der Rest von Arch ist ja auch "bleeding edge" - da warte ich nicht auf die Releases.