Ah okay, dann habe ich mich zu sehr von deinem etwas missverständlichen "aber ich kann jetzt gar nicht mit dem Server verbinden" in die Irre leiten lassen.
Dann wohl wirklich ein Fall für den Support. 
PS: Man kann hier im Forum auch ganz easy Bilder hochladen (entweder direkt aus der Zwischenablage einfügen oder eben die Datei hochladen). Dann muss man keinen Drittanbieter ansurfen um deine Bilder sehen zu können.
aber ich kann jetzt gar nicht mit dem Server verbinden oder interagieren.
Ich kann mich auch ganz normal mit SSH verbinden, der Server läuft ganz normal
Na was denn nun? 
Wenn die SSH-Verbindung klappt, sollte sich der Rest (was auch immer nicht funktioniert..haste ja nicht konkret verraten) doch mit entsprechender Fehlersuche aufklären lassen?
httpdocs/bla
Gerade bei solchen Konstellationen kommt glaube ich das Toolkit auch durcheinander, schließlich landet Seite B dann in einem Unterverzeichnis und somit imselben DocRoot wie Seite A. Sauberer wäre hier eine Trennung auf gleicher Ebene. Zum Beispiel /webseiten/domain-a, /webseiten/domain-b, usw.
Bei mir sieht das beispielsweise so aus, um eine saubere Trennung und Ordnung zu gewährleisten:
Das ist aber auch schon alles was ich zum Toolkit sagen kann; bin kein Fan dieser Ein-Klick-Lösungen. Die eingebauten Automatismen bereiten mir zu viel Ärger, wenn irgend'ne Abfrage nicht richtig greift.
Bzgl. Support-Meldung: damit würde ich mich dann wohl mal an den Support wenden. 
"Geht nicht" ist halt immer eine sehr unpräzise Fehlerbeschreibung.
Wenn ich das hier richtig deute, versuchst du ein Catchall-Redirect ganz allein über DNS zu lösen? Das funktioniert nicht wirklich. Eine HTTP-Weiterleitung muss letztendlich ein Webserver umsetzen.
Ich würde es so lösen, indem ich eine Catchall-Subdomain im WCP erstelle und darüber dann den http(s)-Redirect abfertige.
Heißt also:
1. im DNS Wildcard für A und AAAA wieder ganz normal auf die Webhosting-IPs setzen, damit der Wildcard-Aufruf auch vom Webhosting verarbeitet wird:
2. Catchall-Subdomain erstellen:
3. Dann über eine eigene .htaccess-Datei die 301 Weiterleitung einrichten oder einfach im WCP das Hosting auf Weiterleitung umstellen:
Das müsste so eigentlich klappen.
ein Script
welches denn?
ich vermute ebenfalls wie die anderen, dass das Ding arg veraltet ist. ein Blick ins Script würde uns genaueres verraten.
naja, fail2ban banned ja nur, wenn Loginversuche x Mal scheitern. Da solltest du also eher mal prüfen WIESO es zu fehlerhaften Logins deinerseits kommt.
Ich habe es erstmal komplett abgeschaltet
fail2ban und ufw loggen ja ihre Aktivitäten - da also mal reinschauen was wieso wann geblockt wurde. auf jeden Fall sollte nach (bzw. eigentlich schon während) deiner Recherche fail2ban dringend wieder aktiviert werden, da man deine Dienste bzw. deren Logins sonst einfach bruteforcen kann.
Weiterleitung
Sehe da keinen Vorteil gegenüber
ohne einen "Kontakt" immer mit allen Mail-Adressen pflegen zu müssen
Oh sorry, falsch gelesen.
Okay, da fällt mir nix mit Boardmitteln ein. Eine Verteilerliste wäre hier wohl das geeignete Mittel, aber soweit ich weiß gibt es diese nicht im Webhosting (ich gehe mal davon aus, dass dir um ein solches geht). Aber diese müsste ja ebenfalls wie dein genannter Kontakt gepflegt werden.
Vielleicht hat jemand anderes noch ne Idee dazu.
Kurz und knapp: Catchall-Weiterleitung anlegen:
https://www.netcup-wiki.de/wik…nicht_vorhandene_Benutzer
Das klappt natürlich nur "für jeweils eine Domain" und nicht für "alle drölf Domains gleichzeitig die ich bei Netcup gesammelt habe". Muss also entsprechend bei jeder Domain eingerichtet werden.
Mit Sieve-Filtern (beispielsweise im Webmailer von Netcup) könnte man auch noch entsprechend granulare Regeln zur weiteren Steuerung dafür basteln.
Grüße
René
Ruft man die IP-Adresse 188.68.47.84 im Browser auf
Das ist jedoch nicht zielführend. Das Webhosting versorgt mit dieser IP ja nicht nur deine Domains, sondern auch die vieler weiterer Kunden. Daher führt ein IP-basierter Aufruf niemals zu deinem eigenen Webhosting - dies gelingt dir nur über einen domainbasierten Aufruf. Dieser klappte in meinem Test auch, mit gültigem LE Zertifikat (ausgestellt Fri, 22 Oct 2021 07:37:11 GMT).
Als Output erscheint allerdings, wie du sagst, nur error. Dazu müsste man nun in den Webserver-Logs nachschauen was ihm da nicht schmeckt.
Wie erstelle ich denn einen solchen Cronjob?
Auch das ist ausführlich im Netcup-Wiki beschrieben: https://www.netcup-wiki.de/wik…hosting#Geplante_Aufgaben
In deinem Fall dann "URL abrufen".
Nur ein Schuss ins Blaue und als Denkanstoß für diejenigen, die da tiefer in der Materie sind:
Ein Root CA von LE ist doch vor 2 Wochen abgelaufen. Kommt damit ein in die Jahre gekommendes Debian Stretch klar?
QuoteDST Root CA X3 will expire on September 30, 2021. That means those older devices that don’t trust ISRG Root X1 will start getting certificate warnings when visiting sites that use Let’s Encrypt certificates.
[...]
all clients of your API must trust ISRG Root X1 (not just DST Root CA X3), and (2) if clients of your API are using OpenSSL, they must use version 1.1.0 or later.
Welche openssl Version läuft denn bei dir? (openssl version)
Vielleicht ist mein Gedanke auch völlig Quatsch, dann einfach ignorieren und weitergehen. 
"s3.meinserver.de" und zeige auf die IP bei Netcup 94.16.xxx.xxx
Nur um sicherzugehen, dass wir nicht wieder in denselben Fehler laufen: eingetragen im CCP hast du folglich nur sub A 94.x.x.x, also links nicht den gesamten FQDN, sondern nur den Hostteil? Wie sieht denn ein Check bei https://dnschecker.org/ aus? Liefern alle DNS-Server die gewünschte IP? Gut möglich dass dir zuhause irgendein Gerät (Client, Router, etc) noch aus dem Cache noch falsche Werte liefert.
"Die Aufgerufende Seite ist nicht sicher"
Rufst du die Seite explizit mit https davor auf? Ansonsten muss im Webserver noch eine 301-Weiterleitung eingetragen werden, damit automatisch von http auf https weitergeleitet wird. (auch gut möglich, dass dein Bitwarden-Docker-Dings das bereits implementiert hat, keine Ahnung, ich installier sowas immer händisch - dann weiß ich auch welche Config da wirklich aktiv ist). Lauscht der Webserver auf dem Port 443? ss -tlpen Welches Zertifikat wird ausgegeben - das von Letsencrypt? Lässt sich auch über die CLI auslesen: openssl s_client <HOST>:443
Die Frage ist aber, ob du wirklich auf deinem Server landest. Liest sich ja so, alls ob du stattdessen wieder im Webhosting von Netcup gelandet bist. Zuerst sollte also wirklich sichergestellt werden, dass die IP Adresse stimmt. Sonst gehen wir Fehlern nach, die womöglich gar keine sind.
Ja leider bist du bei Letsencrypt mit deiner Domain durch die vermutlich vielen Versuche nun in ein Rate Limit gerannt:
Quotetoo many certificates (5) already issued for this exact set of domains in the last 168 hours
Es bietet sich daher immer an zuerst mit den Staging-/Testserver von LE den Zertifikatsantrag durchzuspielen bis alles klappt. Bei acme.sh geht dies mit dem Schalter --test, certbot nutze ich nicht, gibt es dort aber sicherlich auch.
Ist natürlich jetzt im Nachhinein etwas doof... ich weiß auch nicht ob es Möglichkeiten gibt dieses Limit zu umgehen, vermutlich aber nicht.
die Zertifikate usw. welche ich für die Domain im CCP erstellen kann
DIe im WCP erstellten LE-Zertifikate bringen dir zuhause nichts, richtig. Die werden im WCP am Webserver für dich hinterlegt. Davon hast du ja leider zuhause dann recht wenig. Also: richtig verstanden.
ich habe die gesamte Sub-Domain eingetragen also s9.testdomain.de - A - Destination
Mach dir nichts draus, das ist ein sehr beliebter Fehler hier. 
Ich empfehle auch immer wieder den Blick ins Netcup Wiki, dort sind viele Details durchaus gut erklärt:
https://www.netcup-wiki.de/wiki/Domains_CCP
Viel Erfolg! Bin auf deine Rückmeldung gespannt.
steht da was von Plesk
Dann landest du doch beim Aufruf im Browser vermutlich eher irgendwo auf deinem Webhosting von Netcup (dort ist das fehlerhafte Plesk-Zertifikat leider üblich) und nicht bei dir zuhause - oder?! Und wenn bis eben auch ein DNS-Wildcard-Record hinterlegt war, ist das gar nicht so unwahrscheinlich.
Hast du schon sichergestellt, dass die entsprechenden (Sub)Domains wirklich die korrekte IP von zuhause liefern? Klingt als wäre irgendwo noch ein alter/falscher Wert in einem Cache und zeigt noch auf dein Webhosting. Fakt ist zumindest, ein Plesk-Zertifikat sollte dir nicht ausgeliefert werden, wenn auch kein Plesk im Einsatz ist.
Ansonsten habe ich sehr gute Erfahrungen mit dem acme.sh Cient gesammelt - unterstützt von Hause auch die Netcup-API - dann müssen auch keine Ports in der Firewall aufgerissen werden. Damit einfach WIldcard-Zertifikate (*.deinedomain.de) oder eben Multisite-Zertifikate (bla1.deinedomain.de, bla2.deinedomain.de, usw) anfordern und fertig.
kann ich leider nicht testen;
(habe nur vServer bei netcup und mein Netzwerk zu Hause)
Da könnte man ja trotzdem mal mit freien iperf-Servern gegentesten.
Liste siehe https://forum.netcup.de/admini…ighlight=iperf#post168116
Wenn wir hier bei Datenbank wirklich eine MySQL-Datenbank meinen und nix dateibasiertes, kommst du beispielsweise mit phpMyAdmin da ran, jedoch NICHT mit FileZilla & Co.
Netcup Wiki:
https://www.netcup-wiki.de/wik…nel_Webhosting#phpMyAdmin
Darüber lässt sich die Datenbank auch im- und exportieren (bzw. deren Inhalte). Aber wenn, wie du schon sagst, die Datenbank aktuell "verschwunden" ist (was auch immer das heißt), könnte es ggf. zu spät für eine Lösung sein.
Ich fahre mit einer acme Waittime von 630 Sekunden (10,5min) seit Ewigkeiten sehr gut - zumindest war das bisher auch für die Netcup DNS Server immer genug Zeit die Einträge zu übernehmen.
