Ionos Domain: www.sub.domain.tld zu sub.domain.tld mit einem Zertifikat abdecken - Wildcard erforderlich?

[_anonymous0815_]

Hallo Forum,

ich habe mir überlegt, meinen SFTP-Server abzuschalten und gegen eine selbstgehostete Nextcloud-Instanz zu ersetzen.

Bisher hatte ich einfach bei No-IP EINE DynDNS-Domain und eben den SFTP mit PKI und diversem Hardening laufen.

Jetzt soll die Nextcloudinstanz öffentlich über HTTPS/:443 verfügbar gemacht werden, da diese sich doch etwas flexibler und angenehmer administrieren lässt, aber auch mehr Absicherung benötigt.

Ich habe jetzt bei Ionos eine Domain bestellt und die letzten Tage gebastelt, jedoch komme ich hier einfach nicht mehr weiter, da ich den Hostingkram bisher wie der Teufel das Weihwasser gemieden habe.

Ich möchte jetzt einfach, dass

nextcloud.meinedomain.de

#auch unter

www.nextcloud.meinedomain.de

#Erreichbar ist UND durch ein signiertes Zertifikat abgesichert wird

Ich hatte jetzt folgendes versucht:

www.nextcloud.meinedomain.de---CNAME---> nextcloud.meinedomain.de---CNAME----> meinedomain.de---A-Record/DynDNS über Ionos-API---> IPv4

Da meckert Ionos rum, dass für den www.-Eintrag MX-Records deaktiviert werden müssten. Bei dem nc.md.de-Eintrag funktioniert es wiederum problemlos, wenn ich auf die Domain verweise, welche auf den A-Record verweist.

Die nächste Frage wäre, wie decke ich das ganze mit einem Zertifikat ab? Das liefe dann ja auf *.meinedomain.de (Wildcard) hinaus, welche Letsencrypt wohl bereitstellen kann.

Da kommt dann dieser dämliche Aufbau von Nextcloud-AIO hinzu, welcher einen Docker-Container startet, welcher weitere Container anlegt und startet und selbstständig ein Zertifikat bei Lets-Encrypt anlegt, ohne dass ich darauf aktiv Einfluss genommen habe.

Ich weiß, dass das hier nicht unbedingt einfach umzusetzen ist und viel Fehlerpotenzial birgt, aber ich möchte hier learning bei doing betreiben und gucken, was möglich ist.

Anspruch der Nextcloud soll auch keine 100%ige Verfügbarkeit sein, sondern erst mal lediglich zum abgesicherten Datentransfer taugen, ohne dass man einen SFTP-Client/ Putty/ openssh dazwischen nutzen muss. Weitere Funktionen werden vielleicht folgen.

Vielen Dank schon mal für die Anregungen.

 

[madmax2010]

Da meckert Ionos rum, dass für den www.-Eintrag MX-Records deaktiviert werden müssten. Bei dem nc.md.de-Eintrag funktioniert es wiederum problemlos, wenn ich auf die Domain verweise, welche auf den A-Record verweist.

wie sieht der Eintrag aus?
warum www.nextcloud.domain.tld? -> warum nicht einfach nextcloud.domain.TLD

ansonsten brauchst du eigentlich dir den A/AAAARecord, unter dem die nextcloud erreichbar sein soll korrekt zu setzen.

Du kannst nextcloud auch Nativ / ohne AIO Wrapper im Container laufen lassen

 

[_anonymous0815_]

wie sieht der Eintrag aus?

warum nicht einfach nextcloud.domain.TLD

Das soll auch der hauptsächliche Zugriffspunkt sein.

Ich will aber nicht, dass www.nextcloud.domain.TLD in einen Fehler rennt, sondern dass auf nextcloud.domain.TLD verwiesen wird.

Ergänzung (26. Februar 2024)

Ich denke, dass man das innerhalb des Apache-Containers sicher umleiten kann, sauber finde ich das jedoch keineswegs... auch ein Grund, weshalb ich Docker hasse, weil die Abstraktion exponentiell nach oben schießt, ich nicht IM Container rumpfuschen will und wenn der Container mal weg ist, fängst komplett neu an.

 

[madmax2010]

hm. mach mal
sudo certbot certonly --standalone --preferred-challenges http -d www.nc.domain.tld --dry-run --verbose
und schau was passiert.
Vermutlich musst du deinem Reverseproxy da noch was konfigurieren. KeineAhnung wie Nextcloud AIO aussieht

 

[_anonymous0815_]

Probiere ich nachher mal aus, melde mich dann.

 

[_anonymous0815_]

Sorry für die verspätete Antwort, ich habe aktuell anscheinend mehrere Probleme.

Problem Nr. 1: Dass das DynDNS über die Ionos-API nicht funktionieren wollte. Ich denke ich weiß auch warum. Da ich die Subdomain www.domain.tld und die Domain domain.tld für DynDNS eingetragen hatte, die www. Subdomain aber testhalber gelöscht hatte, damit kam wohl die API nicht klar.

Jetzt habe ich allerdings alle Domains dort eingetragen und die fungieren jetzt alle als DynDNS (A Record)... vermutlich auch Quatsch... also muss das nochmal angetastet werden...

Problem Nr. 2: Der Speedport Smart 4 lässt ab und an kein ICMP zu. Anpingen endet manchmal ohne jegliche Antwort, manchmal gehen die Pings problemlos durch...
Konfiguration ist bei weitem nicht in dem Umfange möglich, wie es meine alte 7590 zugelassen hat...

Problem Nr. 3: Scheinbar hat der 5G-Empfänger nach nur einem halben Jahr Einsatzzeit Probleme, denn der LTE/5G-Tunnel bricht nun regelmäßig zusammen. Möglicherweise auch nur eine Störung bei der Telekom... mal abwarten.

 

[_anonymous0815_]

Update:

mein Problem war eher, dass die www.(sub.dom.tld) nicht durch die *.dom.tld Wildcard abgedeckt werden.

Ich brauche also ein sog. SAN-Zertifikat, um die Domain, die Subdomains und die Sub-Subdomains abzudecken. Wobei jede Sub-Subdomain einzeln aufgeführt werden muss, da es der entsprechende RFC nicht vorsieht sowas wie

*.*.dom.tld

auszustellen.

Ich habe zudem die Doku von Nextcloud AIO durchgelesen und bin auf die Möglichkeit gestoßen, das ganze mit Reverse Proxy aufzusetzen.

Der Reverseproxy läuft aktuell jedoch mit auf der Nextcloudmaschine, was den Administrationsaufwand einigermaßen in Grenzen hält, aber sicher eben nicht so sicher ist.

Aktuell führt halt jede Domain, auch die, die dafür nicht vorgesehen sind, erst mal standardmäßig auf die Nextcloud, weil diese auf Port 443 läuft.

Wenn ich mein Plex aufrufen will, muss die 32400 dahinter.

Hier wäre perspektivisch sicher nochmal sinnvoll, einen logisch getrennten Reverse-Proxy aufzusetzen, der die Anfrage an die Subdomains für Nextcloud und Plex, je nach Domainaufruf an die entsprechende VM weiterreicht und beide Dienste über Port 443 erreichbar sind.

 

[_anonymous0815_]

Update 2:

Das gewünschte Verhalten tritt jetzt ein.

Nutze die DynDNS-VM auch als Reverse Proxy und kann jetzt über meine Subdomains sowohl Plex, als auch Nextcloud auf Port 443 erreichen. War allerdings auch wieder frickelig.

Ergänzung (28. Februar 2024)

Die letzte Anpassung wird sein, nebst einem A-Record, auch einen AAAA-Record anzulegen. Da muss ich jedoch wohl nochmal das DynDNS aufbohren.

Ergänzung (28. Februar 2024)

Frage zum Thema Hardening: Fail2Ban nur auf dem Reverse Proxy oder jeweils auf den eigentlichen Hosts?

 

[madmax2010]

Frage zum Thema Hardening: Fail2Ban nur auf dem Reverse Proxy oder jeweils auf den eigentlichen Hosts?

Auf alles was exposed ist.
Vermutlich:
Nextcloud Logs
Apache Logs
ssh

schau mal hier, der erste Teil ist was du dazu suchst : https://www.schreiners-it.de/nextcloud/nextcloud-mit-fail2ban-absichern/

 

[_anonymous0815_]

Update 3: Ich nutze aktuell die normale Domain, wie alle anderen Sub-Domains, für DynDNS und habe Wireguard dafür vorgesehen. Nun leitet mich, wenn ich von Außerhalb auf das Heimnetz zugreife, die IP des Speedports auf meine nc. Subdomain um und somit auf Nextcloud.

Von zu Hause gehts normal...

 

[_anonymous0815_]

Update 4:
Der Ionos DynDNS wollte erst nicht mit IPv4 und 6 funktionieren, da die nur ein Beispiel für die Fritz!Box angeben, mit Variablen in der URL, die die Fritz!Box auflöst.

Dann habe ich ein Pythonscript bei GitHub gefunden: https://github.com/lazaroblanc/IONOS-DynDNS
welches sich diesem Problem annimmt. Gesehen, dass es gar nicht so kompliziert ist und nun selbst etwas in Bash umgesetzt.

Er setzt die Einträge initial mit sem Script, das möchte ich versuchen, am Wochenende in Bash umzusetzen. Denn ansonsten muss man sich erst im API-Portal anmelden und seine Domains eintragen. Ist zwar kein Problem, da man eh den API-Key im Portal anlegen muss, aber ich denke so wäre es nochmal komfortabler...

Problem ist jetzt nur, dass der Speedport am Telekomanachluss mit 5G Hybrid zwar theoretisch Dual-Stack hat, aber IPv6 so dermaßen besch***** implementiert ist, dass alle Pakete von Außen prinzipiell abgelehnt werden. Quasi DS-Lite mit dedizierter IPv4, aber relativ nutzloser IPv6.