Zertifikat ist nicht vertrauenswürdig

[dosdeclasseur]

Hallo zusammen,

ich habe eine Frage zur Konfiguration der Diskstation mit SSL-Zertifikaten - weiß aber nicht sicher, ob ich im richtigen Forum gelandet bin, oder ob es überhaupt an der Diskstation liegt.

so: ich habe mittels Let's encrypt ein Zertifikat erstellt und dieses eigebunden - funktioniert soweit so gut. Kann unter Win/Linux/Mac, etc. problemlos drauf zugreifen. Ohne dass ein Zertifikats-Fehler angezeigt wird.
An meinem alten Handy - Samsung Galaxy S2 - jedoch wird, wenn ich mittels der Synology-Apps (DSPhoto, etc.) zugreifen will folgender Fehler angezeigt: "Das SSL-Zertifikat der DiskStation ist nicht vertrauenswürdig. Dies kann bedeuten, dass es ein selbst signiertes Zertifikat ist, oder jemand versucht, Ihre Verbindung abzufangen". (Letzteres hoffe ich mal nicht.) -> auf anderen Android-Geräten im Haushalt (Sony) geht die Verbindung problemlos - kein Fehler! -> Zertifikat überprüfen ist abgewählt!

Hat jemand eine Idee woran es liegen kann?

Früher habe ich zertifikate von StartSSL verwendet -> habe mir ein neues von StartSSL ausstellen lassen -> Auf allen Geräten - mit Ausnahme des alten Galaxy S2 - geht es.... ???

(Wenn meine Frage nicht ins Forum passt bitte löschen, oder verschieben! - Danke!!!)

 

[Fusion]

Da gibt es halt Probleme mit der Vertrauenskette, vermutlich ein nicht ausgeliefertes Intermediate Zertifikat.

DSM Version, App Versions und DSM Einstellungen können auch noch Einfluß haben (Stichwort HSTS, HTTP/2, ...)

 

[dosdeclasseur]

Danke für die schnelle Antwort! - Hat mein Problem gelöst!!

War in den Einstellungen für Sicherheit: muss für Android < 5 "Zwischenkompatibilität" wählen! (Wer lesen kann ist klar im Vorteil)

 

[preheat]

Liebe Community,

ich habe ein ähnliches Problem -> mein Let's Encrypt Zertifikat wird von sämtlichen Browsern (Chrome Version 53.0.2785.143 m - Google Chrome ist auf dem neuesten Stand), Firefox (49.0.1 - neueste Version), ... etc. als nicht vertrauenswürdig angezeigt.
Fehlermeldung in Chrome: Certificate Error - There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).
DSM Version=DSM 6.0.2-8451 Update 1
Http/2 aktiviert, HSTS deaktiviert
Hat jemand eine Idee woran es liegen kann ?

Danke, Valentin

 

[Fusion]

Auf welchen Namen lautet das Zertifikat und mit welcher URL rufst du die DS auf?
ERR_CERT_COMMON_NAME_INVALID sagt, dass hier keine Übereinstimmung vorliegt.

 

[preheat]

Der Name der Zertifikats lautet auf eine URL die ich aber nicht eingebe, da ich lokal übers Heimentz zugreife)....d.h. ich gebe nur die fixe IP der DS ein.
Daher kommt der Fehler wohl....

D.h. Zertifikat für HTTPS im Heimnetz kann ich mir dann sparen, oder?

LG

 

[rednag]

Wenn Du die DS mit der internen IP ansprichst ist die Warnung klar, da dafür das Zertifikat nicht ausgestellt worden ist. Du kannst es ja von extern über die Domain probieren. Ob man jetzt ein Zertifikat im Heimnetz braucht mag ich jetzt mal ganz unverblümt anzweifeln.

 

[Fusion]

Die Meldung ist ja prinzipiell erstmal eine Warnung, weil eben was nicht "koscher" erscheint. Die Verbindung selbst wird dann aber trotzdem verschlüsselt, wenn man die Ausnahme genehmigt.
Entweder sparst du es dir intern (z.B. DSM intern nur via http aufrufen und von extern nur https / 443 weiterleiten.
Oder man nimmt intern eben auch die Domain und nicht die IP.
Falls man damit in einen Timeout oder ähnliches läuft heißt das Stichwort NAT-Loopback / DNS-Rebind-Schutz, den man je nach Router anpassen kann.
Falls das nicht geht bleibt noch der Weg via HOSTS Datei auf dem Client Rechner, oder über einen lokalen DNS server im LAN die Namensauflösung zu betreiben.
Möglichkeiten gibt es also genug...

 

[preheat]

Danke für Eure Hilfe....Aufruf mit der original URL klappt ohne Warnung
Dafür hab ich nun das Problem dass ich von extern auf die Video Station, File Station und Photo Station komme, nicht jedoch auf die Audio Station & Download Station.
HTTPS ist aktivier, und Port 5000, 5001, 5006, 443, und 80 sind weitergeleitet.
Wisst ihr woran das liegen kann?
BG

 

[Frogman]

Mal so als Hinweis: auch wenn man in der Regel seinem LAN und den Clients darin vertrauen kann, kann es in einigen Fällen durchaus sinnvoll sein, verschlüsselte Zugriffe zu verwenden - bspw. sollte man das dann tun, wenn man mit dem Client per WLAN zugreift. Es ist leichter als viele glauben, ein WLAN zu kompromittieren... und werden dann Benutzerkennungen dort unverschlüsselt verwendet, steht man schnell mit heruntergelassenen Hosen da.

 

[Fusion]

@preheat - das kann an vielem liegen. Da ja ein Teil funktioniert musst du halt den Unterschied herausfinden. Zumindest File/Video und Audio/Download arbeiten nach demselben Muster.
Wie rufst du diese denn auf? Aus dem DSM oder direkt per Browser-Link? Aliase, Ports, benutzerdefinierte Domains, Reverse Proxies, ... irgendwas eingstellt?

 

[preheat]

Ich hatte Probleme die Audio Video Download Station über die Android/IOS App aufzurufen.

Audio Station verwendet über HTTPS den selben Port wie die Weboberfläche und File Station, die ich beide ohne Probleme aufrufen kann.

Nun bin ich drauf gekommen, dass ich bei Audio Video Download Station https:// und Portnummer beim Login angeben muss - bei den anderen Apps (FileStation) musste ich das nicht...komisch...
Auf jeden Fall funktioniert es jetzt. Vielen Dank! BG