Ithariel

Nein, natürlich nicht. Aber wenn du nicht mehr geblockt bist und das ganze mit --debug ausführst, siehst du was schief läuft. Wenn du den Cron weiter laufen lässt, dann wird der LE Block mit pech immer wieder von vorn angefangen.

Okay, du bist erstmal bei LE geblockt. LE Cron deaktivieren und bissel abwarten, für ne Stunde oder so. Genaue Zeiten findest du in der LE Doku. Danach nochmal Debug ausführen und guggen was passiert.

Zeigt die SubDomain denn auf deinen Server? Ist die denn ohne SSL auch richtig erreichbar? Du kannst den Cronjob auch mal manuell aufrufen: /usr/bin/php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug durch den Debug Parameter kriegt man da ne menge mit.

Joa, mit nscd kannst du dir die Änderungen halt sparen. Da gehts dann auch wenn die libnss-mysql.cfg nur von root gelesen werden kann.

Installier dir mal nscd, dann funktioniert das ganze auch.

Als Admin unter Einstellungen -> Systemeinstellungen -> Standard-IP/Port

Ist dein Froxlor aktuell? Let's Encrypt hatte da mal die User Agreements geändert, aber die waren dann nicht in Froxlor hinterlegt. Dadurch konnte man keine gültigen Zertifikate mehr ausstellen. Am besten mal: Froxlor auf den neusten Stand bringen In der Datenbank ggf. die LE Daten der Betroffenen Kunden auf NULL setzten Betroffene LE Certs in Froxlor als Admin unter "SSL Zertfikate" löschen LE cronjob aufrufen, am besten mit --debug damit du was sehen kannst Nen MySQL Dump von der Froxlor DB zu machen bevor du was drin änderst wäre natürlich auch nicht verkehr

Du könntest das ganze auch mal manuell Testen: postmap -q tester@xy.de mysql:/etc/postfix/mysql-virtual_alias_maps.cf Hier sollte einfach die E-Mail als Antwort kommen Und dann noch: postmap -q tester@xy.de mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf Hier bekommst du dann das HomeDir zurück.

Zertifikat ist Zertifikat, ist eigentlich egal von wem. Wenns vom Format nicht passen würde, würde der Mail-Server gar nicht erst Starten. Testen kannst du das natürlich auch, für SMTP mit STARTTLS z.B.: openssl s_client -connect SERVERIP:smtp -starttls smtp

Ich hab das gefühl dass das eigentlich nichts mit deinem Server zutun hatte. Es war ja der Nitrado Server der deine Mail abgelehnt hat und zwar mit "not logged in". Das ist eigentlich ein Zeichen dafür, besonders wenn die Froxlor und Postfix verwenden, das die Empfänger Domain aus deren Sicht Extern liegt. Man muss sich ja erst Authentifizieren bevor man über den Server rausschicken darf, sonst hätte man ja ein Open Relay... Warum es jetzt geht und was tatsächlich Kaputt war kann ich nicht sagen.

Okay, die abc123.de ist aber auch Korrekt mit E-Mail und Postfach bei Nitrado eingerichtet oder? Weil wenn das der Fall ist, weis ich echt nicht mehr weiter

Also, du verschickst von abc.de an abc123.de richtig? Liegt die abc.de den wirklich bei dir, oder nimmst du nur als Absender? Liegt die vielleicht auch beim Empfänger? Soweit mir bekannt bietet Nitrado nur Webhosting an, der vweb10.nitrado.net als Empfänger liegt also Extern und hat an sich nichts mit deinem Server zutun richtig?

Der Let's Encrypt Client kann auch Web-Server Konfigurieren, dafür ist der Parameter vermutlich da. Um das ganze in Froxlor zu aktivieren kannst du z.B. bei den Eigenen vHost Einstellungen folgendes Eintragen: Header always set Strict-Transport-Security "max-age=31536000" Natürlich kann der HSTS Header variieren, da musst du selber gucken wie du den gern hättest.

Durch das verschleiern der Domains wird es leider oftmals etwas schwierig bei so etwas zu helfen. Tausch am besten mal die Domains durch dummys aus (also z.b. abc.de oder 123.de) und gib an welche Domain nun bei dir liegt und welche Extern. Ich kann dir aber jetzt schon sagen: Der Externe Server lehnt die Mail ab, weil denen deine (Ab- ) Sender Domain nicht passt. Da kannst du bei dir so viele Permits rein machen wie du willst, das wird sich nicht ändern.

Etwas spät, aber was solls. Das Problem äussert sich darin, dass nach anlegen des Kunden (also des virtuellen Users), der Webserver keine Lese-Berechtigung auf das Kundenverzeichnis hat. Dadurch gibt der Webserver einfach 403 Forbidden aus.