Gespeicherte SSL Zertifikate im Browser

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 ?

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.

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

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.

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).

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.

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?

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.

test schrieb:
> Sind wir uns hier alle einig?

Ja (was Server Zertifikate angeht).

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).

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.