SSL-Zertifikate wurden geändert

[Ulfhednir]

Und ich bin mir so ziemlich sicher, dass es den Lösungsansatz bereits 2021 gab. Mein Beitrag ist aus 2021 und da hatte ich mich zwangsweise mit der Thematik beschäftigt. Allerdings ist der Lösungsansatz für den DAU eher suboptimal, deswegen gab es meine DAU freundliche Empfehlung mit self-signed Cert.

 

[Handschweiß]

Die EInstellung "Verbindung bearbeiten" gibt es bei mir nicht. Wie geht es denn dann?

 

[Benie]

Synchronisierungsaufgaben und dirt Verbindung bearbeiten

 

[Handschweiß]

Kann man dort nicht bearbeiten

 

[niklas]

dort:

 

[Benie]

Etwas anderes gibt es nicht.

 

[Opoeler]

Es tut mir leid, aber das ist doch ein riesen Mist von Synology. Durch diese Fehlermeldung hat der Drive Client auf dem PC meiner Frau gestoppt. Meine Frau hat die Fehlermeldung nicht gesehen und ich war auf Dienstreise. Wie es so sein muss, ist die Daten HDD genau in dieser Zeit hopps gegangen und die Daten sind weg.
Mit dieser Hilfe habe ich es jetzt zwar wieder am Laufen, aber die Daten für eine Woche sind weg.

Auf meinem iPad hab ich jetzt festgestellt, dass sich Drive nicht mehr starten lässt.
Ein Löschen und Neuinstallation hätte dann zur Folge dass alle Daten auf dem iPad gelöscht werden und komplett neu synchronisiert werden muss.

Super Lösung für das Handling wichtiger Daten.

 

[plang.pl]

Da kann Synology nix dafür. Ich nenne Dir auch 3 Gründe, warum das so ist:
-Sync ist kein Backup
-dass das Zertifikat in deinem Fall nicht gültig ist, ist alleine Deine Schuld oder / und steht außer der Macht von Synology, denn auch die können Let's Encrypt nicht zwingen, ein Zertifikat für eine IP / Hostname auszustellen
-du brauchst ein Backup deiner DS -> kein Backup, kein Mitleid

 

[Opoeler]

bzgl. Punkt 1 und 3 gebe ich Dir Recht. Ein 1 Woche altes Backup habe ich jedoch und das auch auf zwei DS.
Beim zweiten Punkt verstehe ich nicht, weshalb das meine Schuld sein soll.

Vielleicht sollte ich nicht erwarten, dass Synology Drive halbwegs so zuverlässig wie kommerzielle Cloud Dienste (iCloud, OneDrive etc) ist.
Das mit dem Drive Client auf dem IPad ist dann scheinbar auch normal. iCloud und OneDrive sowie Google Drive funktionieren auf dem gleichen Gerät bisher ohne jeden Ausfall.

 

[alexhell]

Aber für das SSL Zertifikat bist du doch zuständig. Die Zertifikate von lets Encrypt sind nur 90 Tage gültig und für eine IP bekommst du nun mal kein Zertifikat. Was soll Synology denn da machen?

 

[plang.pl]

Punkt 1: Ein Zertifikat gilt im Home-Bereich niemals für eine IP Adresse oder einen Hostname des NAS
Punkt 2: Ein Zertifikat gilt nur für eine QuickConnect Adresse, einen DDNS oder eine Domain
Punkt 3: Ein Zertifikat läuft alle 3 Monate aus und wird erneuert
Wenn du also mit deinem Drive Client nicht über eine in Punkt 2 genannte Methode verbunden bist, musst du alle 3 Monate das Zertifikat manuell bestätigen. Es sei denn, du lässt dieses nicht mehr aktualisieren. Das kann man aber nur dann tun, wenn keiner der aus Punkt 2 angesprochenen Dienste konfiguriert ist. Alternativ kannst du Drive auch ohne SSL-Verschlüsselung nutzen. Solange das im Heimnetz oder im VPN bleibt, ist das nicht soo tragisch.

 

[Opoeler]

Danke, das hilft mir etwas weiter. Da ich keine Ahnung von den ganzen Zertifikats Themen habe, halte ich mich mal an die Optionen unter Punkt 2. Das iPhone und iPad habe ich auch über quickconnect verbunden, da ich auch extern Zugriff haben möchte.
Die PC‘s, die nur im Haus verwendet werden, habe ich nur über die IP konfiguriert.
Ich wollte eigentlich nur eine einfache Lösung für den Ersatz der diversen Cloud Speicher und habe die entsprechenden Tutorials von Synology angeschaut, bzw. umgesetzt.

Wieder etwas von Euch gelernt, vielen Dank dafür!
Auch wenn ich nicht alles kapiert habe

 

[plang.pl]

Mit QC ist das am einfachsten. Ich hoffe nur, du hast in der DS nicht die "automatische Routerkonfiguration" bemüht - dann ist deine DS einem hohen Risiko ausgesetzt. Wenn nicht, dann hast du bei QC eigentlich keinen großen Angriffsvektor und damit ein geringes Risiko. Vorteil: QC erkennt, wenn sich das Endgerät im gleichen Netzwerk befindet und schaltet auf direkten Datenverkehr um.
EDIT: Das Zertifikat muss in der Systemsteuerung aber auch korrekt zugeordnet sein. Am besten dort jedem Dienst das QC Zertifikat zuweisen, sofern du es nicht anders haben möchtest.

 

[Opoeler]

Du meinst die automatischen Portweiterleitungsregeln ? Die habe ich genutzt........

 

[plang.pl]

QuickConnect braucht keine Portweiterleitungen. Dann geht der Verkehr über einen Synology Relay-Server. Ist aber im Durchsatz gedeckelt. Wenn du schon Portweiterleitungen nutzt, mach diese manuell. Etliche böse Buben / Mädchen warten nur darauf, bei einem Portscan einen offenen 5000/5001er Port zu finden.

 

[Janüscht]

@Opoeler:
Du kannst es auch ordentlich machen, mit einer Handvoll Schritte mehr. Dann würdest du einen deutschen DynDNS nutzen und muss nicht den ganzen Datentransfer über den Synology Server laufen lassen. Das kann man machen, jedoch sehe ich das sehr skeptisch. Auch wenn die Sachen über SL verschlüsselt sind, fallen doch einige Metadaten an. Dazu kommt, dass Synology seit einiger Zeit einen sehr komischen und nutzerunfreundlichen eigenen Weg geht. Man sollte das immer im Hinterkopf haben und nur weil es die einfachste Lösung ist, muss sie nicht unbedingt die beste sein.

Mein Tipp. Erstelle dir einen Account bei Dynv6 aus Bremen. Dort kannst du unzählige Domains und Subdomains kostenlos erstellen. Anders als bei dem Selbstüberschätzen Dennis Schrödermit seinen IPv64.net. Der ist genauso überflüssig. Für das Zertifikat noch 3 Befehle in acme.sh und du hast für immer Ruhe und das Zertifikat erneuert sich alle 60 Tage automatisch.

Natürlich gilt das Ganze auch für eine reine IPv6-Verbindung. Wie das geht, habe ich bereits in einem anderen Thread beschrieben. Such einfach in meinen Beiträgen dazu.

 

[plang.pl]

Wenn man davon tatsächlich keine Ahnung hat und sich nicht tagelang damit befassen will, ist meiner Meinung nach QC sicherer als DynDNS. Denn mit falschen Portfarwardings holt man sich schnell ungebetene Gäste ins virtuelle Haus. Es sei denn, man hat z.B. eine FritzBox. Dann ist WireGuard VPN wohl der Königsweg.

 

[ctrlaltdelete]

Und an der Einrichtung von acme.sh wird es auch scheitern. Außerdem hatte acme.sh letztens nach einem Update einen Fehler und es wurden keine Zertifikate mehr deployed.
p.s. ich nutze Subdomains und acme.sh erfolgreich

 

[Opoeler]

Da bin ich langsam aber sicher raus. GhostVPN und Wireguard hätte ich noch........aber irgendwelche Zertifikate erstellen, manuelle Portweiterleitung einrichten, diese seltsame acme.sh ändern etc, ist mir zu hoch.
Ich bin doch nur dem Synology Video für den Ersatz der kommerziellen Clouds durch Drive auf den Leim gegangen (alles easy ohne umfangreiche Kenntnisse.....) und nun wird das Ding immer größer.

 

[Janüscht]

@plang.pl
das halte ich für eine falsche Aussage. Wenn man sich nicht mit den Basics beschäftigen will, sollte man erst keinen NAS kaufen. Wofür man bei einer Anmeldung, Portweiterleitung im Router 1 Woche braucht, ist mir schleierhaft. Das ist auch beim ersten Mal nur maximal 1h. Mehr nicht, wenn eher weniger. Für einen Geübten sind es gerade 10 Minuten incl. Wartezeit in acme.sh. Zu QC:ein kritischer User kann sich auch gerne das Whitepaper durchlesen, wo natürlich einige Fragen nicht beantwortet sind. @*kw* hatte, glaube ich, damals einmal bei Synology nachgefragt in Bezug auf die API und Zertifikatserneuerung. Das steht hier irgendwo auch noch in einem extra Thread dazu.

Viel schlimmer finde ich es, wenn die User mit einer einfachen Einrichtung schon überfordert sind, warum du jedes Mal auf Proxmox herumreitest und anpreist. Das wird langsam langweilig. Das ist hier ja kein Proxmox-Forum.

@ctrlaltdelete, das stimmt so nicht. Ich nutze acme.sh schon ewig und aktualisiere mit Watchtower immer auf die aktuelle Version. Ich musste bei keiner Verlängerung tätig werden. Acme.sh hat aber beim Deploy geändert, so ist es jetzt möglich, den TOTP oder den Namen direkt im Terminal einzugeben, bevor es deployt wurde. Den TOTP in der account.conf gibt es somit nicht mehr. Ich betone noch einmal, dass es keine Auswirkung auf den Import bei mir gab. Beiträge zu acme.sh gibt es hier genug, mit Bildern von ED. ED hat das damals auch bei mir eingerichtet und seitdem läuft es gefühlt ewig, ohne Probleme. Auch das Exportieren auf weitere externe DS über HTTPS mit 2FA funktioniert von hier.
Oft sitzt der Fehler auch vor dem Rechner. , ich weiß aber, wen ich denn fragen kann.