Ich hatte soeben genau dieselben Probleme und Fragen und bin dem nun so tief ins Detail wie möglich nachgegangen. Folgendes sind meine Erkenntnisse:
1. Für QuickConnect wird der Cloud Station Client jedes Zertifikat als nicht vertrauenswürdig einstufen. Da bei QuickConnect die Verbindungen direkt über IP-Adressen und nicht über Domain Namen aufgebaut werden, kann das SSL Zertifikat nicht verifiziert werden.
2. Dasselbe gilt natürlich, wenn man direkt eine IP-Adresse für die Verbindung zur DS eingibt im Cloud Station Client.
3. Gibt man beim Verbinden mit der DS im Cloud Station Client einen Domain Name an, welcher im hinterlegten SSL Zertifikat entweder direkt als Subject Name oder aber als Alternative Subject Name angegeben ist, kann das Zertifikat verifiziert werden und wird als vertrauenswürdig eingestuft (natürlich nur, falls es auch gültig ist und eine lückenlose Chain zu einem bekannten Root CA aufweisen kann, dies ist aber bei LetsEncrypt Zertifikaten der Fall).
4. Das Zertifikat muss im Control Panel bei den Zertifikatseinstellungen dem Cloud Station Server zugewiesen werden. Diese Einstellung kopiert den Private Key, das Zertifikat und die Chain nach /usr/local/etc/certificate/CloudStation/CloudStationServer, wo sie vom Cloud Station Server gefunden werden. Achtung wichtig: Der Cloud Station Server muss neu gestartet werden, damit er das neue Zertifikat benutzt!
5. Um eine Verbindung mittels Cloud Station von extern zu ermöglichen, muss TCP Port 6690 weitergeleitet werden im Router.
6. Auf Windows kann es trotz korrekt aufgesetztem Server und Client immer noch sein, dass dem Zertifikat nicht vertraut wird. Dies hat damit zu tun, wie Microsoft Updates von Root CA Zertifikaten handhabt. Diese Updates werden on-demand geladen WENN zur Verifikation eines Zertifikats das zugehörige Root CA Zertifikat noch nicht im lokalen Root CA Zertifikatespeicher liegt UND die Windows APIs zur Verifikation benutzt werden. Leider hält sich der Cloud Station Client nicht an diese Bedingungen. Er benutzt zwar den Windows Root CA Zertifikatespeicher, aber verifiziert die Zertifikate mit einer eigenen Methode und nicht über die Windows APIs! Deshalb kann es sein, dass das Root CA Zertifikat, welches von LetsEncrypt benutzt wird, von Windows noch nicht heruntergeladen wurde und somit keine Zertifikate von LetsEncrypt mit dem Cloud Station Client verifiziert werden können.
Wieso kann aber der Browser das Zertifikat verifizieren? Ganz einfach, weil er einen eigenen Root CA Zertifikatespeicher benutzt und dieser regelmässig und unabhängig von Windows und dessen APIs aktualisiert wird.
Wie kann man Windows zwingen, ein Root CA Zertifikateupdate zu machen? Es gibt zwei Möglichkeiten: 1. Mit einem Browser von Microsoft (Edge, oder Internet Explorer) auf eine Website surfen, welche ein LetsEncrypt Zertifikat verwendet (zum Beispiel per SSL auf die DSM Oberfläche, falls diese mit einem LetsEncrypt Zertifikat verschlüsselt ist). Bei der Verifikation des Zertifikates wird der Browser das nötige Root CA Zertifikat automatisch in den lokalen Speicher importieren.2. Das fehlende Root CA Zertifikat manuell herunter laden und installieren (
https://www.identrust.com/certificates/ie.html). Dieses Zertifikat (DST Root CA X3) von IdenTrust ist ein gültiges Root CA Zertifikat für alle LetsEncrypt Zertifikate wie hier beschrieben im Abschnitt Cross Signing:
https://letsencrypt.org/certificates/. Nach einem der beiden Vorgehensweisen UND einem Neustart des Cloud Station Clients sollte das Zertifikat dann akzeptiert werden, sofern zuvor alles korrekt eingerichtet wurde.
