Nextcloud mit Lets Encrypt und anderem Port

[MetalForLive]

Hallo zusammen,

ich habe mal wieder ein spezielles Anliegen wo ich nicht weiter weiß.
Diesmal geht es um Nextcloud und einem Lets Encypt Zertifikat.
Die Ausgangs Situation ist folgende:

Ein Standort mit einem Windows Server inkl. Hyper-V, ein Internetanschluss mit einer Dynamischen IP und DynDNS.
Virtualisiert läuft dort unter anderem ein Webserver in einer DMZ welcher Port 80 und 443 belegt.
Hinzu kam nun ein virtueller Ubunut Server auf dem Nextcloud als Snap installiert ist.

Funktioniert soweit auch alles, ich habe per PAT in meiner Firewall den Port 880 auf Port 80 und Port 444 auf Port 443 des Ubuntu Server weiter geleitet und komme so auch von außen auf die Nextcloud.
Nun wollte ich ein Lets Encrypt Zertifikat hierfür erstellen und habe festgestellt, das geht wohl nur für Port 80 und 443.

Gibt es irgendeine Möglichkeit das Ganze über IIS zu bridgen ?
Ich stelle mir sowas vor wie dass ich im IIS eine neue Seite mit der entsprechenden DynDNS Domain erstelle, für diese ein Lets Encrypt Zertifikat erstelle und den Traffic dann intern an den Linux Server redirecte ohne das es zu Zertifikatsproblemen kommt.

Es wäre natürlich schon schöner wenn es dann über die default Ports läuft.

Alternative Möglichkeiten wären halt die Zertifikatswarnung einfach ignorieren was ich unschön finde, gerade wenn noch mehr Leute darauf zugreifen sollen oder dass ich die Nextcloud am Standort 2 hoste, da dort Port 80 und 443 noch frei sind.
Dann müsste ich für den Server dort allerdings noch neuen RAM kaufen und eine Festplatte, daher wäre es cool wenn es auch anders gehen würde.

 

[Pupp3tm4st3r]

Moin,
wenn ich das richtig verstanden habe, sollte es über eine DNS Verification gehen. Dazu gibt es wohl hier noch einen passenden Client: https://zerossl.com/

Vielleicht hilft Dir das ja weiter
Grüße

 

[Bisumaruku]

Nein du benötigst zwingend Port 80 oder 443. Einzige Lösung wäre für die Zertifikatserstellung die Ports umstellen und nachher wieder zurück. Im laufenden Betrieb kannst du die Ports nutzen die du willst. Wäre halt nur lästig das alle 3 Monate manuell machen zu müssen.

Oder ganz andere Idee über einen Reverse Proxy wie nginx mit Virtuellen Verzeichnissen arbeiten. Dann wären beide Server über 80 bzw. 443 erreichbar und nur über die virtuellen Verzeichnisse zu unterscheiden.

 

[d2boxSteve]

Das muss auch für einen anderen Port gehen. Du musst ggf. das Zertifikat manuell authorisieren über einen TXT Eintrag deiner Domain.

Ergänzung (29. März 2019)

Schau dir hier mal die
DNS-01 challenge
an:
https://letsencrypt.org/docs/challenge-types/

Damit mach es ich.

Ergänzung (29. März 2019)

Eine andere Idee, es gibt inzwischen recht günstige "echte" Zertifikate. "*.domain.de" (Wildcard) für 40$/Jahr:

https://www.ssl2buy.com/alphassl-wildcard.php

Das Lets Encrypt benutze ich für ein kleines Forum, das echte hab ich für meine Cloud.

 

[snaxilian]

Du kannst auch mit dem IIS einen Reverse Proxy einrichten und anstatt mit unterschiedlichen Ports würde ich mit Subdomains arbeiten. Also nextcloud.domain.tld führt zur nextcloud, website.domain.tld dann zu dem anderen Webserver.
Vorteil: Deine Webseiten sind unter den üblichen Ports erreichbar und man muss keine Verrenkungen in Firewalls machen oder PAT konfigurieren etc.
Auch kannst für jede Subdomain dir dann ein Zertifikat besorgen, z.B. bei let's encrypt.

Alternativ eben DNS Challenge aber ich denke das wird etwas schwierig mit reinem DynDNS...

 

[MetalForLive]

Aber bei einer neuen Dyn DNS Subdomain hab ich doch trotzdem nur eine IP Adresse bei der ich auch nur einmal den Port 80 extern habe.

 

[snaxilian]

Genau dafür ist ja dein Reverse Proxy da. Der guckt in eingehende Anfragen wohin, sprich zu welcher Subdomain die Anfrage geht und leitet den Traffic entsprechend weiter.

In deinem Fall zeigen sowohl nextcloud.dyndns.org als auch webseite.dyndns.org auf die IP 1.2.3.4.
Dein IIS (oder so ziemlich jeder beliebige andere Webserver) lauscht jetzt auf 1.2.3.4:80 und 1.2.3.4:443 und ist konfiguriert als Reverse Proxy mit den o.g. URLs.
Wenn du jetzt mit einem Browser nextcloud.dyndns.org aufrufst, bekommst ja per DNS zwar die 1.2.3.4 zurück geliefert aber dein Browser sendet dann die entsprechende HTTP GET Anfrage an 1.2.3.4 mit dem Inhalt "Bitte liefere mir die Webseite nextcloud.dyndns.org" woraufhin dich der Reverse Proxy zu der Ubuntu-VM schickt.

So kannst du mit nur einer IP beliebig viele Webseiten betreiben. Rein theoretisch könntest du sogar alle TLS-Verbindungen am Reverse Proxy terminieren lassen oder bei Bedarf ein und dieselbe Webseite hochverfügbar anbieten indem du mehrere Webserver deine Seite hosten lässt (wobei streng genommen auch dein Reverse Proxy hochverfügbar sein sollte als auch der Datenbankserver hinter den Webservern, usw. usf). Das nennt sich dann eher Loadbalancer. Die Begriffe ähneln sich in vielen Funktionen, ein paar kleine Unterschiede gibt es aber wobei viele Appliances bzw. Webserver oft beide Funktionalitäten abbilden können.
Ebenso könnte man z.B. zentral am Reverse Proxy viele Security Features abhandeln anstatt dies auf jedem Webserver einzeln konfigurieren zu müssen (sofern dies technisch möglich und sinnvoll ist).

 

[Bob.Dig]

Klingt gut. Gibt es das als kostenlose, GUI-basierte Appliance/VM irgendwo zum Runterladen?

 

[d2boxSteve]

@Bob.Dig : ja, nennt sich pfSense (kostenlose, auf FreeBSD basierende Firewall). Hier was zu tun ist: https://administrator.de/forum/pfsense-reverse-proxy-squid-2-web-server-ip-380189.html

 

[MetalForLive]

Alles klar, ich sehe gerade, da gibts ne Reverse Proxy Erweiteung für IIS, dann muss ich mich damit mal befassen.


Edit:

Hmm, mache hier jetzt schon ein paar Stunden rum aber das mit dem reverse Proxy über IIS funzt nicht so ganz leider.
Bekomme immer die Meldung:"502 - Webserver hat als Gateway oder Proxyserver eine ungültige Antwort erhalten."
Ich glaube das liegt daran, das die Nextcloud ein selbst signiertes Zertifikat hat und er damit irgendwie nicht klar kommt.