Freigabe-Link mit benutzerdefinierten Domain

[alexhell]

Du kannst über acme.sh für jede Domain ein Wildcardzertifikat holen. Läuft auch im Docker.

 

[XuseX]

Hallo allerseits,
ich habe ein neues Zertifikat ZeroSSL über acme.sh erstellt. Es hat alles bis auf die Einrichtung (Deployment) auf DS über SSH funktioniert.
Nach dem Deployment-Befehl kam die Meldung:

The domain 'example.com' is not a cert name. You must use the cert name to specify the cert to install.
Can not find path:'./example.com'

Befehle davor waren:
export SYNO_Username="username"
export SYNO_Password="password"
export SYNO_DID="OTP CODE"
export SYNO_Certificate="NEW NAME"
export SYNO_Scheme="https"
export SYNO_Port="5001"
./acme.sh --deploy --home . -d example.com --deploy-hook synology_dsm

Ich habe aber auf der Seite von ZeroSSL gesehen, dass das Zertifikat erteilt wurde. Ich habe die ca_bundle.crt und cerfificate.crt manuell heruntergeladen und die private key über SSH ausgelesen. Synology hat das Zertifikat akzeptiert und ich habe dem den Dienst Synology Drive Server zugewiesen.



Und dennoch funktioniert es nicht. :-(

Folgende Meldung erscheint:
"Dieser Server konnte nicht beweisen, dass er drive.example.de ist. Sein Sicherheitszertifikat stammt von DDNS.synology.me. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der deine Verbindung abfängt.

Wie gesagt für DDNS.synology.me habe ich ein gültiges LE Zertifikat. Wenn ich ohne die benutzerdefinierte Domain ein Freigabe-Link aufrufe, dann kommt kein SSL-Error.



Mein Hosting-Provider (IONOS) hat mir Empfohlen anstatt eines CNAME-Eintrags (Verweis von der Subdomain auf die DDNS) eine Domain-Weiterleitung über den Konfigurator einzurichten. Ich habe es heute morgen getestet, und das hat auch nicht funktioniert. Dabei wollte der Link nicht mal "unsicher" geöffnet werden.

Wo könnte das Problem liegen? Mich verwirrt die oben zitierte Meldung, dass der Server immer noch das DDNS Zertifikat erkennt und nicht akzeptiert, dass es für die Subdomain auch ein Zertifikat vorhaben ist.

 

[Benares]

Denk dran, dass SYNO_Certificate auf die Beschreibung des Zertifikats zeigt, das du deployen willst

 

[XuseX]

Das habe ich jetzt nicht verstanden, @Benares.
Ich dachte, dass bei der Anweisung export SYNO_Certificate="NEW NAME" einfach eine beliebige Beschreibung rein kommt, also ein Name für dieses Zertifikat. Und wenn man die Beschreibung frei lässt: export SYNO_Certificate="", dann wird dieses Zertifikat zum Standardzertifikat. Stimmt das? Ich möchte aber weiterhin als Standardzertifikat, das Zertifikat für meine DDNS haben. Aus diesem Grund habe ich für das Zertifikat meiner Subdomain einfach einen Namen stehen.

 

[Benares]

Bei einem neuen Zertifikat weiß ich nicht mehr, was in der Beschreibung landet.
Bei jeder Erneuerung musst beim Deploy aber mitgeben, welches deiner Zertifikate das neue ersetzten soll. Und das wird über SYNO_Certificate="irgendwas" zugeordnet wenn in der Beschreibung (Aktion, Bearbeiten) der Text "irgendwas" steht.

 

[XuseX]

Ich komme einfach nicht weiter.

Nur zur Info als Zusammenfassung:

Ziel: Weiterleitung von der Subdomain drive.example.de (Anbieter IONOS) auf DDNS name.synology.me um die Subdomain als benutzerdefinierte Domain für Freigabe-Links (Synology Drive Server) zu nutzen.

Sowohl für DDNS name.synology.me, als auch für die Subdomain drive.example.de ( example.de, *.example.de, drive.example.de) sind SSL Zertifikate auf der DS installiert.

1. Versuch:

CNAME-Eintrag > Verweis von drive.example.de auf name.synology.me

Funktioniert aber mit SSL Error.

Folgende Meldung erscheint:
"Dieser Server konnte nicht beweisen, dass er drive.example.de ist. Sein Sicherheitszertifikat stammt von name.synology.me. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der deine Verbindung abfängt.

2. Versuch:
Domainweiterleitung (Frame-Weiterleitung) über IONOS direkt eingerichtet.
Keine Veränderung. Selbe SSL Fehlermeldung.

3. Zum Testen habe ich bei IONOS über DNS API eine DDNS für die Subdomain drive.example.de eingerichtet. Leider ist mir nicht gelungen diese DDNS in der DS hinzufügen. Meldung: Wenden Sie sich an den Anbieter von Synology . Ich habe die Query URL von IONOS bei der DS im Bereich Externer Zugriff > DDNS > Anbieter anpassen hinterlegt, dann den Hostname drive.example.de angegeben (Benutzernamen und Kennwort gibt bei IONOS nicht. Laut IONOS einfach ein Leerzeichen), aber leider schlug der Verbindungstest fehl.

Da aber für die öffentliche IP bereits die DDNS von name.synology.me hinterlegt ist, wird das DSM auch unter der Subdomain drive.example.de aufgerufen. Aber immer noch mit der besagten SSL Fehlermeldung.

Ich habe das Gefühl, dass etwas die Abfrage des Zertifikats für die Subdomain beim Versuch 1 und Versuch 2 blockiert.

Zu den geöffneten Ports im Router für die DS:
1194, 6690, 5001, 443

Gibt es von eurer Seite weitere Tipps? Ich danke Euch im Voraus!

 

[Benares]

Folgende Meldung erscheint:
"Dieser Server konnte nicht beweisen, dass er drive.example.de ist. Sein Sicherheitszertifikat stammt von name.synology.me. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der deine Verbindung abfängt.

Dann muss du Synology Drive halt ein Zertifikat zuordnen, dass (auch) für drive.example.com gilt.
Das (Wildcard-)Zertifikat für synology.me deckt alle *.name.synology.me-Namen ab, aber halt keine anderen.

 

[alexhell]

Mir ist eben was aufgefallen. Auf dem Screenshot steht zwar Synology Drive Server, aber da ist nicht deine Domain zu geordnet. Ich habe eben bei mir unter Systemsteuerung -> Anmeldeportal -> Anwendungen -> Synology Drive eine eigene Domain eingetragen. In deinem beispiel drive.example.de. Dann taucht dieser Eintrag auch bei Sicherheit -> Zertifikat auf und du kannst dem Dienst dein Zertifikat zuweisen. So hast du Drive ja nie dein Zertifikat zugeordnet.

 

[Benares]

Das Eintragen einer Domain im Anmeldportal bei den Anwendungen erzeugt im Hintergrund einen (nicht sichtbaren) Reverse Proxy, ähnlich zu denen, die man manuell anlegen kann. Der hat dann eine eigene Zertifikats-Zuordnung unter Sicherheit/Zertifikate, wie die manuell erstellten Reverse Proxys auch.

 

[alexhell]

Ja genau, aber ohne den Eintrag kann man ja kein Zertifikat zuordnen oder? Also ich weiß es jedenfalls nicht wie.

 

[Benares]

Doch, das geht. Es gibt dann bei Drive sogar 3 Dienste, denen man Zertifikate zuordnen kann
1. "Synology Drive" (Drive direkt)"
2. "Synology Drive - 10003" (???)
3. "Synology Drive - drive.example.com" (Drive über impliziten Reverse Proxy, drive.example.com als Domain im Anmeldeportal)
und wenn man noch explizite Reverse Proxys für Drive erstellt evtl. auch noch
4. "drive.synology.me" (Drive über expliziten Reverse Proxy für "drive.synology.me")
...

 

[XuseX]

OMG!!!! Ich danke EUCH!!!

Das war der entscheidende Punkt im Anmeldeportal bei den Anwendungen die Subdomain als alternative Domain anzugeben und dieser Subdomain dann die Anwendung Synology Drive Server unter Zertifikaten zuzuweisen.

Davor habe ich immer wieder dem Zertifikat der Subdomain die Zuweisung unter Einstellungen hinterlegt und beim Zertifikat stand auch Für: Synology Drive Server. Aber anscheinend wie @alexhell richtig anmerkte, muss auch die Subdomain da stehen.



Freigabe-Links funktionieren super!

Ich danke Euch nochmal. Das Forum ist einfach klasse!

 

[alexhell]

Wenn du die Domain nicht einträgst, dann weiß Synology doch gar nicht, dass du darüber auf Drive zugreifen willst. Aber sehr schön, dass es jetzt so funktioniert wie du es wolltest

 

[Benares]

Ohne Domain-Eintrag oder Reverse-Proxy müsste man halt mit https://drive.example.com/Drive (Alias) oder https://drive.example.com:10003 (Port) arbeiten, da drive.example.com nur die IP auflöst. Erst mit einem Reverse Proxy (ob implizit oder explizit ist egal) geht das auch über den Standard-https-Port (443) anhand des angesprochenen Namens.
Wichtig ist das für die erforderlichen Portweiterleitungen/-freigaben. Im ersten Fall bräuchte man 443 und 10003 (bzw. noch weitere für weitere Apps), mit Reverse-Proxy nur noch 443 (bzw. noch 80 und Umleitung auf https/443, wenn man's "schön" machen will).

 

[XuseX]

Danke für die Hinweise.
Eine Kleinigkeit stört mich aber weiterhin.

Wenn ich die Subdomain drive.example.de , die auch als alternative Domain unter Anwendungen für Synology Drive hinterlegt ist, aufrufe, dann werde ich korrekt zu Synology Drive weitergeleitet, die Verbindung ist sicher und alle Freigabe-Links funktioniert auch.

Mir ist aber aufgefallen, dass der Synology Drive Client weiterhin ein Problem mit dem Zertifikat hat und diesen als nicht vertrauenswürdig einstuft.

Ich habe die Einstellungen im Client überprüft und die neue Domain eingetragen, aber bei der Überprüfung kommt die SSL Meldung.



Unter Zertifikaten sind der Domain example.de (*example.de, drive.example.de) --> Synology Drive - drive.example.de und Synology Drive Server als Dienste zugewiesen.

Weiterhin ist mir aufgefallen, dass der Dienst Synology Drive Server im Webbrowser unter zwei Domains aufgerufen werden kann, ohne jegliche Fehler.

1. Wenn ich aus dem Synology Chat unter App Laucher (screenshot) auf Synology Drive zugreife, dann wird die Anwendung immer noch unter der alten Domain (meine Standard-DDNS) ohne SSL-Fehler aufgerufen. Eingenlich müsste der Aufruf über drive.example.de gehen.

2. Genau so sieht es auch aus, wenn ich aus dem DSM unter App Laucher auf Synology Drive zugreife. Aufgerufen wird Synology Drive unter der Standard-DDNS.


3. Wenn ich aber aus dem Synology Drive Client (screenshot) oder aus dem Synology Drive Server im Webbrowser, die Anwendung nochmal aufrufe, dann wird die Anwendung korrekt unter drive.example.de aufgerufen.



Woran kann es liegen? Interessant ist auch, dass wenn ich im Synology Drive Client unter Einstellungen die Standard-DDNS angebe und die Verbindung teste, dann kommt auch die SSL-Meldung. Was auch richtig ist, denn diesem Zertifikat für die Standard-DDNS wurde der Dienst Synology Drive Server entzogen. Aber im Webbrowser kommt keine Fehlermeldung.

Und ohne zu speichern, habe ich geschaut, was unter Anmeldeeinstellungen für Synology Drive angezeigt wird, wenn ich einen Aliasnamen eingebe. Dann wird mir meine Standard-DDNS angezeigt.



Ich hoffe, dass Ihr mir weiterhin mit hilfreichen Tipps helfen könnt. Danke schon mal im Voraus!

 

[alexhell]

Ich kann dir leider nicht bei allen Fragen helfen, weil ich nutze persönlich kein Drive.

1. Wenn ich aus dem Synology Chat unter App Laucher (screenshot) auf Synology Drive zugreife, dann wird die Anwendung immer noch unter der alten Domain (meine Standard-DDNS) ohne SSL-Fehler aufgerufen. Eingenlich müsste der Aufruf über drive.example.de gehen.

Nein, wenn du etwas über DSM aufrufst, dann wird nicht die alternative Adresse verwendet, sondern das was du bei Systemsteuerung -> externer Zugriff -> Erweitert eingetragen hast. DSM hängt für die App dann die Parameter dran. Das drive.example.de ist ja nur eine Alternative Adresse.

2. Genau so sieht es auch aus, wenn ich aus dem DSM unter App Laucher auf Synology Drive zugreife. Aufgerufen wird Synology Drive unter der Standard-DDNS.

Siehe Antwort zu 1.

3. Wenn ich aber aus dem Synology Drive Client (screenshot) oder aus dem Synology Drive Server im Webbrowser, die Anwendung nochmal aufrufe, dann wird die Anwendung korrekt unter drive.example.de aufgerufen.

Ja weil du auch über die Domain drauf zugegriffen hast.

Und ohne zu speichern, habe ich geschaut, was unter Anmeldeeinstellungen für Synology Drive angezeigt wird, wenn ich einen Aliasnamen eingebe. Dann wird mir meine Standard-DDNS angezeigt

Ja, weil das nur ein Alias ist. Er hängt an deine Hauptdomain einfach nur den Alias dran. Das ist genau das erwartete Verhalten.