DSM & Webserver über SSL mit 2 Sub-Domains erreichbar machen

[MDler]

Hallo Forenmitglieder !

Dies ist mein 1. Post in diesem Forum und ich hoffe das mir bei meinem Problem vielleicht jemand weiterhelfen kann ... Ich habe vorab schon etwas im Forum gesucht, bin jedoch nicht 100% fündig geworden. Ich hoffe, dass ich auch die passende Rubrik getroffen habe, da ich direkt zu SSL kein Hauptthema fand.

Zu meiner Hardware:
Model: Synology DS220+
DSM-Version: DSM 7.2.1-69057 Update 5

Zum Problem:
Ich nutze die Synology momentan als "kleinen Webserver". Ich habe mir dazu mittels PHP eine eigene "Video-Station"-Plattform programmiert, was auch seit sehr langer Zeit problemlos funktioniert. Diese ist über das Internet https://web.meinedomain.de (Beispielsubdomain) über SSL (443) erreichbar und meldet auch keine Zertifikatfehler. (Webhoster: IONOS - A-Record-Update via IONOS-DNS-Api) Da ich mit meinem derzeitigen Webhoster immer unzufriedener bin, habe ich mir eine 2. Domain bei einem anderen Webhoster gesichert. Die "neue" Sub-Domain https://web.meinezweitedomain.de (A-Record-Update über Netcup-DDNS-Api) soll nun ebenfalls auf meinen Webserver laufen. Den DNS-A Record für diese Sub-Domain habe ich auf die IP der Synology eingerichtet. Mittels Ping/DNSLookup funktioniert das soweit auch wunderbar und wird zur richtigen IP aufgelöst.

Nun wollte ich einfach im DSM unter den Menüpunkten "Systemsteuerung" / "Sicherheit" / "Zertifikat" ein neues Let's Encrypt - Zertifikat für die neue Sub-Domain https://web.meinezweitedomain.de hinzufügen. Das Zertifikat selber wurde auch erfolgreich erstellt, jedoch hänge ich an diesem Punkt irgendwie. Wenn ich mir die Eigenschaften des 1. Sub-Domain-Zertifikates anschaue, sind dort wohl irgendwelche "Dienste" (FTPS, KMIP, Synology Storage Console Server, Systemstandard) eingetragen. Diese "Dienste" sind aber im neuen SSL-Zertifikat nicht zu sehen und können auch nicht ausgewählt oder hinzugefügt werden. Aus diesem Grund wird vermutlich auch der Zugriff auf DSM/Webserver über SSL nicht funktionieren !?

Grundsatzfrage:
Ist es möglich diese 2 Sub-Domains mit einem/zwei !? SSL-Zertifikate Zugriff auf DSM und Webserver zu bekommen ? Wenn ja, wie müßte ich dazu vorgehen ?

Und bevor Fragen kommen, warum ich nicht einfach nur die neue Sub-Domain nutzen möchte:
Ich bin mir noch nicht 100% sicher, ob ich den "alten" Webhoster tatsächlich verlasse, da ich derzeit noch in der "Webhoster-Testphase" bin. Auf der Domain https://meinezweitedomain.de sollen später andere Anwendungen laufen. Hierbei bin ich noch nicht 100% sicher ob ich dafür auch alle notwendigen PHP-Extensions und Scripte zum laufen bekomme. (Ist also eine ganz andere Baustelle)

Es wäre schön wenn mir hierbei jemand unter die Arme greifen könnte.

Grüße und Danke !

 

[JohneDoe]

Ein Zertifikat hat erstmal nichts mit den Diensten zu tun. Das Zertifikat muss halt zur Domain passen. Also https://example.de passt nicht für https://www.example.de.
Das was du gern haben willst ist kein Problem. Such danach mal nach Reverse Proxy. Da müsstest du genug Anleitungen finden.

 

[MDler]

Hallo JohneDoe !
Vielen Dank erstmal für die Antwort ! Ich habe die Einstellungen für Reverse-Proxy gefunden und folgende Einträge für die "neue" Sub-Domain hinzugefügt:
1. Eintrag: (Zugriff auf Webserver via SSL)
Quelle:
Protokoll: HTTPS
Hostname: web.meinezweitedomain.de
Port: 443
Ziel:
Protokoll: HTTPS
Hostname: 192.168.2.177 (Lokale IP der Synology)
Port: 443

2. Eintrag: (Zugriff auf DSM - Port von "außen" im Router geändert)
Quelle:
Protokoll: HTTPS
Hostname: web.meinezweitedomain.de
Port: 1919
Ziel:
Protokoll: HTTPS
Hostname: 192.168.2.177 (Lokale IP der Synology)
Port: 5001

Wenn ich nun "von außen" mittels https://web.meinezweitedomain.de oder https://web.meinezweitedomain.de:1919 zugreife, komme ich zwar auf die jeweiligen und richtigen Verzeichnisse/Anwendungen, erhalte jedoch noch immer einen SSL-Zertifikatsfehler. (Genauso wie vorher schon)

Habe gerade mal den SSL-Zertifikatsfehler, welcher mir im Browser ausgegeben wird, anzeigen lassen.
net::ERR_CERT_COMMON_NAME_INVALID
Subject: web.meinedomain.de
Hier wird augenscheinlich immer wieder versucht das SSL-Zertifikat der 1. (funktionierenden) Domain zu verwenden, obwohl ich den Aufruf von web.meinezweitedomain.de angestoßen habe. Für mich sieht das irgendwie so aus, als wenn die SSL-Zertifikate nicht richtig zugeordnet werden können. Gibt es dafür irgendwo eine Einstellung ?

 

[JohneDoe]

Du musst das Zertifikat unter Sicherheit noch dem Reverse Proxy zuweisen.

 

[MDler]

Hallo !
Ich finde unter dem Menüpunkt "Sicherheit" / "Sicherheit" im unteren Bereich nur die Einstellung für "Vertrauenswürdige Proxys". Dort sind 2 Buttons: "Hinzufügen" + "Löschen". Man kann dort "irgendwas" hinzufügen, unter "CDIR". Aber ein Zertifikat oder Sonstiges kann ich dort nicht auswählen. Wo finde ich diese Einstellungen ?

Grüße !

 

[JohneDoe]

Guck mal unter Sicherheit -> Zertifikat.

 

[MDler]

Vielen Dank erstmal für die Hilfe ! Habe es gefunden und dort die jeweiligen URLs / Ports richtig aktiviert. Der Fehler mit dem SSL-Zertifikat zum Server besteht nun erstmal nicht mehr, erhalte jedoch bei jedem Zugriff auf den Webserver einen 400 Bad Request vom nginx. "Request Header Or Cookie Too Large" - Habe sämtliche Cookies/Session gelöscht und ebenfalls schon einen "reinen" Browser getestet. Auch der Aufruf auf Unterseiten bringt immer den 400er Bad Request. Desweiteren greift das SSL-Zertifikat beim Aufruf von https://web.meinezweitedomain.de:1919 zum DSM ebenfalls noch nicht.

​

 

[MDler]

Habe jetzt das Ziel vom Reverse-Proxy für den Webserver intern auf Port 80 mit http eingestellt. Nun funktioniert der Zugriff von "außen" mittels https zum Webserver ohne Zertifikatsfehler. Vermutlich ist dann der "interne" Datenverkehr im LAN nicht verschlüsselt, spielt in der Situation jedoch erstmal keine große Rolle. Jetzt muss ich nur noch irgendwie den DSM-Zugriff via SSL hinbekommen. (https://web.meinezweitedomain.de:1919) - Hierbei wird noch immer das "alte" SSL-Zertifikat von web.meinedomain.de versucht zu verwenden.

 

[MDler]

Keiner mehr eine Idee wie man in dieser Situation vielleicht doch noch das DSM über SSL zugänglich machen kann ?!

 

[Ulfhednir]

Dann schau mal unter Sicherheit -> Zertifikate -> Einstellungen und prüfe welches Zertifikat zugeordnet ist.

 

[MDler]

Hallo ! Vielen Dank für das Interesse am Thema. Die Zertifikate sind dementsprechend zugeordnet. Der Webserver über Port 443 ist auch ohne Fehler zu erreichen. Nur das DSM nicht. Meine Vermutung: Der Reverse-Proxy bekommt über HTTPS automatisch den Port 443 mitgeteilt wenn man die URL https://web.meinezweitedomain.de:1919 auruft und ignoriert dann den Port 1919. Somit kommt wohl das Standard-Zertifikat zum tragen und löst den "SSL-Zertifikatsfehler" für diese Sub-Domain aus ... !?

 

[hblein]

In der Systemsteuerung unter Sicherheit -> Zertifikat -> Einstellungen -> Konfigurieren kannst du den RP-Einträgen ein entsprechendes Zertifikat zuordnen. Evtl. musst du, um den RP-Eintrag zu finden, ein Stück runterscrollen.
Der Reverse-Proxy lauscht, im Übrigen, auf dem Port den du jeweils bei Quelle angibst. Heißt, gibst du im Browser eine URL ohne Port ein, dann gilt Port 443 (sofern im RP bei der Quelle Port 443 angegeben ist). Gibst du im Browser eine URL mit Port ein, dann gilt dieser Port (sofern im RP bei der Quelle für diese Adresse der entsprechende Port angegeben ist). Oder kurz, der RP lauscht auf all den Ports, die bei den einzelnen Einträgen, bei Quelle, angegeben sind. Setzt natürlich voraus, dass es entsprechende Portweiterleitungen im Router gibt.

 

[NSFH]

und daher macht es keinen Sinn DSM über einen willkürlichen Port laufen zu lassen! Nur 443 benutzen, denn der ist immer auf und weitergeleitet zur Syno. Somit vermeidet man die Erfordernisse weitere Ports im Router (hier 1919) öffnen und weiter leiten zu müssen!
Jeder offene Port ist eine potentielle Sicherheitslücke.

 

[Kachelkaiser]

Warum legst du nicht eine zweite Subdomain z.B. dsm.xxxx.xx an. Bei der machst du einen CNAME auf die web.xxxxx.xx damit sie unter der gleichen IP erreichbar ist.

Im RP dann einfach den Eintrag anpassen


Quelle:
Protokoll: HTTPS
Hostname: dsm.meinezweitedomain.de
Port: 443
Ziel:
Protokoll: HTTPS
Hostname: 192.168.2.177 (Lokale IP der Synology)
Port: 5001

 

[MDler]

Vielen Dank erstmal für die zahlreichen Antworten ! Wie ich oben schon beschrieben habe, lief das ganze problemlos mit meiner ersten Sub-Domain: https://web.meinedomain.de (Web-Server) sowie https://web.meinedomain.de:1919 (DSM) - Mit dem Standard-SSL-Zertifikat (Unter Zertifikate im DSM) funktionierte das genau so wie hier angegeben. Mein Ziel war/ist es nun, dass gleiche parallel mit meiner "neuen" Sub-Domain https://web.meinezweitedomain.de (Web-Server) sowie https://web.meinezweitedomain.de:1919 (DSM) zu erreichen. Grundsätzlich war dies nur erstmal eine "idee". Der Web-Server funktioniert ja so über den Reverse-Proxy, da ich eine Sub-Domain mit HTTPS (Port 443) an den internen Web-Server (80) "weiterleiten" kann. Da DSM jedoch einen eigenständigen Port 5001 für HTTPS (SSL) verwendet, kann ich für https://web.meinezweitedomain:1919 keine Umleitung über SSL zum internen DSM machen, da hier die HTTPS (443) wohl zuerst eintritt und Port 1919 ignoriert wird. Ja, es ist richtig, dass ich dafür nun dem DSM über HTTPS eine eigenständige Sub-Domain spendieren könnte (Also ohne eigenen Port 1919) - Aber das war ja eigentlich nicht mein Vorhaben, da ich gerne die "alte" Zugriffsmöglichkeit wie gewohnt weiter nutzen wollte. Mal unabhängig ob nun ein weiterer Port sinnvoll und/oder sicherheitsbedenklich wäre. Mir wurde hier, denke ich, schon sehr gut geholfen und dafür bedanke ich mich auch ! Hoffte die ganze Zeit nur, vielleicht doch noch irgendwie die "alte" Zugangsmethode herstellen zu können. Werde DSM dann wohl über eine eigenständige Sub-Domain (von außen 443) laufen lassen, oder ich schalte die "alte" Sub-Domain einfach ab und stelle die neue Sub-Domain wie die alte auf Standard-Zertifikat um.

Grüße !

 

[hblein]

Mal nur so aus Neugierde (fast OT) gefragt, ist es eigentlich egal, ob man im RP beim Ziel die Geräte-IP oder einfach nur "localhost" einträgt, wenn der Dienst, der angesprochen werden soll, auf demselben NAS läuft, auf dem auch der RP läuft, oder macht das einen Unterschied? Ich würde vermuten, es macht keinen Unterschied, oder gibts da doch einen?

 

[heavy]

Leider kenne ich DSM7 nicht gut (habe es nur auf meinem Backup Nas am laufen) aber auch unter DSM7 sollte dein Vorhaben möglich sein. Ich habe 3 TLD Domains auf meiner 718 laufen und 7 free Dyndns (wie No-ip) und für die TLD (also .de .com .email .org etc) sind auch Letsencrypt Zertifikate (6 eigenständige die anderen domains sind in die Zertifikate integriert als alternative domain namen) hinterlegt. Ich bekomme weder bei den hinterlegten Webseiten noch beim DSM einen Zertifikatsfehler, egal über welche Domain ich es aufrufe. Mann muss nur eins bedenken (wie gesagt DSM 3 bis 6) man kann NICHT Dienste des NAS (Photo, mail, video station, etc) über die Domain aufrufen (incl. Subdomain wie www.), die in den V-Hosts eingetragen ist. Sprich hast du als Vhost eintrag www.meinedomain.tld für deine Webseite eingtragen dann geht www.meinedomain.tld/photo nicht. Da geht dann nur meinedomain.tld/photo also ohne www. Warum eigentlich der Reverse Proxy?

 

[heavy]

Ich habe mir jetzt nochmal alles durchgelesen und deshalb auch die Frage an dich @JohneDoe warum Reverse Proxy. Der macht hier (erstmal) keinen Sinn und nur Probleme. Wenn alles grundsätzlich läuft können wir schauen ob wir die Portumleitung dann über den RP machen damit nach außen nur der 443 offen ist.

 

[NSFH]

Habe das alles nur überflogen und vermute, dass hier ein Unverständnis vorliegt wie ein RP funktioniert.

Für den RP wird im Router nur eine einzige Weiterleitung zur Syno eingerichtet und das für die 443, für keinen anderen Port!
Idealer Weise erstellt man nun bei seinem Domainhoster Subdomains (geht auch anders so finde ich es besser) für jede HTTPS Anwendung, die auf der Syno genutzt werden soll.
Beispiel: dsm.meinedomain.de und webserver.meinedomain.de und passt für jede Subdomain den A-Record an mit Ziel auf die Syno (feste IP oder DDNS)

Ruft man jetzt eine der beiden Subdomains auf landet man im RP der Syno.

Der RP fungiert jetzt als Übersetzer.
Als Quelle werden die Parameter des Einganges eingetragen, also immer HTTPS, Port 443 und der Name der Subdomain
Als Ziel wird eingetragen, wohin die Quelle weiter geleitet werden soll, immer HTTPS, die IP der Syno und dort den Port der App. Bei DSM müsste man also 5001 eintragen.

Zusammengefasst: alles was von Aussen kommt ist Port 443, intern wird es vom RP auf die App auf den synoeigenen Port weitergeleitet.

Aus Sicherheitsgründen würde ich niemals Port 80 so weiterleiten/nutzen!!!

@heavy: Der RP macht hier absolut Sinn und die Probleme liegen beim Nutzer, nicht beim RP oder System.

 

[heavy]

Die Domain die im RP eingetragen ist um das DSM zu erreichen lässt sich nicht mehr in der Webstation zum erreichen einer Webseite eintragen. Somit braucht er schon mal zwei verschiedene Subdomains. Und damit ist es für dass was er zu Beginn schreibt

Ist es möglich diese 2 Sub-Domains mit einem/zwei !? SSL-Zertifikate Zugriff auf DSM und Webserver zu bekommen ?

Eben nicht das Richtige