Hallo, kann mir bitte jemand sagen oder Links schicken, wie die SSL Zertifikate, für den https Zugriff, in den Browser kommen. Werden die Zertifikate über das Browser Update heruntergeladen oder gibt es bestimmte Adressen, wo man sich neue SSL Zertifikate lädt. Danke
Beitrag #5771959 wurde vom Autor gelöscht.
Das Server-Zertifikat liefert der Webserver mit. Das zur Kontrolle erforderliche Zertifikat der Zertifizierungsstelle enthält das Betriebssystem oder der Browser. Für die Zertifikatsperrliste sorgt die Zertifizierungsstelle. https://de.wikipedia.org/wiki/Zertifikatsperrliste
:
Bearbeitet durch User
Ich habe einen uC der eine https Anfrage an einem Endpunkt sendet. Das erforderliche SSL Zertifikat habe ich im .pem Format vorliegen und kopiere den Inhalt in den uC. Wenn sich nun die URL ändert und ein neues Zertifikat erforderlich ist, welche Möglichkeiten hat der uC(Client) das neue SSL Zertifikat zu bekommen ?
Dann nochmal komplett vor vorne: Meinst du das Server-Zertifikat des angesprochenen Webservers, das Zertfikat der Zertifizierungsstelle dazu (Root-CA), ein Zwischenzertifikat dieser Zertifizierungsstelle (Intermediate-CA) oder ein Client-Zertifikat, mit dem sich der µC beim Server authentifiziert?
:
Bearbeitet durch User
Fabian P. schrieb: > welche Möglichkeiten hat der uC(Client) das neue SSL Zertifikat zu > bekommen ? Firmware update.
Fabian P. schrieb: > Das erforderliche SSL Zertifikat habe ich im .pem Format vorliegen Das root CA oder direkt eins für die spezifische Domain (Certificate pinning)? Falls ersteres, bräuchtest du alle root CAs, und müstest die halt gelegentlich aktualisieren. Falls letzteres, musst du eben dieses vorher aktualisieren. Falls du die sowieso selbst signierst, mache deine eigene kleine root CA, hinterlege das öffentliche Zertifikat, stelle sicher das das ding nicht abläuft, und signiere mit deiner CA dann jeweils Zertifikate für deine momentane Domain. Sofern deine SSL Library das überhaupt vorsieht. Client Zertifikate sind nochmal was anderes.
... und wenn der µC mangels Platz völlig anders mit Zertifikaten umgeht als der Rest der Welt, wird es schwierig, die Lösung zu erraten.
Es gäbe auch noch die Möglichkeit DANE + DNSSEC zu implementieren, dann braucht man nur die DNS Root Zertifikate. Das verfahren wird leider von Browsern nicht unterstützt.
Hall A.K Ich meine das Client Zertifikat mit dem sich der Client beim Server authentifiziert. Dieses habe ich über den Browser heruntergeladen und den Inhalt in den uC kopiert. Wenn sich nun die URL ändert und ein neues Client Zertifikat erforderlich ist, welche Möglichkeiten hat der uC(Client) das neue Client SSL Zertifikat zu bekommen ?
Fabian P. schrieb: > Ich meine das Client Zertifikat mit dem sich der Client beim Server > authentifiziert. Dieses habe ich über den Browser heruntergeladen und > den Inhalt in den uC kopiert. > > Wenn sich nun die URL ändert und ein neues Client Zertifikat > erforderlich ist, > welche Möglichkeiten hat der uC(Client) das neue Client SSL Zertifikat > zu > bekommen ? Wenn ich dich richtig verstehe und der Client der uC ist: per Firmware Update oder eine gesonderte ins-eeprom-lade-prozedur
Ein Client-Zertifikat muss nicht von der URL des Webservers abhängig sein.
:
Bearbeitet durch User
Für Mozilla sind die Root Zertifikate quasi öffentlich: https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt Werden mit den Browser Binaries verteilt. Windows hat übrigens einen eigenen Zertifikatsspeicher (den Mozilla und Chrome aber IIRC nicht nutzen) und verwaltet das Zeuchs per Windows Update.
A. K. schrieb: > Ein Client-Zertifikat muss nicht von der URL des Webservers abhängig > sein. Wollte ich auch gerade schreiben. Das Client Zertifikat ist wie ein Personalausweis. Es dient dazu, dass der Server die Identität des Clients sicher feststellen kann. Dazu muss der Client ein Zertifikat vorlegen, das der Server für vertrauenswürdig hält. Über welchen Weg der Client das Zertifikat übermittelt, spielt bei der Identitätsprüfung prinzipiell keine Rolle. Client Zertifikate muss man nicht unbedingt kaufen. Man kann sie auch einfach selbst erstellen und durch Vergleich mit dem Original (oder einer Prüfsumme) kontrollieren. Die mir bekannten Web Browser verlangen, dass Client Zertifikate von irgendwem unterschrieben wurden. Das HTTPS Protokoll schreibt die Unterschrift jedoch nicht zwingend vor. Anders ist das bei Server Zertifikaten. Denn die enthalten normalerweise einen Domänen Namen, der mit der URL im Browser verglichen wird. Wenn diese nicht übereinstimmen, meckert der Browser. Das HTTPS Protokoll erzwingt diesen Verglich nicht, aber die aktuellen Browser machen das alle sinnvollerweise, denn: Der Browser weiß überhaupt nicht, welche Server Zertifikate echt sind. Die Sparkasse könnte deinem Browser jeden Tag ein anderes Zertifikat vorlegen, ohne dass dem das verdächtig vorkommt. Er vertraut nämlich jedem Zertifikat, dass von einer bekannten Zertifizierungsstelle unterschrieben wurde. Nur die Zertifikate der relativ wenigen Zertifizierungsstellen hat der Browser zum Vergleich vorliegen, damit er deren Unterschriften prüfen kann. Also kann er letztendlich nicht das Zertifikat der Sparkasse prüfen, sondern nur die darin enthaltene Unterschrift der D-Trust GmbH. Ob das Zertifikat wirklich der Sparkasse gehört, erkennt der Browser nur ganz grob daran, dass die im Zertifikat eingetragene Domäne mit der URL überein stimmt. Das Funktionsprinzip ist ganz ähnlich dem von Dokumenten aus Papier, die man von einem Notar beglaubigen/unterschrieben lässt. Der Empfänger hält das Dokument für vertrauenswürdig, weil ein Notar es unterschrieben hat und er darauf vertraut, dass der Notar es geprüft hat. Beim Zertifikat ist das Dokument die Gesamtmenge der Infos, die im Zertifikat drin stehen. Also mindestens ein Name, oft mit Adresse und im Web vor allem mit Domäne. Die Zertifizierungsstelle spielt die Rolle des Notars, sie unterschreibt das Zertifikat, wenn sie ganz sicher ist, dass dieses Zertifikat von der richtigen Firma/Person benutzt wird. Derzeit werden Methoden evaluiert, die Gültigkeit von Zertifikaten zusätzlich zu den Unterschriften mit Hilfe von Online Diensten zu überprüfen. Die Idee ist umstritten, weil dadurch weitere Firmen die Macht bekommen, das Internet zu zensieren.
OK ich frage nochmal anders: Wenn der Firefox Browser eine Anfrage an die URL https://www.beispiel.de stellt und nicht das geforderte Client Zertifikat besitzt, bekommt der Browser(Client) keine Daten. Der Browser benötigt nun das Client Zertifikat für diese URL, woher bekommt er das?
Fabian P. schrieb: > woher bekommt er das? Von Betreiber des Servers. Der hat die Mittel, Client-Zertifikate für seinen Dienst zu erstellen.
Fabian P. schrieb: > OK ich frage nochmal anders: > > Wenn der Firefox Browser eine Anfrage an die URL > https://www.beispiel.de stellt und nicht das geforderte Client > Zertifikat besitzt, bekommt der Browser(Client) keine Daten. > Der Browser benötigt nun das Client Zertifikat für diese URL, woher > bekommt er das? Der Client erstellt einen Private Key und generiert einen CSR, der Serverbetreiber signiert es und generiert damit ein Zertifikat (also wie beim Webserverzertifikat, nur umgekehrt und nicht von einer öffentlichen CA). Bei der Anmeldung prüft der Server nun, ob das Zertifikat des Clients von der erwarteten Zertifizierungsstelle signiert ist.
Fabian P. schrieb: > Der Browser benötigt nun das Client Zertifikat für diese URL, woher > bekommt er das? Wahrscheinlich über einen anderen Weg -- hoffentlich. Es wäre sehr schlecht, wenn er es sich von der URL selbst abholen könnte. Dann könnte das nämlich auch Hinz und Kunz und der Client vom bösen Hackerwolf.
Oder anders... Das läd sich der Browser immer automatisch runter. Das ist nix was man irgendwie updaten oder speichern muss.
Ja genau. Aber wo lädt jetzt der Browser das Zertifikat herunter für diese URL?
Achim H. schrieb: > Fabian P. schrieb: > Der Browser benötigt nun das Client Zertifikat für diese URL, woher > bekommt er das? > > Wahrscheinlich über einen anderen Weg -- hoffentlich. > > Es wäre sehr schlecht, wenn er es sich von der URL selbst abholen > könnte. Dann könnte das nämlich auch Hinz und Kunz und der Client vom > bösen Hackerwolf. Neeeeiiiiinnn ;-) Das holt er sich natürlich selbst von der URL ab. Um zu verhindern das da ein böser Hacker blödsinn macht prüft der Webbrowser das Zertifikat natürlich. Aber wie das prüfen geht ist wieder ein anderes Thema (hier im Thread geht alles durcheinander, da sorgt für Verwirrung).
Wenn sich ein Client sein Zertifikat jederzeit abholen kann, ohne sich dabei ernsthaft authentifizieren zu müssen, kann man sich den Zirkus auch schenken. Normalerweise läuft das wie bei Dave4 beschrieben. Es ist zwar egal, ob der Client das selbst erledigt oder irgendwer sonst, aber das Paar aus Key und Zertifikat gehört fix auf den Client.
test schrieb: > Das läd sich der Browser immer automatisch runter. > Das holt er sich natürlich selbst von der URL ab. Nein, auf gar keinen Fall lädt sich der Client sein eigenes Zertifikat von der URL des Servers herunter. Das wäre ein grober Kunstfehler - völlig unsicher. > Um zu verhindern das da ein böser Hacker blödsinn macht prüft der > Webbrowser das Zertifikat natürlich. Du verwechselst Client Zertifikate mit Server Zertifikaten.
test schrieb: > im Thread geht alles durcheinander, da sorgt für Verwirrung). Es ist schwierig, Fragen klar zu beantworten, wenn man weder die vollständige Information hat, noch sich sich darauf verlassen kann, dass der Fragesteller das Problem richtig erfasst hat. Weshalb manche Antwort eher allgemein ausfällt, in der Hoffnung, dass der Fragesteller damit sein Problem besser sortieren kann.
test schrieb: > Oder anders... Das läd sich der Browser immer automatisch runter. Das > ist nix was man irgendwie updaten oder speichern muss. Das wäre dann das zur URL passende Server-Zertifikat, nicht aber ein Client-Zertifikat.
Stefanus F. schrieb: > Nein, auf gar keinen Fall lädt sich der Client sein eigenes Zertifikat > von der URL des Servers herunter. Das wäre ein grober Kunstfehler - > völlig unsicher. Da sehe ich jetzt kein großes Problem; das Zertifikat funktioniert ja nicht ohne den privaten Key. Der Sinn erschließt sich mir allerdings nicht ganz - vielleicht wäre es nützlich den genaueren Anwendungsfall zu kennen.
Stefanus F. schrieb: > Du verwechselst Client Zertifikate mit Server Zertifikaten. Ja, Nein, Möglich ;-) Das Problem ist das hier alles durcheinander geht und auch gar nicht klar ist was der Threadstarter eigentlich möchte. Fakt ist, wenn man eine https Seite Aufruft bekommt man automatisch der public Key dieser Seite mitgeliefert. Damit diesen public Key niemand fälschen kann ist dieser Unterschrieben (von einem "Notar"). Um diese Unterschrift zu prüfen braucht man den public Key des Notar Und dieser Notar Public Key wird mit dem Browser mitgeliefert (weil diesem einfach so irgendwo aus dem Internet zu laden wäre eine Sicherheitslücke). Sind wir uns hier alle einig?
test schrieb: > Sind wir uns hier alle einig? Ja, was die Arbeitsweise bei einem Server-Zertifikat angeht. Nur geht es demgemäss nicht darum, sondern um ein Client-Zertifikat: Beitrag "Re: Gespeicherte SSL Zertifikate im Browser" Bei einem Server-Zertifikat kann sich der Client darauf verlassen, dass er mit dem richtigen Server spricht. Bei einem Client-Zertifikat hingegen kann sich der Server darauf verlassen, dass der richtige Client mit ihm spricht. Demzufolge gehört das key/cert-Paar eines Server-Zertifikates fix auf den Server und das key/cert-Paar eines Client-Zertifikates fix auf den Client. CA-Zertifikate sind dann nochmal eine andere Baustelle.
:
Bearbeitet durch User
Trotz meiner langen Erklärung scheint es noch nicht klar zu sein. Ich möchte es mit einer Sache vergleichen, die wir alle aus der Papier-Welt kennen. Ich bin Server. An meine Türe klopf ein Client. Der Mann in grün mit Vorwerk Logo auf seiner Jacke sagt: "Guten Tag, ich bin der Herr Saugfuchs von der Firma Vorwerk. Ich möchte Ihnen ein Produkt vorstellen und dann einen Abo Vertrag abschließen". Dann sage ich: "Woher soll ich wissen, dass sie wirklich von Vorwerk kommen? Ok, sie sehen so aus, aber das reicht mir nicht". Herr Saugfuchs überreicht mit seine Visitenkarte, mit Name, Adresse und dem Vorwerk Logo. Daraufhin sage ich "Das reicht mir nicht, Visitenkarten kann jeder leicht fälschen". > Bis hierhin wurde ein unsigniertes Client-Zertifikat ausgetauscht - > was im Internet keiner macht, da nicht vertrauenswürdig. Herr Saugfuchs zeigt mir einen Personalausweis, der wie üblich mit einem amtlichen Siegel beglaubigt wurde. Der Ausweis sieht echt aus und das Siegel kenne ich, weil mein Ausweis das selbe trägt. Das genügt mir. Ich weiß jetzt zwar nicht zweifelsfrei für welche Firma der Mann arbeitet, aber ich habe seinen Namen und Adresse. Notfalls kann ich ihn anzeigen. > Nun wurde ein signiertes Client-Zertifikat ausgetauscht. Alternativ hätte Herr Saugfuchs mir auch seinen Arbeitsvertrag samt Unterschrift seines Geschäftsführer vorlegen können, aber da ich nicht weiß, wer sein Geschäftsführer ist und ich dessen Unterschrift nicht kenne, könnte ich damit wenig anfangen. > Damit der Server ein Client-Zertifkat prüfen kann, benötigt er entweder > eine Kopie des Zertifikates oder (was üblicher ist): er braucht das > Zertifikat Unterzeichners, um die Unterschriften zu vergleichen. Herr Saugnapf stellt mir sein Produkt vor, überzeugt mich und es kommt zum Vertragsabschluss. Ich unterzeichne, doch da hält er inne: "Sagen Sie mal, sind sie wirklich "der" Stefanus F. ?". "Ja sicher doch, sage ich. Kennen Sie mich nicht aus dem Fernsehen?". "Doch schon, aber vielleicht sind sie ein Double?". Daraufhin lege ich ihm meine Visitenkarte vor. Daraufhin er: "Na sie sind ja ein Vogel. Meiner Visitenkarte trauen sie nicht, aber ich soll ihrer Glauben schenken?" Jetzt habe ich meinen Ausweis blöderweise verlegt, aber ich habe eine andere Idee: Ich lege ihm meine Geburtsurkunde vor. Die hat ein Notar beglaubigt. Er schaut sich den Stempel der ausstellenden Stadverwaltung an und zuckt dann die Achseln: "Naja, ich kenne zwar den Beamten Meier aus Buxtehude nicht, aber ich vertraue trotzdem, weil er den Stempel seiner Stadt verwendet hat, und den hätte er nicht bekommen, wenn die Stadt ihm nicht vertrauen würde. > Nun haben wir ein Server-Zertifikat ausgetauscht. Hier haben wir die Besonderheit, dass er die Unterschrift nicht direkt prüfen kann, aber er vertraut dem Unterzeichner, weil der wiederum von den Behörden als Vertrauenswürdig bewertet wurde. Bei öffentlichen Zertifikaten haben wir anstelle der Behörden die root Zertifizierungs-Stellen. Die können Zertifikate unterschreiben oder anderen Firmen erlauben, Zertifikate zu unterschreiben. Wenn ein Browser ein Server Zertifikat prüft, muss er die Identität des Unterzeichners bis zu einem Root Zertifikat verfolgen können. Alle Root Zertifikate kennt er, weil er sie in deinem Speicher vorliegen hat.
A. K. schrieb: > Ja, was die Arbeitsweise bei einem Server-Zertifikat angeht. Nur geht es > demgemäss nicht darum, sondern um ein Client-Zertifikat Dieser Unterschied ist dem Threadstarter aber nicht klar, deswegen die Verwirrung. Wenn man sich als Client gegenüber dem Server ausweisen will, dann muss man dem Server etwas schicken was man mit seinem private Key verschlüsselt hat (public und private Key sind immer ein Paar). Seinen public Key schickt man dabei gleich mit. Und entweder ist dieser public Key von einem "Notar" unterschrieben (dann kann der Server ihn live prüfen). Oder man hat ihn schon mal vorher persönlich beim Server vorbei gebracht. Dann speichert der Server denit dem Vermerk "der braucht keine Unterschrift, der ist OK". Und dann kennt der Server ja deinen public Key und kann ihn immer ohne Unterschrift prüfen (durch Vergleich mit dem gespeicherten).
test schrieb: > Dieser Unterschied ist dem Threadstarter aber nicht klar, deswegen die > Verwirrung. Da ich seinen Kopf nicht aufschrauben und drin nachsehen kann, muss ich mich an diese Formulierung halten: "Ich meine das Client Zertifikat mit dem sich der Client beim Server authentifiziert." Mal angenommen, er hat den Unterschied wirklich kapiert, geht es also um ein Client-Zertifikat, nicht um ein Server-Zertifikat.
Um weitere Verwirrungen zu vermeiden würde ich empfehlen, die Keys außen vor zu lassen. Die Keys dienen hier als elektronischer Ersatz für das mittelalterliche Siegel aus Wachs, welches die Unterschrift als echt bestätigt. Ich glaube, dass man den Sinn von Zertifikaten bereits korrekt erfassen kann, wenn man von "elektronischen Unterschriften" spricht - ohne genau zu wissen, woraus diese technisch bestehen. Damit kann man sich später befassen, wenn man die Zertifikate an sich verstanden hat.
test schrieb: > Dieser Unterschied ist dem Threadstarter aber nicht klar Den Eindruck habe ich nicht. Der Unterschied scheint ihm Klar zu sein, aber einigen freundlichen Helfern nicht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.