Reverse-Proxy & Zertifikat

[TschonBo]

DS224+ DSM 7.2.2..

Hallo,
endlich habe ich Jitsi unter Linux Mint 22.1 auf einem PC im LAN installiert.
Bei der Installation habe ich auch ein Zertifikat auf meine Sub-Domain erhalten. Um dies alles installieren zu können hatte ich die Ports 80 & 443 für diesen PC freigegeben und meinem NAS die Ports solange verwehrt.
Dann habe ich die Ports wieder für das NAS freigegeben und im Reverse-Proxy die Sub-Domain eingetragen, was auch teilweise funktioniert. Teilweise, weil das Zertifikat ja auf dem Linux-Server liegt und ich nicht in die DS importieren kann. ?? Stelle ich nun ein neues Zertifikat über die DS aus? Oder gibt das neue Probleme? Wie gehe ich am Besten vor?
Schon doof das nicht alle Rechner auf die gleichen Ports hören dürfen.
Dankbar für jeden guten Tipp.
Ein Forum für Zertifikats-fragen habe ich leider auch nicht gefunden.

 

[plang.pl]

Den Reverse Proxy unter Linux Mint zu betreiben ist keine Option?
Du kannst das Zertifikat auf der DS auch ordern. Idealerweise mit acme.sh, falls dein Anbieter dort unterstützt wird (https://github.com/acmesh-official/acme.sh/wiki/dnsapi & https://github.com/acmesh-official/acme.sh/wiki/dnsapi2)

 

[Benares]

Normalerweise besorgt man sich ein Zertifikat, dass für example.com und *.example.com (als Beispiel) gilt und ordnet dieses den jeweiligen Diensten/Reverse Proxys zu. Rein intern darf es ruhig auch mit http weitergehen. Ich mache alles über https/443 und verpointere das weiter über den verwendetet Namen.
Beispielsweise läuft https://ds415.example.com (also 443) über die Portfreigabe an die DS1522+ zum Reverse Proxy dort ist dann weiter an https://ds415:5001

 

[TschonBo]

Den Reverse Proxy unter Linux Mint zu betreiben ist keine Option?
Du kannst das Zertifikat auf der DS auch ordern. Idealerweise mit acme.sh, falls dein Anbieter dort unterstützt wird (https://github.com/acmesh-official/acme.sh/wiki/dnsapi & https://github.com/acmesh-official/acme.sh/wiki/dnsapi2)

Leider keine Option. Der Jitsi soll nur an sein wenn ich ihn brauche.
Wenn ich meine Sub.Domain.de, wie bereits mit Jitsi auf dem PC ausgestellt, ein neues Zertifikat verpasse, wie geht es dann weiter? Dann gibt es zwei unterschiedliche Zertifikate, geht Jitsi da noch ran oder als Unsicher abgelehnt?? Oder bleibt es bei der ersten Empfangsquittung, glaube ich eher nicht.

 

[TschonBo]

Normalerweise besorgt man sich ein Zertifikat, dass für example.com und *.example.com (als Beispiel) gilt und ordnet dieses den jeweiligen Diensten/Reverse Proxys zu. Rein intern darf es ruhig auch mit http weitergehen. Ich mache alles über https/443 und verpointere das weiter über den verwendetet Namen.
Beispielsweise läuft https://ds415.example.com (also 443) über die Portfreigabe an die DS1522+ zum Reverse Proxy dort ist dann weiter an https://ds415:5001

Ja, so mache ich das auch. Doch was ist mit dem Zertifikat? Zwischen NAS und Linux Server?
Das NAS geht zuerst ran, braucht also ein Zerti.. muss das gleich sein mit dem auf dem Linux Server? Ich denke ja. ??

 

[TschonBo]

In der Wiki steht was zu dem Befehl cat
„2. Möglichkeit: Die Verwendung des Befehls cat“
Sollte ich damit mein Zerti.. vom Server in den DSM kriegen?
„ssh -p [PORT] [BENUTZERNAME]@[IP-ADRESSE]„
Schon mal Jemand gemacht?
Und ist es überhaupt nötig? Oder gibt es andere Ideen?

 

[Benares]

Bei mir läuft acme.sh als Docker auf meiner Haupt-DS, einer DS1522+. Die erneuert das Zertifikat zyklisch und "deployed" es an sich selbst und an meine DS415+. Letzteres braucht es eigentlich nicht.
Port 443 (https) ist im Router nur an die DS1522+ weitergeleitet, dort erfolgt auch im Reverse Proxy die Umsetzung https->http, je nach internem Ziel.

 

[ottosykora]

Schon doof das nicht alle Rechner auf die gleichen Ports hören dürfen.

also das ist nicht verboten, es bleibt aber die Frage wer von den Geräten antworten soll ;-)

 

[plang.pl]

Das Zertifikat auf mehreren Geräten abzurufen, ist kein Problem

 

[TschonBo]

Klarer als in Post #6 kann ich meine Frage nicht formulieren.
Mein Reverse-Proxy nimmt Anfragen an und leitet die Sub-Domain weiter.
Ich habe kein Problem mit der Ausstellung eines Zertifkats, doch ich weis nicht, wer das Zertifikat validiert, mein RP, meine Serveranwendung Jitsi auf dem Linux PC oder müssen beide das gleiche Zertfikat haben?
Bisher hat nur mein Jitsi das Zertifikat und ich erreiche Jitsi auch abgesichert (https).
Doch dann erhalte ich die Meldung:
Connection error
Your device may be offline or our servers may be experiencing problems.

Leite ich in meiner FritzBox den Port 443 direkt an Jitsi funktioniert Jitsi, aber die Portweiterleitung an das DSM muss ich dafür stoppen, da eine doppelte Portweiterleitung in der FB nicht möglich ist.
Vielleicht liegt das Problem gar nicht am Zertifikat, denn die Fehlermeldung sehe ich ja über die abgesicherte https://sub.domain.de
Aber wo liegt dann das Problem?
Das NAS und mein Linux Server liegen im gleichen LAN. Alles nur IPv4.

 

[Benares]

Wenn du den Reverse Proxy auf der DS dazwischen schaltest, muss dein Zertifikat auch auf die DS und dem richtigen Reverse-Proxy-Eintrag zugeordnet werden.

 

[TschonBo]

Wenn Du aus Erfahrung schreibst und es bei dir funktioniert, dann zeige mir doch bitte mal den Eintrag für die proxy.conf. Die Sub am RP einfach durchzureichen scheint mir die einfachere Lösung.
Das stelle ich mir so vor.
server {
listen 443 ssl;
server_name sub.domain.de;
# Weiterleitung an die Jitsi-Anwendung
location / {
proxy_pass https://192.168.x.x:4443
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Das Problem ist nur, das ich das Backand nicht ohne SicherheitsAusnahme im Browser erreiche, also der proxy_pass https://192.168.x.x:4443 ablehnt.
Eigentlich sollte der BackandPort ja 4443 sein, doch damit wird es nicht gefunden bzw. Abgelehnt, nur über den Port 443 mit meiner lokalen IP mit Sicherheitsausnahme kann ich es erreichen, weshalb der RP Eintrag nicht funktioniert.

 

[Hagen2000]

Hallo TschonBo,
das wird so nicht funktionieren, weil Du für die IP-Adresse 192.168.x.x sicherlich kein Zertifikat hast.

Mit dem Proxy hast Du zwei Teilstrecken: Die erste vom Browser zum Proxy - dafür benötigst Du auf dem Proxy ein Zertifikat für sub.domain.de oder ggf. ein passendes Wildcard-Zertifikat.
Die zweite vom Proxy zum eigentlichen Server. @Benares hatte Dir dazu geraten, hier per http (ohne 's') weiter zu gehen (was er in #3 allerdings m. E. nicht konsistent beschrieben hat). Der Proxy ist nämlich seinerseits Client gegenüber dem eigentlichen Server und erwartet bei einer https-Verbindung natürlich ebenfalls ein gültiges und für den Namen passendes Zertifikat.

Also müsstest Du entweder den eigentlichen Server namentlich ansprechen - was entsprechende DNS-Einträge und ein passendes Zertiifkat erfordert - oder eben ohne Verschlüsselung vom Proxy zum eigentlichen Server arbeiten (dafür gilt dann mit Sicherheit eine andere Portnummer als 4443).

 

[TschonBo]

Ja, da beißt sich die Katze in den Schwanz.
Der nginx RP erwartet eine IP zu der er weiterleiten kann.
Jitsi erwartet meine SubDomain.
Wenn nun der RP TTL Validiert geht es trotzdem an die IP weiter und Jitsi sagt Nein.
Ich habe Adguard als DNS Server laufen, vielleicht liegt da die Lösung?
Hast Du da eine Idee wie das aussehen könnte?
Leo AI schrieb mir dies:
Erklärung:

1. Es ist keine SSL-Zertifikatkonfiguration im Nginx-Reverse-Proxy erforderlich, da dieser nur als Weiterleitung fungiert.
2. Der Nginx-Reverse-Proxy leitet die Anfrage an die Jitsi-Anwendung unter der IP-Adresse 192.168.1.100:8443 weiter.
3. Wichtige Header wie Host, X-Real-IP, X-Forwarded-For und X-Forwarded-Proto werden an die Jitsi-Anwendung weitergeleitet, damit diese die korrekten Informationen erhält.

Bezüglich der Serveradresse, die Jitsi erhält:

• Jitsi erhält die aufrufende Sub-Domain sub.domain.com als Serveradresse, da der Nginx-Reverse-Proxy diese Information im Host-Header weiterleitet.
• Die LAN-Adresse des Nginx-Reverse-Proxy (192.168.1.100) wird nicht an Jitsi weitergegeben, da Jitsi die Verbindung direkt mit der Sub-Domain herstellt.

Solange das SSL-Zertifikat auf der Jitsi-Anwendung korrekt konfiguriert ist, kümmert sich Jitsi selbstständig um die Validierung des Zertifikats.

 

[Hagen2000]

Der nginx RP erwartet eine IP zu der er weiterleiten kann.

Hast Du schon mal in die offizielle Doku geschaut? https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

Ohne deine Frage an die AI zu kennen, ist eine Beurteilung der Antwort schwierig. Aber Punkt 1 ist schon in sich nicht schlüssig, denn warum sollte die Weiterleitung begründen, dass kein SSL benötigt wird? Im Zusammenhang mit Satz 2 wird es noch schlimmer, den Port 8443 ist üblicherweise SSL verschlüsselt (kann man natürlich auch anders machen). Satz 3 beschreibt die Aufgaben eines Proxy - hmm

Probier es doch intern ohne SSL, wie von Anfang an empfohlen.

 

[TschonBo]

Da ich gestern noch kein PDF hatte, hier nun die gesammte Unterhaltung mit Leo AI.
Wenn der RP also nur durchleitet, (TLS-End-to-End via Jitsi ) bleibt das Problem, dass ich Jitsi nicht über die IP korrekt ansprechen kann und abgewiesen werde.
Darin sehe ich das Hauptproblem, wenn das mit TLS-End-to-End via Jitsi richtig ist.
Natürlich bin ich für andere Lösungen offen, hauptsache es funktioniert.
Jitsi habe ich mit dieser Anleitung installiert:
https://hoerli.net/jitsi-meeting-software-selbst-gehostet/

 

[TschonBo]

Probier es doch intern ohne SSL, wie von Anfang an empfohlen.

Dann müsste ich Jitsi ohne Domain neu installieren, also auf localhost bzw. 127.0.0.1:80?
Das Zertifikat also auf meiner NAS erstellen und auf den Jitsi per RP an die IP von Jitsi weiterleiten.

 

[TschonBo]

Jitsi lässt sich ohne Zertifikat nicht installieren/ausführen.
Wenn ich einen eigenen DNS Eintrag setze SubDomain=JitsiServerIP, geht die Anfrage ja nicht mehr raus, sondern es wird ohne FritzB. Direkt aufgerufen. Dann könnte ich doch statt der IP die Sub.Domain eingeben als Ziel.
Ist das richtig?