Keine sichere Verbindung (HTTPS) möglich (QNAP TS-453D-4)

Du denkst falsch.

Deine "sichere" Verbindung wird dir immer als "unsicher" angezeigt, weil das Zertifikat vom NAS für die HTTPS-Verbindung nicht von einer CA signiert wurde. Das müsste Chrome auch irgendwo als Erklärung ausspucken, wenn man auf die Warnung klickt.

Bei Zertifikaten geht es um vertrauen.

Da das NAS Zertifikat selber vom NAS erstellt wurde, vertraust du ihm nicht. Ich habe mir hier daher eine eigene CA aufgebaut, bei der ich das eigene Root CA auf die Clients verteile.

Dann erstellt ich Server Zertifikate für meine internen Systeme und verteile die z.B. per Import aufs NAS.

Und schon komme ich ohne Warnung auf das NAS per https.

Da Zertifikate aber seit kurzem nur noch 390 Tage gültig sein dürfen, damit alle möglichen Kisten diese akzeptieren, ist das ein wenig Aufwand, der dann 1 mal im Jahr anfällt.

Zitat von Crazyhorse

Da das NAS Zertifikat selber vom NAS erstellt wurde, vertraust du ihm nicht.

Doch, da es in meinem internen LAN steht, sonst würde ich es dort nicht einhängen. Mit deiner Logik dürftest du keinen NAS-Dienst wie z.B. DLNA oder SMB/CIFS nutzen.

Der Bockmist ist eher, dass man in Chrome anders als in anderen Browsern (z.B. Firefox) keine Ausnahme für eine lokale https-Verbindung festlegen kann. Kein normaler Heimanwender braucht in seinem privaten Heimnetz ein Zertifikat einer externen Zertifizierungsstelle. Google ist mit dieser nervtötenden Gängelung deutlich übers (eigentlich sinnvolle) Ziel hinausgeschossen.

Zitat von krp11

...hm....und wie macht man sowas? Benötigt man dazu ein Kaufprogramm?

Nein, openSSL reicht, dafür braucht man aber Linux Know-how oder testet das openSSL für Windoof.

Eine gute Beschreibung gibt es z.B. hier.

Danach habe ich mir für meine VMware Umgebung eine CA und Server Zertifikate gemacht, einfach zum testen .

Gruss

Ob du dir den Aufwand mit einem selbsterstelten Zertifikat antun willst, überlasse ich dir. Gewiss lernst du dazu. Chrome wird aber immernoch meckern, weil das Root-Zertifikat dazu im lokalen Zertifikatsspeicher liegt und nicht auf der (online) Liste der Root CA steht.

Wenn du deine Firewall im Router nicht mit Portfreigaben löchrig gemacht hast, sind wohl keine man in the middle Attacken beim lokalen Zugriff zu erwarten. Also kannst auch per HTTP auf GUI zugreifen.

Zitat von warpcam

Doch, da es in meinem internen LAN steht, sonst würde ich es dort nicht einhängen. Mit deiner Logik dürftest du keinen NAS-Dienst wie z.B. DLNA oder SMB/CIFS nutzen.

Verständnisproblem.

Ein Client traut nur Zertifikaten die von einem Root CA abstammen, welches er in seinem Store hat.

Ich habe also eins erstellt, das liegt im Store meines Clients. Mit diesem habe ich dann ein Webserver Zertifikat signiert und das inkl. privatem Key auf meinem NAS importiert.

Und schon vertraut ein Google Chrome diesem Zertifikat.

pasted-from-clipboard.png

Denn bei Zertifikatsketten geht es schlicht um vertrauen. Das ich meinem NAS vertraue steht außerfrage. Um meinem Client das jedoch als vertrauenswürdig zu verkaufen benötigt dieser einen Beweiß, dass es wirklich meins ist. Den liefere ich meinem Browser indem ich das QTS mit einem Webserverzertifikat versehe welches er meinem Client vorzeigt und dieser es mit dem von mir erstelltem Root CA prüfen kann.

Auch intern sollte man https verwenden, denn sonst werden Kennwörter im Klartext übertragen.

Rufe ich das QTS mit dem selbst erstelltem Zertifikat auf, bekomme ich die Warnung, weil er das Zertifikat für mich nicht prüfen kann. Es ist also ein Hinweis, ich soll doch bitte selber prüfen, ob ich dem System was ich aufgerufen habe vertraue. Der Chrome jedenfalls kann es nicht für mich prüfen, mehr macht in dem Fall die Zertifikatskette nicht.

Sie nimmt mir Arbeit ab, sorgt dafür, dass sich mit mit einem Zielsystem verbinde, welches auch das ist, welches ich beabsichtige zu besuchen.

Kenn ich das Zielsystem, vertraue ich diesem, dann ist mit egal ob der Browser mich vor dem nicht prüfbarem Zertifikat warnt.

Rufe ich aber eine Seite auf, sagen wir von der Sparkasse, dann bin ich drauf angewiesen, das Chrome die Seite für mich über das Zertifikat prüft. Denn ich kann nicht einschätzen ob die 185.85.0.144 die richtige Adresse ist. Chrome aber schon, denn hier wird ja ein gültiges, prüfbares Zertifikat vorgezeigt.

pasted-from-clipboard.png

Zitat von Crazyhorse

Denn bei Zertifikatsketten geht es schlicht um vertrauen. Das ich meinem NAS vertraue steht außerfrage. Um meinem Client das jedoch als vertrauenswürdig zu verkaufen benötigt dieser einen Beweiß, dass es wirklich meins ist. Den liefere ich meinem Browser indem ich das QTS mit einem Webserverzertifikat versehe welches er meinem Client vorzeigt und dieser es mit dem von mir erstelltem Root CA prüfen kann.

Und hier genau liegt das Problem dieses Clients/Browsers (Edge offenbar auch). Er akzeptiert nicht, dass ich als Nutzer des NAS ihm mitteile (bzw. er gibt erst gar nicht mehr die Möglichkeit dazu), dass das NAS ein für mich vertrauenswürdiges Zertifikat liefert, auch wenn es nur von QNAP ausgestellt ist (noch vertraue ich QNAP). Würde er das tun (so wie andere Browser, wie z.B. Firefox) dann gäbe es diese Diskussion gar nicht. Im Prinzip bedeutet das nur, ich sch... auf deinen Willen, weiß es besser und zwinge dir aus Vereinfachungsgründen etwas im reinen LAN-Betrieb Unsinniges auf. Wenn sie Ausnahmen auf interne Quell-Adressen beschränken würden, wäre schon was gewonnen. Aus Googles Sicht kann man aber annehmen, dass sie gern alle Geräte öffentlich haben wollen und deshalb diese Annahmen treffen. Besser macht es das Fehlen dieser essentiellen Funktion aber nicht, die es ja früher gab, sie wurde aber im "alles muss immer verschlüsselt sein"-Wahn ausgebaut. Man hat halt den LAN-User mit internem Webserver vergessen/ignoriert.

Mag ja sein, dass es Dir Freude bereitet, dich mit dem ganzen Zertifikatsgeraffel auseinanderzusetzen. Aber wahrscheinlich mehr als 90% der normalen Anwender haben keinen Plan davon noch irgendwie Bock darauf, sich damit so tiefgreifend zu beschäftigen oder wären dazu überhaupt in der Lage. Jetzt hast du zwar eine tolle Zertifikatskette für deinen Browser/Webserver, aber für den Rest der NAS-Kommunikationsprotokolle hilft dir das auch nicht. Außer unnötigem Mehraufwand kann ich da keinen Mehrwert erkennen, es sei denn, du betreibst das NAS als reinen Webserver offen im Internet. Die Minderheit, die das machen will, sollte sich natürlich mit dem ganzen Geraffel beschäftigen. Nur warum muss die Mehrheit der "normalen" Nutzer unter dieser Gängelung des Browsers leiden?

Aber natürlich kann Chrome das auch.

Evtl. ist es ein lokales Problem bei Dir?

Ich habe hier Chrome Version 96.0.4664.110 (Offizieller Build) (64-Bit) und werde immer genervt mit den Warnungen.

Die Seiten können aber immer ohne Probleme als Ausnahme hinzugefügt werden.

Gruss

Zitat von FSC830

Aber natürlich kann Chrome das auch.

Wie? Es gibt keine offensichtliche Möglichkeit:

pasted-from-clipboard.png

EDIT:

Aha, das ist neu (Chrome 97.0.4692.71):

pasted-from-clipboard.png

Offenbar merken sich neuere Chrome-Versionen (und Edge ebenfalls) die Ausnahme nun endlich automatisch, wenn man "weiter" auswählt.

Das gab es früher noch nicht (kann schon länger her sein, denn ich nutze mittlerweile fast nur noch Firefox), habe mir da echt 'nen Wolf gesucht. Es gab wohl zu viele Proteste oder sie haben es eingesehen .

Zitat von warpcam

Wenn sie Ausnahmen auf interne Quell-Adressen beschränken würden, wäre schon was gewonnen.

Das kann Chrome aber nicht wissen, denn hier kann auch NAT im Spiel sein und dann wird aus einer privaten IP plötzlich auf dem Gateway wieder eine public IP und damit zum Problem.

Also vertraut Chrome per default nur Zertifikaten die er auch kennt, sprich dessen Root er im Rechner Store finden kann.

Das Firefox hier anders arbeitet ja mag sein, dafür musst du das eigene Root aber auch noch mal extra im Firefox eigenem Store importieren, denn er interessiert sich nicht für den System Store.