Was ist ein SSL/TLS-Zertifikat konkret?

Naftali

Cadet 2nd Year
Registriert
Feb. 2021
Beiträge
23
Hallo,

damit ein Client die Authentizität des Webservers überprüfen kann, bekommt er ein Server-Zertifikat im Zuge des Three-Way-Handshakes. Das Zertifikat wurde vorher von einer Root-CA signiert. Der Client kann die Signatur mit dem öffentlichen Schlüssel der Root-CA überprüfen. Kann mir jemand sagen, was genau man als Zertifikat bezeichnet? Den öffentlichen Schlüssel der Root-CA, den man in Form eines Zertifikats herunterladen oder verteilen kann, oder das signierte Zertifikat, das beim Three-Way-Handshake übergeben wird?

Danke!
 
das zertifikat ist quasi eine datei die nur der aussteller mit seinem privaten schlüssel verschlüsselt und du mit seinem öffentlichen entschlüsselst und somit weist dass er er ist
 
  • Gefällt mir
Reaktionen: Naftali
Ich denke, zu dem Thema gibt es ne Menge guter Informationen im Netz. Da solltest du vielleicht nochmal ein wenig die Suchmaschine deines Vertrauen bemühen.

Kurz gesagt, ein Zertifikat (in dem Kontext für gewöhnlich X509) ist eine Sammlung von Informationen über eine Entität (z.B. der Webserver, mit dem du reden willst), inklusive des öffentlichen Schlüssels dieser Entität, wobei die gesamten Informationen von einer anderen, hierarchisch übergeordneten Entität signiert sind. Dabei entsteht eine Kette (chain of trust), die bis zur Wurzel (root oder root-ca) zurückführt. Dieser Wurzel muss man vertrauen und schon kann man "sicher" sein, dass man wirklich mit dem redet, mit dem man glaubt zu reden :)
 
  • Gefällt mir
Reaktionen: BeBur
Wenn ich nun in die Hände eines digitalen SSL-Zertifikats käme, das Server Alice gehört und von DigiCert signiert wurde, kann ich mich dann nicht als Alice ausgeben und ihre Identität vortäuschen und sollten nicht genau das Zertifikate verhindern?

Und wenn man die von @Yuuri genannten Quellen mal tiefer durchleuchtet, erfährt man ja auch, wie man an ein Zertifikat kommt:

[...]Der Server identifiziert sich gegenüber dem Client. Hierzu wird per Certificate ein X.509v3-Zertifikat an den Client geschickt, [...]
 
Zuletzt bearbeitet:
Naftali schrieb:
Wenn ich nun in die Hände eines digitalen SSL-Zertifikats käme, das Server Alice gehört und von DigiCert signiert wurde, kann ich mich dann nicht als Alice ausgeben und ihre Identität vortäuschen und sollten nicht genau das Zertifikate verhindern?

Wenn du an den privaten Schlüssel von Alice gelangst, ja. Dann könntest du dich glaubwürdig als Alice ausgeben. Der private Schlüssel heißt aber so, weil er grundsätzlich niemals nach draußen gegeben werden darf. Dieser darf nur dem Eigentümer bekannt sein, niemandem sonst. Würde Alice mitkriegen, dass jemand ihren Schlüssel gestohlen hat, ist dieser kompromittiert, d.h. das Key-Paar darf dann nicht mehr verwendet werden und es muss ein neues generiert werden.
Anders beim Public Key. Das ist, wie der Name sagt, ein öffentlicher Schlüssel den Alice bei jedem Seitenaufruf mit Gott und der Welt teilt. (Das muss sie auch, weil das Verfahren sonst nicht klappen würde.)
 
Signiert wird doch aber nicht mit dem privaten Schlüssel von Alice, sondern mit dem privaten Schlüssel der CA. Der Server Alice müsste dem Zertifikat, das sie den Clients schickt, irgendein selbstsigniertes Indiz beilegen. Schaut man sich aber die Bestandteile eines X.509-Zertifikats an, dann wird da ein solches Indiz nicht erwähnt.
 
Signiert wird die Kommunikation mit der Website von Alice aber wohl mit dem privaten Schlüssel dieser Website...
 
@Bob.Dig du meinst, Alice signiert mit ihrem eigenen privaten Schlüssel? Ich als Client vertraue doch aber Alice gar nicht. Signieren kann nur eine übergeordnete Instanz wie DigiCert als Beispiel. Die Kommunikation wird auch nicht signiert, sondern verschlüsselt. Verschlüsselt wird sie auch nicht mit dem privaten Schlüssel, sondern mit dem Session-Key.
 
Die Authentizität des digitalen Zertifikats von Alice wird durch die Certificate Authority (CA) sichergestellt.

Wenn Alice mit Bob über einen unsicheren Kanal wie das Internet kommuniziert, kann Bob zwar durch den öffentlichen Schlüssel sicherstellen, dass sein Gegenüber tatsächlich im Besitz des zugehörigen privaten Schlüssels ist, aber er hat erst mal keine Möglichkeit zu beurteilen, ob sein Kommunikationspartner auch wirklich Alice ist. Schließlich könnte z.B. ein Hacker die Kommunikation abfangen und mit seinem eigenen Schlüsselpaar manipulieren, d.h. er verschlüsselt Daten mit seinem eigenen Key und behauptet gegenüber Bob das sei der Key von Alice.

Um das zu verhindern braucht man eine CA. Das ist ganz einfach gesagt eine Zertifizierungsstelle, der beide Kommunikationspartner (Alice und Bob) vertrauen. Das kann z.B. eine öffentliche Behörde sein. Die CA verifiziert die Identität des Zertifikatseigentümers. Wenn nun Bob ein digitales Zertifikat erhält welches vorgibt von Alice zu stammen, kann er dessen Authentizität durch eine unabhängige vertrauenswürdige Stelle, nämlich der CA, bestätigen lassen. Wäre das übermittelte Zertifikat jedoch zwischendrin durch einen Hacker manipuliert worden, hätte es einen anderen Fingerprint (weil der Hacker den privaten Schlüssel von Alice nicht kennt). Die CA teilt Bob dann mit, dass dieses Zertifikat nicht authentisch ist, da es nicht der tatsächlichen Prüfsumme von Alice entspricht.

Ungefähr vergleichbar ist das mit dem Postident-Verfahren. Stell dir vor du möchtest bei einer Onlinebank ein Konto eröffnen. Aufgrund gesetzlicher Vorschriften (z.B. Gesetze gegen Geldwäsche) ist die Bank verpflichtet deine Identität zu verifizieren. Nun handelt es sich aber um eine Onlinebank, die keine Filiale in deiner Stadt hat, d.h. du kannst da nicht einfach hingehen und deinen Ausweis vorlegen. Daher einigt ihr (du und die Bank) euch auf eine gemeinsame CA der ihr beide gleichermaßen vertraut. Das kann z.B. die Post sein. Du gehst also nun mit deinen Ausweispapieren und Dokumenten von der Bank zu deiner nächsten Postfiliale und lässt deine Identität dort bestätigen. Wenn die Post deine Papiere geprüft hat, bestätigt sie gegenüber der Bank, dass du wirklich derjenige bist als der du dich ausgibst.
 
  • Gefällt mir
Reaktionen: Penicillin
Hier sieht man das Prinzip einer Chain of Trust. Das End Entity Zertifikat besitzt der Server Alice, der im Laufe dieses Threads zum Webserver wurde.

Nach allem was ich weiß und gelesen habe, signiert der Server das Zertifikat nicht mit seinem eigenen privaten Schlüssel. Die CA bildet vielmehr den Hash-Wert (Fingerprint) über die Zertifikatsdaten (darin enthalten der öffentliche Schlüssel von Alice) und signiert diese mit ihrem privaten Schlüssel.

Meine Frage war nun, ob man nicht das Zertifikat stehlen und die Identität von Alice vortäuschen könnte.

Ich habe eine plausible Antwort auf die Frage gefunden: Wenn ich als Man in the Middle dir (Bob) das Zertifikat (darin enthalten der öffentliche Schlüssel) von Alice als das meinige verkaufen würde, könntest du keine Nachricht von mir lesen, weil ich nicht den dazugehörigen privaten Schlüssel besitze, mit dem ich meine zukünftigen Nachricht an dich verschlüssle.

Das meintest du wahrscheinlich mit: Sie verschlüsselt mit ihrem privaten Schlüssel. Jetzt habe ich dein Post verstanden. Danke fürs Mitdenken!
 
@Naftali Habe den Thread erst heute entdeckt.

Ein Zertifikat besteht unter anderem aus einem öffentlichen und den dazugehörigen privaten Schlüssel.
Das ist bei jedem Zertifikat so, auch das bei einer CA. Du erstellst für den Server einen Zertifikatsrequest, dabei wird ein privater und öffentlicher Schlüssel nebst Zertifikatsdaten generiert. Anschließend wird das Zertifikat mit öffentlichen Schlüssel von einer CA mit ihrem privaten Schlüssel unterschrieben/signiert.

Der Unterschied zwischen CA und Serverzertifikat ist, dass der private Schlüssel vom Serverzertifikat nicht zum Signieren, sondern ausschließlich zum Entschlüsseln verwendet werden kann. Der private Schlüssel kann die Daten die mit dem dazugehörigen öffentlichen Schlüssel verschlüsselt wurden wieder entschlüsseln.

Eine HTTPS Verbindung kann man sich ganz einfach vorstellen, man hat ein Vorhängeschloss (öffentlicher Schlüssel vom Server). Dieses Vorhängeschloss schickt man jemanden im geöffneten Zustand zu (ohne Schlüssel!). Der Empfänger schreibt eine Nachricht (bei HTTPS ist es ein vom Empfänger/Client erstellter symmetrischer Schlüssel) und legt diese in eine Kiste die mit dem Vorhängeschloss gesichert (verschlüsselt) wird. Anschließen schickt er diese Kiste mit der Nachricht zurück. Keiner Unterwegs kann diese Nachricht lesen, da der passende private Schlüssel fehlt.

Du (der Server) hast den passenden Schlüssel zum Schloss. Damit kannst du die Kiste aufsperren (entschlüsseln) und die Nachricht (symmetrischer Schlüssel) lesen. Ist jedoch jemand fremdes im Besitz von dem privaten Schlüssel, dann kann er damit auf dem Versandweg jederzeit die Kiste öffnen (entschlüsseln). Mit dem nur dem Server und Client bekannten symmetrischen Schlüssel wird anschließend die Kommunikation verschlüsselt.
 
Zuletzt bearbeitet:
Zurück
Oben