Zertifikatfehler

[Trolli]

Internet Explorer 7.
Habe aufgehört dem nachzugehen, lebe mit dem Schönheitsfehler.

Es gibt zwei Gründe für eine Zertifikatwarnung. Entweder stimmt die aufgerufene Adresse nicht mit der im Zertifikat angegebenen Adresse überein oder das Zertifikat stammt von einer Zertifizierungsstelle, die dem Browser nicht als vertrauenswürdig bekannt ist.

Den ersten Fall hast Du, wenn Du z.B. das Zertifikat auf Deine DynDNS-Adresse ausgestellt hast, und dann über die IP auf die Station zugreifst. Das kann man verhindern, indem man auch zu Hause die DynDNS-Adresse verwendet (sofern der Router das zulässt) oder indem man einfach im lokalen Netz nur HTTP verwendet (eine Verschlüsselung ist im lokalen Netz in der Regel nicht notwendig).

Sollte der Zertifikatfehler durch die Vertrauensstellung der Zertifizierungsstelle auftreten, so ist das ganz einfach zu beheben: Bei der Generierung des Zertifikats wird unter anderem die Datei ca.crt erstellt. Diese kann man einfach auf den Arbeitsrechner kopieren und über "Rechtsklick -> Zertifikat installieren" zu den vertrauenswürdigen Zertifikaten hinzufügen.

Trolli

 

[PeterG]

Ich kenne keine offizielle Zertifizierungsstelle, die kostenlose Zertifikate herausgibt.

Kommt auf den Zweck an. Zumindest für private Verwendung im email-Bereich gibt es kostenlose Zertifikate von TC Trustcenter, für SSL allerdings nicht. Nun habe ich von den Unterschieden keine Ahnung, aber könnte man nicht vielleicht für den hier erörterten Einsatzzweck so eine TC Internet ID dennoch verwenden (durch Ergänzung des Verwendungszwecks oder dergl; sorry, bin da völlig planlos, aber grundsätzlich ist doch ein Zertifikat nur eine Kombination aus öffentlichem und privatem Schlüssel; sollte da der Einsatzzweck nicht eigentlich egal sein?), geht das prinzipiell technisch überhaupt nicht (wieso?) oder wäre das Zertifikat an sich zwar ok, aber es fehlt dann aufgrund des durch den Ausgeber vorgegebenen Zweck am Abgleich mit dem Stammzertifikat?

Gruß
Peter

 

[jahlives]

Für die reine Authentifizierung würde sich prinzipiell jeder Typ eines Public/Private Key Paars eignen. Wenn ich mich recht erinnerne (ja der Informatikunterrricht ist schon ein Weilchen her ) wird bei SSL der Schlüssel neben der Authentifizierung aber auch zur Verschlüsselung der Verbindung genutzt. Von dem her muss der Schlüssel schon SSL konform sein. Ausserdem verwenden weitere Anwendungen ebenfalls die SSL Schlüssel.

Der einfachste Weg ist es (zumindest für mich) die Zertifikate seler zu signieren. Ich erstelle sie aber immer auf den DynDNS Namen. Damit habe ich wohl im LAN eine Fehlermeldung (ist mir aber egal), aber von aussen stimmt das Zert mit dem Namen der Domain überein. Da importiere ich jeweils das ca.crt der Singierungsstelle (meine eigene) in den Browser und erlaube dem Browser alle Cert dieser Stelle für alle Dienste (z.B. web und mail) als vertrauenswürdig zu benutzen.

Was es auch noch gäbe sind sogenannte Key-Signing-Parties. Soviel ich weiss werden dort aber eher PGP Schlüssel und keine SSL Schlüssel signiert

 

[itari]

Zur Frage der SSL-Verschlüsselung gibt es ne nette Wikipedia-Seite. Ganz generell darf man aber sagen, dass bei der Verschlüsselung von Netzwerkpaketen eher eine symmetrische Verschlüsselung verwendet wird, deren Key laufend geändert werden (kennen wir ja auch vom Online-Banking). Der Verbindungsaufbau (Authentifizierung) wird dagegen meist auf der Basis asymmerischer Verschlüsselungen 'abgesegnet'. Und da würden auch die Zertifikationsgeschichten wieder hineinpassen. Bei den Zertifikaten ist neben den Schlüsselpaaren ja auch noch die Bestätigung von einer Certificate Authority wichtig, das es sich um 'traubare' Schlüssel handelt. Dies ist ja der Diskussionsauslöser gewesen.

Itari

 

[PeterG]

Hi,
mit dem kostenlosen Zertifikat hat man ein als vertrauenswürdig bescheinigtes Schlüsselpaar, das auf ein Stammzertifikat zurückgeht, nur halt nicht für ssl ausgegeben ist. Daher ja meine von keiner Sachkenntnis befleckte Idee, ob man nicht dieses Zertifikat auch für die Authentifizierung beim Aufbau einer ssl-Verbindung mißbrauchen könnte, den Verwendungszweck also irgendwie erweitern?

Gruß
Peter

 

[jahlives]

Zur Frage der SSL-Verschlüsselung gibt es ne nette Wikipedia-Seite. Ganz generell darf man aber sagen, dass bei der Verschlüsselung von Netzwerkpaketen eher eine symmetrische Verschlüsselung verwendet wird, deren Key laufend geändert werden (kennen wir ja auch vom Online-Banking). Der Verbindungsaufbau (Authentifizierung) wird dagegen meist auf der Basis asymmerischer Verschlüsselungen 'abgesegnet'. Und da würden auch die Zertifikationsgeschichten wieder hineinpassen. Bei den Zertifikaten ist neben den Schlüsselpaaren ja auch noch die Bestätigung von einer Certificate Authority wichtig, das es sich um 'traubare' Schlüssel handelt. Dies ist ja der Diskussionsauslöser gewesen.

Itari

@itari
bist du sicher dass der Session Schlüssel (symmetrischer Key) laufend geändert wird? Ist es nicht so, dass der kontstant bleibt während der ganzen SSL Verbindung? Weil sonst müsste doch bei Wechsel des Schlüssels während der Verbindung der gesamte SSL Handshake zwischen Client und Server erneut durchgeführt werden.
Oder habe ich SSL falsch verstanden ?

 

[itari]

@itari
bist du sicher dass der Session Schlüssel (symmetrischer Key) laufend geändert wird? Ist es nicht so, dass der kontstant bleibt während der ganzen SSL Verbindung? Weil sonst müsste doch bei Wechsel des Schlüssels während der Verbindung der gesamte SSL Handshake zwischen Client und Server erneut durchgeführt werden.
Oder habe ich SSL falsch verstanden ?

Ich bin mir nicht ganz sicher ... ich meine der Schlüssel (z. B. 128 Bit) wird einmal ausgetauscht und dann werden Fragmente (also z. B. 32 Bit) des Schlüssels (also z. B. Bit 12-44 eines 128 Bit langen Keys) zur eigentlichen Verschlüsselung benutzt (und in der Konversation wird jeweils vorausschauend das Fenster für das nächste Fragment (Bit 42-74) übertragen, mit dem dann die Antwort wiederum verschlüsselt wird). So hatte ich das mal vor langer Zeit irgendwie in meinen Kopf bekommen, finde jetzt aber nicht auf Anhieb eine Referenz. Kann also durchaus sein, dass ich mich da irre.

Itari

 

[jahlives]

Ich bin mir nicht ganz sicher ... ich meine der Schlüssel (z. B. 128 Bit) wird einmal ausgetauscht und dann werden Fragmente (also z. B. 32 Bit) des Schlüssels (also z. B. Bit 12-44 eines 128 Bit langen Keys) zur eigentlichen Verschlüsselung benutzt (und in der Konversation wird jeweils vorausschauend das Fenster für das nächste Fragment (Bit 42-74) übertragen, mit dem dann die Antwort wiederum verschlüsselt wird). So hatte ich das mal vor langer Zeit irgendwie in meinen Kopf bekommen, finde jetzt aber nicht auf Anhieb eine Referenz. Kann also durchaus sein, dass ich mich da irre.

Itari

Dann wären die Daten aber doch nur noch 32bit verschlüsselt. Und das wäre durch Brute Force doch sehr schnell zu brechen...
ich begebe mich mal auf die Suche ob ich in den unendlichen Weiten des www etwas detaillierteres dazu finde

 

[mr. winterbottom]

Moin,

ich hänge mich hier mal dran.
Nun, ich nutze gegewärtig FF 3.x

Jetzt habe ich hier zwei DS207+. Beide habe ich mit HTTPS im DS 2.1 (FW 844) eingerichtet.
Eine DS nenne ich "SERVER" die andere "BACKUP".
Wenn ich jetzt "SERVER", mit "https://IP_VON_SERVER:5001", aufrufe werde ich gebeten das Zertikikat zu bestätigen. Somit wird mir der Zugang zun "SERVER" gewährt.
gebe ich jetzt "https://IP_VON_BACKUP:5001" am FF 3.x ein "sagt" FF 3.x das schon ein Zertifikat vom gleichen Anbieter vorliege und mir somit der zugang zu "BACKUP" verwehrt bleibt.

Analog hierzu.
Wenn ich gleiches Szenario mit dem IE 8 durchführe werde ich nur gewarnt ...

.....
> Klicken Sie hier, um diese Webseite zu schließen.
> Laden dieser Website fortsetzen (nicht empfohlen).

Wenn ich "fortsetzen" klicke kann ich ohne murren des IE 8 weiter arbeiten.

Was ist hier das Prob. und wie kann ich dieses lösen???

mr. winterbottom

 

[itari]

Nun, ich nutze gegewärtig FF 3.x

... "sagt" FF 3.x das schon ein Zertifikat vom gleichen Anbieter vorliege und mir somit der zugang zu "BACKUP" verwehrt bleibt.

Was ist hier das Prob. und wie kann ich dieses lösen???

Problem ist wohl, dass du für 2 verschiedene Server dasselbe Zertifikat verwendest - warum das aber solche Schwierigkeiten macht, kann ich dir leider auch nicht erklären.

Lösungsversuch: Geh mal im FF3 in Extras - Einstellungen - Erweitert - Zertifikate - Server - Ausnahme hinzufügen usw. ... ich glaube, dass das dein Problem lösen könnte.

Itari

 

[micha2500]

Das ist ganz normal beim Zugriff auf die Synology Station über https. Der Grund liegt darin, dass das von Synology vorinstallierte Zertifikat natürlich nicht zu Deiner eigenen DNS passt. Der Browser meldet in diesem Fall einen Zertifikatfehler. Dieser Fehler hat allerdings keine Auswirkungen auf die Funktionalität - die Verschlüsselung greift trotzdem.

Wenn Du das ändern möchtest, musst Du dir ein eigenes Zertifikat mit den Daten deines DNS selbst erstellen. Wie das geht, steht hier: http://www.synology-wiki.de/index.php/Generierung_eines_eigenen_SSL-Zertifikats

Trolli

Kurze Frage, ich versuche nach der verlinkten Anleitung zu verfahren. Der vorletzte Schritt:

• Verschieben der neuen Zertifikate an den richtigen Ort:

mv /usr/local/ssl/ca.crt ssl.crt
mv /usr/local/ssl/server.crt ssl.crt
mv /usr/local/ssl/ca.csr ssl.csr
mv /usr/local/ssl/server.csr ssl.csr
mv /usr/local/ssl/ca.key ssl.key
mv /usr/local/ssl/server.key ssl.key

lässt sich ausführen. Nach meiner Auffassung wird in der ersten Zeile die ca.crt zur ssl.crt. Im der zweiten Zeile wird die im ersten Schritt erzeugte ssl.crt (ehemals ca.crt) überschrieben durch die server.crt. Zeile 3+4 und 5+6 ebenso.

Der letzte Schritt

Die ca.crt kann nun auf den jeweiligen Client-Rechnern installiert werden. Wir kopieren diese Datei dazu zunächst ins Verzeichnis public.cp /usr/syno/etc/ssl/ssl.crt/ca.crt /volume1/public

schlägt fehl, weil es in /usr/syno/etc/ssl/ kein Verzeichnis ssl.crt und daher dort auch keine ca.crt gibt. Das sieht dann so aus:


root@DS420:/usr/syno/etc/ssl# cp /usr/syno/etc/ssl/ssl.crt/ca.crt /volume1/public


cp: cannot stat ‘/usr/syno/etc/ssl/ssl.crt/ca.crt’: Not a directory


root@DS420:/usr/syno/etc/ssl# dir


total 40


drwx------ 5 root root 4096 Feb 28 21:50 .


drwxr-xr-x 61 root root 4096 Feb 28 18:19 ..


drwxr-xr-x 3 root root 4096 Feb 28 21:49 bak


drwx------ 2 root root 4096 Feb 28 16:53 cgi.key


-r-------- 1 root root 245 May 4 2020 dh1024.pem


-r-------- 1 root root 424 May 4 2020 dh2048.pem


-r-------- 1 root root 769 Apr 14 2020 dh4096.pem


-rw-r--r-- 1 root root 981 Feb 28 21:48 ssl.crt


drwx------ 2 root root 4096 Feb 28 21:50 ssl.csr


-rw-r--r-- 1 root root 887 Feb 28 21:47 ssl.key

Ist da etwas falsch?

 

[Tommi2day]

Gratulation fürs finden, Der Thread ist schon mehr als 10 Jahre alt.
Bei den aktuellen DS Versionen geht man in der Systemsteuerung zu Sicherheit->Zertifikat und kann da sein Zertifikat hochladen und das neue Zertifikat anschliessend zum Standardzertifikat machen. Das hat auch den Vorteil, das es das nächste DSM Update überlebt

 

[micha2500]

Ah, ich habe da nur ein Zertifikat von Synology drin. Ein Abruf bei Let`s Encrypt scheitert, weil die Eingaben nicht akzeptiert werden. Ziel ist, dass beim Browseraufruf die Warnung verschwindet. Gibt es eine Anleitung für Doofe?

 

[Tommi2day]

Äh, was soll man da noch sagen. Das richtige Zertifikat hast Du ja scheinbar schon erstellt, das was Du oben reinkopieren wolltest. Also Hinzufügen, crt File und key datei angeben, kkgfls noch das CA/intermediate Zertifikat zufügen und speichern. Dann den neuen Eintrag als Standardzertifikat festlegen. Wenn das Zertifikat OK war, ist auch die Warnung weg
Zum Thema Letsencrypt gibt es hier auch noch eine Reihe Threads. Man sollte natürlich schon wissen, wie das mit den Zertifikaten grundsätzlich funktioniert. Auch da hilft die Suchmaschine

 

[micha2500]

Den Zugriff über eine dyndns-Adresse mit entsprechenden Zertifikat habe ich hinbekommen. Das ist ganz nett, aber ich benötige den Zugriff von extern nicht. Ich sehe das eher als ein zusätzliches Sicherheitsrisiko. Für den Aufruf der IP aus dem Heimnetzwerk funktioniert das Zertifikat natürlich nicht (die IP ist ja auch nicht hinterlegt und bei der Erstellung auch nicht hinterlegbar). Gibt es hier auch eine Lösung, um die Box nur für internen Zugriff eingerichtet ohne Zertifikatswarnung zu betreiben?