d00p

Also laut apache doc geht die option auf server und auf vhost basis. Zeig uns doch bitte mal die entsprechenden vhosts und wie das eingefügt wurde 

Ah okay, does your server possibly not have an ipv6 address and/or cannot connect to ipv6 networks? That could be the origin of the error message, because first we check for ipv6 record (AAAA) and then for ipv4 (A) - and then merge the two results. So if the first fails, it's not an array (should be "false" and I guess array_merge tries to typecast so it's null) and the merge fails.
Can you try the following adjustments to /var/www/html/froxlor/lib/Froxlor/PhpHelper.php:
diff --git a/lib/Froxlor/PhpHelper.php b/lib/Froxlor/PhpHelper.php index 90b30478..f9fbab55 100644 --- a/lib/Froxlor/PhpHelper.php +++ b/lib/Froxlor/PhpHelper.php @@ -223,9 +223,17 @@ class PhpHelper */ public static function gethostbynamel6($host, $try_a = true) { - $dns6 = dns_get_record($host, DNS_AAAA); + $dns6 = @dns_get_record($host, DNS_AAAA); + if (!is_array($dns6)) { + // no record or failed to check + $dns6 = []; + } if ($try_a == true) { - $dns4 = dns_get_record($host, DNS_A); + $dns4 = @dns_get_record($host, DNS_A); + if (!is_array($dns4)) { + // no record or failed to check + $dns4 = []; + } $dns = array_merge($dns4, $dns6); } else { $dns = $dns6;  

The corresponding setting would be "Settings -> Cronjob settings -> Allow automatic database updates". 
I would frist stop the cron-daemon (so I'm control of the execution), adjust the settings and then run the cron manually using
php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug I strongly recommend a prior backup  If this does not work as expected, let me know, we'll figure something out to update your froxlor

if you just exchange old with new, better use "install/scripts/switch-server-ip.php"

that should work yes

That's because we try to stay as close as possible to the distrobutions default configs and adjust only what froxlor needs. You are free to adjust all the configs as required

Login in as customer, goto "path options" create a new entry and allow "Directory content browsing".
Globally settings +Indexes is not a good idea

what you want is libnss-extrausers - also remember to activate that in the froxlor settings and then follow the configuration templates for it

Das ergibt so gar keinen Sinn...warum sollte Let's Encrypt für domain-alt.tld genenieren wenn ich eins für domain-neu.tld anfordere? Wenn du tatsächlich überall den hostname korrekt geändert hast (allen voran System-Settings -> Hostname, der ist hier relevant) dann kann ich mir nicht vorstellen wieso er sowas tun sollte.
Am besten löschst du zunächst nochmal die Zertifikate von neu und alt (!) und zwar zum einen in froxlor (sofern noch vorhanden) unter dem Punkt "SSL Certificates" und zum anderen, nicht wie du vermutet hast unter /etc/ssl/froxlor-custom/ (hier werden die aus der db generierten certificates abgelegt für den webserver) sondern via acme.sh direkt.
cd /root/.acme.sh/ ./acme.sh --remove -d [domain-alt.tld] ./acme.sh --remove -d [domain-neu.tld] rm -rf /root/.acme.sh/[domain-alt.tld] rm -rf /root/.acme.sh/[domain-neu.tld/ Und dann versuchst du es nochmal ganz in ruhe von vorne

Diese Einstellung hat nur Auswirkung wenn du auch lokal einen DNS Server betreibst, die allerwenigsten machen das. Bist du einer der weniger, dann wird ein entsprechender SPF/TXT Record in die Zone der Domain eingefügt

Ist das Default Setup, such nach myhostname und mydomain in der main.cf

gitlab ist halt nicht gerade als "webhosting kunde" zu betreiben. Dafür sollte eigentlich eine eigene VM genutzt werden, da dort auch einige Dienste laufen etc.
Am einfachsten fährst du in Einklang mit Froxlor wenn du eine Domain (oder subdomain) nutzt die gar nicht von froxlor verwaltet wird, denn gitlab hat seinen eigenen Dienst dafür (läuft local auf port 8181). D.h. der apache wird in diesem Fall nur als proxy verwendet (er leitet quasi alle anfragen an 127.0.0.1:8181 weiter). 
Auch sollte die Nutzung des besagten Vhosts für gitlab kein Problem sein, denn die ServerName-Anweisung sagt dem webserver ja für welche Domain er verantwortlich ist. am besten nennst du sie "001-gitlab.conf" dann wird sie gleich am anfang eingebunden (apache ordnet die vhosts nach dateinamen)

Wierum du es benötigst sei dir überlassen
Wenn my-kö.de die produktiv-genutzte domain sein soll, dann klar, ist my-koe alias von my-kö.de
Und nein, das bedeutet nicht quasi das die domain auf eine andere zeigt, sie ist ein ALIAS, also quasi GLEICH.
Wenn du das via Redirect regeln willst ist das ja auch kein Problem, trage bei "my-koe.de" einfach als DocumentRoot "https://my-kö.de/" ein und froxlor erstellt einen korrekten redirect. Beachte hierbei, dass dafür natürlich ggfls ein SSL Zertifikat vorhanden sein muss wenn jemand https://my-koe.de/ eingibt.
Wenn da das Zertifikat nicht passt, lösche es doch einfach nochmal aus froxlor und aus acme.sh (/root/.acme.sh/acme.sh --remove my-koe.de) und lass den cronjob ein neues besorgen (php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug)

Also laut code wird vorher schon auf Existenz und Lesbarkeit der Zertifikatsdatei geprüft, so dass dort maximal durch fehlerhaften Inhalt der Dateien die Funktion openssl_x509_parse() fehltschlägt, sonst sollte und dürfte an dieser Stelle dieses Notice gar nicht auftreten.
Verhindern kannst du es mit Hilfe folgender Änderung:
diff --git a/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php b/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php index 3e7338e3..b476f755 100644 --- a/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php +++ b/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php @@ -502,7 +502,7 @@ class AcmeSh extends \Froxlor\Cron\FroxlorCron if (is_dir($certificate_folder) && file_exists($ssl_file) && is_readable($ssl_file)) { $cert_data = openssl_x509_parse(file_get_contents($ssl_file)); - if ($cert_data['validTo_time_t'] > strtotime($cert_date)) { + if ($cert_data && $cert_data['validTo_time_t'] > strtotime($cert_date)) { return true; } }  

achso, ja das sollte gehen, froxlor liest das working dir aus der acme.sh.env

Nein
So, der Fehler sagt, Domain id 214, und taucht da auf wo er den documentroot prüft. Also bitte einmal die Ausgabe von 
SELECT documentroot FROM panel_domains WHERE id=214

If you are using a recent version of froxlor it's like this:
If let's encrypt is activated for a domain, froxlors cronjob calls acme.sh to issue a certificate.
From this point on, acme.sh takes care of the certificate and it's renewal.
Froxlors cronjob simply checks for changes (new domains, SAN list changes, or similar) to issue to acme.sh.
Any renewal is a simple filesystem synchronisation from /root/.acme.sh/ to froxlors database. The cronjob then creates the certificate files in /etc/ssl/froxlor-custom/ from the contents of the database. The content can vary depending on the used Webserver because it's htttp oriented for the vhosts (e.g. cert + key + chain, or similar)

Erstelle eine eigene Datei unterhalb von /etc/cron.d/

trying my best

Offenbar wurde der Guide nicht korrekt befolgt, als erstes mal http:// ist es nicht, nur https://; zudem dann die passenden pakete: 
apt-get -y install apt-transport-https lsb-release ca-certificates und vor einem apt-get install musst du natürlich ein "apt-get update" ausführen, um die neuen Quellen einzulesen

Klingt nach fpm/mod_php Mix. Hast du fpm vllt für froxlor selbst nicht aktiviert? Dann könntest du kurzfristig mittels a2enmod php das mod_php Modul wieder aktivieren und froxlor erreichen um es umzustellen.

then just copy the lib/userdata.inc.php to your froxlor installation and it will use the database specified there and won't say its not installed

Dad bedeutet das schon ein anderer Dienst auf diesen Port hört. Das passiert meistens wenn du via a2enmod ssl schon SSL aktiviert hast (und Apache damit unter Debian automatisch auf Port 443 hört)  und dann beim Anlegen der IP und des Ports in froxlor noch das Häkchen bei "Erstelle Listen Eintrag" gesetzt hast. Dann fügt froxlor ebenfalls ein "Listen" ein und Apache versucht zweimal zu binden. Eins von beiden musst du entfernen Sinnvollerweise das Häkchen in froxlor

are you by any chance including froxlor_bind.conf twice in the bind.conf?

Die werden geprüft ja