Cloud Station Drive: Verbindung nach Erneuerung SSL Zertifikat

[superingo]

Guten Tag!

Vielleicht kann mir jemand bei folgender Fragestellung weiterhelfen:

Ich habe im DSM 6 erfolgreich über domaindiscount ein Comodo-SSL-Zertifikat laufen. Internetseiten akzeptieren das Zertifikat ebenso wie meine Cloud Station Drive Installationen.

Nur war ein Jahr vergangen und ich musste das Zertifikat erneuern, auch das hat problemlos funktioniert. Webseiten laufen wieder schön über https. Aber: Muss ich tatsächlich für die Cloud bei ALLEN Installationen in Windows und Android die Verbindung neu aufbauen?

Für Windows geht dies wohl so:
Verbindung muss einmal neu eingerichtet werden, siehe
http://www.synology-forum.de/showthread.html?69987-SSL-Zertifikat-wurde-ge%C3%A4ndert-%28NEIN%29&referrerid=0

Bei Android muss man auch in den Einstellungen rumspielen, bis die Synchronisierung wieder anläuft, aber welches Vorgehen dabei exakt erforderlich ist kann ich jetzt nicht mehr nachvollziehen. Ich glaube man muss einmal SSL aus- und einschalten.

Muss man jedes Jahr an allen Geräten wirklich so machen, oder geht das einfacher? Jährlich geht ja noch, aber bei let's encrypt wäre das alle 3 Monate, dann wird es wirklich aufwändig...


Besten Dank für Eure Hilfe!

 

[Radon]

Hi superingo und Community

Ich habe genau das selbe Problem. Gibt es hierfür eine Lösung?
Zusätzlich was mich am meisten nervt: Eine andere Synology die per CloudStation Share Sync an meiner hängt, hat das gleiche Problem

Ich habe nur noch diesen Beitrag dazu gefunden (vor allem Post 2):
https://www.synology-forum.de/showt...-Client-Zertifikat-ist-nicht-vertrauenswürdig

Leider hilft mir das nicht wirklich weiter, denn ein Neustart von Cloud Station Server, löst nicht automatisch das Problem auf der anderen Synology. und da alle Syno Clients kein Zertifikat anzeigen können, sehe ich auch nicht welches nun "falsch" sein soll.

Die CloudStation Share Sync meldet: "SSL Zertifikat wurde geändert"
Stimmt ja, aber das soll ja auch so sein...

Browserverbindungen sind alle kein Thema. Einfach fast alle Clients von Synology benötigen händischen Eingriff.
Komischerweise auf einem Windows PC hatte ich das Problem, auf einem anderen nicht. Auf Android (DS Cloud) ist auch kein Fehler gekommen.

Ich hoffe hier kann jemand Aufklären.

Viele Grüsse
Radon

 

[manne01]

Hi,

habe dasselbe Problem.

Habt ihr auch das Folgeproblem, dass dann z.B. beim Verschieben von Dateien die Änderungen im Windows Explorer verzögert oder garnicht angezeigt werden?
Beispiel:
Ich speichere einen Anhang aus einer Mail auf dem per Cloud Drive synchronisierten Windows Ordner. Die Datei erscheint dort nicht, erst nach Neuaufbau der Verbindung im Drive Client (Windows 10)!

Habe mal dem Support geschrieben:

Hi there, I am using a Lets Encrypt SSL certificate which is automatically renewed.

Whenever it is being renewed, my Synology Drive Client on Windows gos to "abnormal status", stops working completely and says "SSL certificate has been changed".

Even my windows explorer refuses to show recent changes made on windows due to this problem!

After I go to "Edit Connection" and re-login, everything works!

This should not happen! Also the error message should be more present as you usually dont recognize Cloud Drive not working. Only when I am bothered by a not working windows explorer I get the idea it could be Synology Drive clients missing connection!
Please help!

Mal sehen was passiert.

Schönen Tag wünscht
Manne

 

[manne01]

Man ist wohl dran - heute kam folgende Antwort:

Hello,

thank you contacting us.

We know this isue and will try to find a solution in future. We ask for patince and apologies this situation at the moment.

We don't know when exactly or with which fix / update the issue will solved.

With best regards

 

[euro]

ich hab Drive jetzt länger nicht genutzt
ist das Probleme immer noch existent? oder wurde das mit einem Update behoben?
Ziehen die Clients sich das neue Zertifikat nun automatisch (lets encrypt)

Danke für ein kurzes Feedback
Stefan

 

[Geniemann]

Also ich habe das Problem länger nicht mehr gehabt, auch nicht mit LE, vermute, also dass es gelöst wurde.

 

[manne01]

Hi, ich habe das Problem weiterhin mit der aktuellsten Drive Client Version 2.0.3

Weiß jemand ob das Problem inzwischen beseitigt wurde? Inzwischen gibts ja die DSM 7 beta und soweit ich weiß auch eine neue Drive version.

 

[Geniemann]

Ich habe das Problem nicht mehr. Es kommt ein Hinweise über die Änderung des Fingerprint, man klickt OK und alles läuft weiter. Ich nutze aber noch nicht die Beta, sondern ganz normal DSM 6.

 

[manne01]

Hi Geniemann, danke für die Rückmeldung. Bei mir ist das NAS von extern erreichbar, bei Dir zufällig auch? Denn wenn dem so ist, ist ja das Zertifikat auf eine Domain ausgestellt. Hast Du in die Client Verbindung dann die lokale IP des NAS, oder den Domainnamen? Mit dem vollen Domainnamen <subdomain>.<domain>.de kriege ich leider keine Verbindung. Nur mit <subdomain> und lokale IP.

Und: Kommt bei Dir beim Test/Speichern der Verbindung die Meldung dass das Zertifikat nicht vertrauenswürdig sei, die man dann aber "ignorieren" kann? Bei mir kommt die und ich vermute solange die kommt, klappt auch das vollautomatische Renewal am Client nicht.

 

[Geniemann]

Hallo manne01,

ja, genau so ist es. Es ist extern erreichbar und ich verwende die URL und es kommt immer die Meldung mit dem nicht vertrauenswürdigen Zertifikat. Mehrfach habe ich mit Synology darüber gesprochen, die wissen wohl nicht woran es liegt. Ich erhalte das mit LE-Zertifikaten gleichermaßen, wie mit gekauften.
Bei den meisten Apps auf dem Handy ist url.tld/app richtig. Manchmal geht nur url.tldort (weiß gerade nicht bei welcher) - bei Drive auf dem Mac geht nur url.tld (ohne alles andere).

Also alles so wie bei dir scheint mir, aber dennoch:
Bei Zertifikatswechsel kommt auf dem Handy eine Meldung zum OK klicken und auf dem Mac in der Drive-App einfach gar keine Meldung mehr. Also das läuft soweit gut und ohne neuverbinden und alles erneut konfigurieren zu müssen.


Beste Grüße

 

[euro]

ich hab das Problem nach wie vor
nach Ablauf vom Cert muss ich unter Win auf allen verbundenen Clients einmal die Drive Regel Verbindung bearbeiten, das Cert abnicken und weiter gehts wieder für 3 Monate
nervig, zumal es immer dann auffällt, wenn man die frischen Daten von der Syno bräuchte (nicht bei mir selbst ..)
mfg Stefan

 

[Geniemann]

Hm, Win Rechner habe ich hier tatsächlich nicht. Bei Mac und Mobile, taucht das Problem nicht auf. Ärgerlich, dass Synology das nicht hinbekommt, oder wenigstens weiß, woran es liegt.

 

[manne01]

Bei mir gehts nur um ein NAS und einen Windows Desktop Client. Und bei mir war in der Drive Connection bisher die lokale IP hinterlegt. Die passte nicht zum Zertifikat, deshalb ja beim speichern die Meldung ob man trotzdem vertrauen will.

Da es mir nicht gelingen wollte, die vollen im Zertifikat hinterlegten externe Domain also subdomain.domain.tld eine Verbindung herzustellen habe ich auf der Kommandozeile gepingt und festgestellt, dass da natürlich für die volle Domain eine wahrscheinlich externe IP (auch noch im v6 Format) zurückkommt und nicht die lokale. Eigentlich müsste der Drive Client ja auch darüber eine Verbindung aufbauen können, das wundert mich. Aber gut, vielleicht liegts am v6.

Nun habe ich jedenfalls
lokale v4 IP des NAS und meine volle Domain in die datei
C:\Windows\System32\drivers\etc\hosts
aufnehmen

Und siehe da, nun gelang die Verbindung und auch die Abfrage ob man trotzdem Vertrauen will kam nicht mehr.

Meine Hoffnung ist nun, dass jetzt wirklich alles zusammenpasst und die Aktualisierung des Zertifikats vollautomatisch bis einschliesslich zum Client durchschlägt. Mal sehen

 

[Fusion]

Ja, das ist die mögliche Lösung für Einzel clients. Für alle Geräte im lokalen Netz wäre es ein lokaler DNS Server auf der DS oder pihole z.b.
Oder der Router unterstützt NAT-Loopback / pinhole NAT bzw bei Fritzboxen 'Ausnahmen vom DNS Rebind Schutz' um eine Rückverbindung (Client > Fritz (lan/wan/lan) > DS) zu erlauben. Dann geht es ebenfalls via Namen, wenn die Portfreigabe korrekt für ipv4/ipv6 vorhanden sind.

Ebenfalls kann helfen wenn man das Zertifikat mal löscht und neu ausstellen lässt, wenn man es schon länger hat.
Es gab in den letzten 1-2 Jahren Änderungen an der Vetrauenskette der Zertifikate bis zur root CA. Das macht selten auch mal Probleme.

 

[Michael_lu]

Hallo zusammen
scheinbar haben wir ein ähnliches Problem. Wir arbeiten bei uns in der Firma mit einer DS718+ und setzen diesen als Server/Datenspeicher ein. Darüber laufen unsere Kalender etc. Alles einwandfrei. Auch haben wir unser altes NAS als Replik-Server eingerichtet. Somit wird einmal am Tag. bzw. in der Nacht eine gesamte Datensicherung erstellt.
Für die Dienste von Synology Drive, Calendar und Server wird ein SSL-Zertifikat verlangt. Dieses konnten wir recht einfach über das Menü "Sicherheit" erstellen. Seitdem das alte Zertifikat abgelaufen und wir das alte erneuert haben, erhalten wir eine Fehlermeldung, dass dieses neue Zertifikat nicht mehr akzeptiert wird und die Datensicherung wird nicht durchgeführt. Die Synchronisation der Kalender etc. funktioniert einwandfrei.

Welche Möglichkeiten gibt es, bzw. welche Lösungsschritte wären Zielführend?

Vielen Dank im Voraus.
Lg Michael

 

[Ulfhednir]

Eine ähnliche Problematik gab es mit der Cloud Station (Vorgänger von Cloud Station Drive). Lösung war denkbar einfach: Den Benutzer + Kennwort im Client nochmal "anmelden" lassen.

 

[roterteufel81]

Hänge mich hier auch mal ran.
Gibt es eine Lösung, wie das für Drive Automatisch geht?

Es passiert unter Drive 3 auf DSM7 immer noch.

1. meine Client User sind keine ITler
2. meine Client User bekommen die gestoppte Drive Funktion in der Regel nicht mit, da sie das rote ! Im Drive Symbol nicht bemerken
3. Denen den Prozess der Neuanmeldung durch die Menüs zu erklären ist schwierig

es muss doch gehen, dass nach einem Let’s Engrypt Zertifikatwechsel alle 90 Tage die Clients einfach weiterlaufen und sich im Hintergrund die neuen Zertifikate ziehen ohne neu einloggen etc.

 

[euro]

Das wäre zumindest ein Träumchen. Hab das Problem auch immer noch bei mehreren Installationen.
Mfg Stefan

 

[roterteufel81]

Das Einzige, was mir noch einfallen würde am Client wäre, dass ich beim Drive statt der lokalen IPV4 Adresse des NAS die DynDNS Adresse angebe und aus dem lokalen LAN mit NAT Loopback arbeiten würde. Ich weiß nicht, ob es dann automatisch laufen würde. Nachteil ist halt, dass man sich dann der Router zum Flaschenhals würde?

Oder aber das oben mit der "Hosts" Datei? Was muss man denn da genau eintragen in HOSTS? Einfach nur „192.168.1.XXX dyndnsadresse.tld“? (Klappte bei mir nicht)

Bei den iOS Smartphone Apps scheint das alles nicht zu passieren, da meckerte er nicht rum, als sich das Zertifikat änderte, weder bei Drive, noch Photos, noch DS Cam, noch DS Finder, noch File Station, die liefen einfach weiter, ohne Meldungen.

Es scheint wirklich nur den Windows Drive zu betreffen. Den Synology Windows Surveillance Client konnte ich jetzt nicht testen

 

[roterteufel81]

Gibt es eigentlich die Möglichkeit, dass man sich bei dem automatischen Zertifikations-Erneuerungs-Script eine E-Mail zusenden lässt, wenn das Zertifikat erfolgreich ausgetauscht wurde? Es sollte also nicht täglich eine E-Mail geben, da das Script ja 1x am Tag läuft und prüft, ob man das Zertifikat erneuern kann, sondern nur dann, wenn es auch wirklich ausgetauscht wurde. Das würde es einigen meiner User sicher einfacher machen.

Ich habe übrigens zu diesem Thema erfolgreich einen Feature Request bei Synology eröffnen können, der auch akzeptiert wurde. Wie lange es dauert, ob was und bis sie es fixen, weiß ich aber noch nicht.

Folgendes habe ich requested:

Kein Auto-Logout und keine erneute Google Authenticator 2FA Eingabe nötig, wenn DynDNS (im eigenen LAN dann mit NAT-Loopback) genutzt wird.

Ich habe sämtliche Apps und Web-Logins all meiner Clients und Geräte auf MyFritz DynDNS mit NAT-Loopback im LAN/WLAN umgestellt, da sie alle an Fritzboxen hängen. Das löst zumindest das nervige Problem mit "nicht vertrauenswürdig" Meldung beim Neu-Login