Hallo Forum-Mitglieder, ich muss mich zurzeit in das Thema Zertifikate und CAs einarbeiten (Schulreferat). Ich habe sämtliche Quellen durchstöbert und wollte euch mal fragen, ob ihr prüfen würdet, ob ich die Zertifizierung richtig verstanden habe. Beispielsituation: Ein Andmin möchte ein Zertifikat auf einen Webserver installieren. 1. Ablauf wie ich ihn mir vorstelle. 2. Admin generiert Schlüsselpaar, das zur Authentifizierung gegenüber dem Client dient. 3. Admin sucht Zertifizierungsstelle aus (z. B. Let's Encrypt). 4. Admin startet zum erstellen des Zertifikats den Client Certbot auf dem Webserver. 5. Admin weist die Identität des Webservers über Certbot bei Lett's Encrypt nach. 6. Certbot nimmt den privaten Schlüssel der CA und signiert damit den öffentlichen Schlüssel des Webservers. Dadurch entsteht das Zertifikat. 7. Ein Webuser installiert sich einen Browser. Dabei wird der öffentliche Schlüssel von Let's Encrypt mitinstalliert. 8. Adminuser schickt ein HTTPS-Request an Webserver. 9. Webserver schickt dem Client das Zertifikat. 10. Webuser entschlüsselt das Zertifikat mit dem öffentlichen Schlüssel der CA (Let's Encrypt. Hierdurch wird die Authentizität des Webservers bestätigt. 11. Webuser speichert den öffentlichen Schlüssel des Weservers um die Authentizität jederzeit zu prüfen.
Torben S. schrieb: > 4. Admin startet zum erstellen des Zertifikats den Client Certbot auf > dem Webserver. > > 5. Admin weist die Identität des Webservers über Certbot bei Lett's > Encrypt nach. So läuft es bei Let's Encrypt (ACME-Protokoll), bei den kostenpflichtigen CAs wird üblicherweise ein CSR (Certificate Signing Request) erzeugt und wahlweise per Web-Frontend oder per Mail übermittelt. Torben S. schrieb: > 6. Certbot nimmt den privaten Schlüssel der CA und signiert damit den > öffentlichen Schlüssel des Webservers. Dadurch entsteht das Zertifikat. Nein, Certbot ist der Client, der kann nichts signieren, sondern holt sich bei der CA das ausgestellte Zertifikat ab. Torben S. schrieb: > 7. Ein Webuser installiert sich einen Browser. Dabei wird der > öffentliche Schlüssel von Let's Encrypt mitinstalliert. Das hängt vom Browser ab, teilweise wird auch der Certificate Store des Betriebssystems verwendet. Torben S. schrieb: > 9. Webserver schickt dem Client das Zertifikat. > > 10. Webuser entschlüsselt das Zertifikat mit dem öffentlichen Schlüssel > der CA (Let's Encrypt. Hierdurch wird die Authentizität des Webservers > bestätigt. Fast. Der Webserver schickt seinen Public Key und das Zertifikat, bzw. meistens zwei Zertifikate, weil i.d.R. mit Zwischenzertifikaten gearbeitet wird: https://letsencrypt.org/images/isrg-hierarchy.png Der Public Key muss auch nicht entschlüsselt werden, der liegt in der ursprünglichen Form vor. Es wird aber natürlich geprüft, ob das Zertifikat zum Public Key (und der CN zum verwendeten Hostname) passt. Signiert wird genau genommen auch nicht der Key selbst, sondern ein Hash davon - deshalb ist es wichtig, dass die verwendeten Hash-Algorithmen sicher sind, damit niemand (mit realistischem Aufwand) ein Schlüsselpaar erzeugen kann, das zu einem bestehenden Zertifikat passt.
Dient der öffentliche Schlüssel des Webservers dazu, sich später gegenüber dem Client zu authentifizieren und wird der im Zuge des Three-Way-Handshakes ausgetauscht?
Torben S. schrieb: > Dient der öffentliche Schlüssel des Webservers dazu, sich später > gegenüber dem Client zu authentifizieren und wird der im Zuge des > Three-Way-Handshakes ausgetauscht? Für die Authentifizierung ist das Zertifikat da. Der Server sagt quasi: "Hier ist mein Public Key, und hier ist das Zertifikat, mit dem Let's Encrypt bestätigt, dass er zu www.domain.com gehört." Optional kann der Client dasselbe tun.
Torben S. schrieb: > Ich habe sämtliche Quellen durchstöbert Das glaube ich nicht mal im Ansatz. Wie weit bist du mit dem Durchlesen der entsprechenden Standards (RFCs, X.509, ...) :-) > 4. Admin startet zum erstellen des Zertifikats den Client Certbot auf > dem Webserver. Wie schon andere schrieben, eigentlich nicht. > 6. Certbot nimmt den privaten Schlüssel der CA und signiert damit den > öffentlichen Schlüssel des Webservers. Dadurch entsteht das Zertifikat. Nein und Nein. a) Der Certbot signiert gar nichts. Schon gar nicht hat oder "nimmt" er den privaten Schlüssel der CA. Die CA erstellt und signiert das Zertifikat mit ihrem privaten Schlüssel. b) Das Zertifikat besteht nicht einfach aus dem signierten öffentlichen Schlüssel. Ein Zertifikat ist ein signiertes Dokument. Im diskutierten Fall werden X.509 Zertifikate verwendet. Der Dokumenten-Teil eines X.509 Zertifikats enthält eine ganze Menge Informationen, zum Teil optional. Der öffentliche Schlüssel des Zertifikatsinhabers ist nur eine solche Information im Zertifikat. Bei einem Zertifikat für Webserver stehen zum Beispiel auch die Webserver-Hostnamen als Subject Alternative Name drin (früher als Common Name). Hier fehlt dann auch der Teil mit einem CSR. Ebenfalls fehlt der Teil in dem das Web-Server Zertifikat und der zugehörige Certificate-Chain im Webserver installiert wird (wenn die Signierung nicht durch eine Root-CA erfolgte). Der Certificate-Chain verbindet in dem Fall wenn die Signierung nicht von einer Root-CA stammt das Web-Server Zertifikat über die signierende Intermediate-CA und eventuell weitere Intermediate-CAs mit einer Root-CA. > 7. Ein Webuser installiert sich einen Browser. Dabei wird der > öffentliche Schlüssel von Let's Encrypt mitinstalliert. Nein. Dabei werden Root-Certificates (Stammzertifikate) von Root-CAs installiert. Deine CA muss aber nicht zwangsweise eine Root-CA sein, sondern kann (und ist meist) ein Intermediate-CA. Das heißt, die CA, die dein Zertifikat signiert hat, taucht in der Liste der Zertifikate für den Browser höchstwahrscheinlich nicht mal auf. > 8. Adminuser schickt ein HTTPS-Request an Webserver. Adminuser? Jeder beliebige Benutzer. > 9. Webserver schickt dem Client das Zertifikat. So grob ja. Der ganze Certificate-Chain ist auch dabei. > 10. Webuser entschlüsselt das Zertifikat mit dem öffentlichen Schlüssel > der CA (Let's Encrypt. Hierdurch wird die Authentizität des Webservers > bestätigt. Nein. Ein Zertifikat ist nicht verschlüsselt. Es ist nur digital signiert. Der Browser überprüft die Gültigkeit. Die digitale Signatur wird geprüft, die Gültigkeit, ob es für den entsprechenden Webserver ist, usw. Bei der Überprüfung der Signierung wird unter anderem geprüft ob sich das Zertifikat über die Certificate-Chain auf eine dem Browser bekannte Root-CA zurückführen lässt. > 11. Webuser speichert den öffentlichen Schlüssel des Weservers um die > Authentizität jederzeit zu prüfen. Hmmm? Verwechselst du da was und bist jetzt bei Details von TLS Sessions, besonders TLS Session Resumption?
Ein Zertifikat ist nichts anderes als ein Personalausweis mit Deiner Unterschrift und dem Stempel des Herausgebers. Da ist nichts verschlüsselt. Jeder darf dieses Ausweis lesen. Dein Gegenüber schaut sich den Ausweis an und prüft den Stempel. Erkennt er ihn und glaubt, dass der Ausweis daher echt ist, so ist alles in Ordnung. Bei einem Personalausweis ist dieser so gestaltet, dass er nur vom Herausgeber erstellt werden kann und daher "fälschungssicher" ist. Bei einem Zertifikat garantiert die Prüfsumme und die Unterschrift der CA, dass die Daten korrekt sind. Ein privater Schlüssel ist privat und wird niemals herausgegeben. Passiert das doch, ist alles für die Katz - zurück auf Los und alles nochmal machen.
Torben S. schrieb: > 2. Admin generiert Schlüsselpaar, das zur Authentifizierung gegenüber > dem Client dient. Ja. Er füllt aber auch ein Anforderungsdokument aus. Es muss auch kein Admin sein, das kann im Prinzip jeder Hansel. > 3. Admin sucht Zertifizierungsstelle aus (z. B. Let's Encrypt). Kannst Du machen. > 4. Admin startet zum erstellen des Zertifikats den Client Certbot auf > dem Webserver. Keine Ahnung, was ein Certbot ist. > 5. Admin weist die Identität des Webservers über Certbot bei Lett's > Encrypt nach. Dazu gibt es verschiedene Methoden: * Die CA schickt Dir eine Email, die Du beantworten musst - dadurch bist Du zumindest berechtigt, die Mail abzugragen. * Du musst in Deinem Nameserver einen Hash hinterlegen - Du bist also berechtigt, den Nameserver zu administrieren; er gehört also scheinbar Dir oder Du bist für die Pflege beauftragt * Dein Chef wird an seinem Arbeitsplatz angerufen und gefragt, ob das alles so korrekt ist. Die Telefonnummer holt die CA aus dem öffentlichen Telefonbuch. * etc. > 6. Certbot nimmt den privaten Schlüssel der CA und signiert damit den > öffentlichen Schlüssel des Webservers. Dadurch entsteht das Zertifikat. Wenn der den privaten Schlüssel der CA hat, kann die CA dicht machen. Nein, er schickt ein Antragsformular mit deinem öffentlichen Schlüssel zur CA. Diese prüft irgendwie Deine Berechtigung und schickt das Formular unterschrieben und gesiegelt zurück. > 7. Ein Webuser installiert sich einen Browser. Dabei wird der > öffentliche Schlüssel von Let's Encrypt mitinstalliert. Möglich. Eher aber das Zertifikat bei sich Let's Encrypt zertifizieren ließ. > 8. Adminuser schickt ein HTTPS-Request an Webserver. Kann er machen. Ee muss aber kein Admin sein. > 9. Webserver schickt dem Client das Zertifikat. Ja > 10. Webuser entschlüsselt das Zertifikat mit dem öffentlichen Schlüssel > der CA (Let's Encrypt. Hierdurch wird die Authentizität des Webservers > bestätigt. Nö. Er schaut sich das Zertifikat an und prüft nach, ob dort der gleiche Hostname drin steht, wie der Webuser in seinem Browser getippt hat. Dann schaut er noch nach, wer das Zertifikat unterschrieben hat. Die Unterschrift prüft er anhand der Liste der Zertifizierungsstellen (und deren öffentliche Schlüssel) in seinem Cache. Auch prüft er, ob das Zertifikat noch nicht abgelaufen ist (auch das steht im Zertifikat). > 11. Webuser speichert den öffentlichen Schlüssel des Weservers um die > Authentizität jederzeit zu prüfen. Nö. Das macht er nur, wenn er meint, dass das Zertifikat nicht korrekt ist und der Webuser dem widerspricht. Das sollte man aber nur in Ausnahmefällen machen (beispielsweise bei selbstsignierten Zertifikaten, denen Du traust, weil selber erstellt). Ach ja - es muss nicht zwingend eine CA beteiligt sein. Du darfst Dein Zertifikat auch selber unterschreiben. Dann brauchst Du halt "dumme", dir Dir trauen.
Torben S. schrieb: > 11. Webuser speichert den öffentlichen Schlüssel des Weservers um die > Authentizität jederzeit zu prüfen. Vorhin ganz überlesen: Das gibt es zwar auch (Certificate Pinning), ist aber unüblich und in der Praxis eher nervig als hilfreich.
Im einfachsten Fall kennt der certbot den Webserver, etwa den Apache. In dem Fall wirds sehr einfach. Der certbot erledigt dann nämlich fast alles selbst.
:
Bearbeitet durch User
Torben S. schrieb: > Beispielsituation: Ein Andmin möchte ein Zertifikat auf einen Webserver > installieren. Certbot ist ein Tool und ein Verfahren für Letsencrypt. Klassische Bezahl-Zertifizierstellen arbeiten anders als Letsencrypt, da ist mehr Handarbeit dabei. Dein Prozedere ist von beiden Verfahren inspiriert und mischt sie miteinander, wodurch du dich nur selbst verwirrst.
:
Bearbeitet durch User
Torben S. schrieb: > ich muss mich zurzeit in das Thema Zertifikate und CAs einarbeiten > (Schulreferat). > [...] > Let's Encrypt Das ist leider kein gutes Beispiel, fürchte ich, weil Let's Encrypt und Certbot verschiedene Schritt automatisieren und vor dem Nutzer "verbergen". Tatsächlich erstellt der Client ein Schlüsselpaar, also einen privaten und einen öffentlichen Schlüssel, bei dem sich der Hostname (kann auch ein Wildcard-Name wie *.example.com sein) im Canonical Name (CN) des Subject befindet, sowie eventuelle weitere Hostnamen im X509 Subject Alternative Name. Dann erstellt er aus diesem öffentlichen Schlüssel einen Certificate Signing Request (CSR) und sendet diesen an eine Certification Authority (CA). Die CA verifiziert, daß der Server tatsächlich jenem gehört, der den CSR stellt. Diese Vorgänge werden alle von Certbot automatisiert ausgeführt. Eine "richtige" CA verifiziert dabei die Identität desjenigen, der den CSR gestellt hat, während Lets Encrypt lediglich sicherstellt, daß derjenige die Kontrolle über den Server hat. Wie dem auch sei, wenn die CA diese Prüfung erfolgreich abgeschlossen hat, stellt sie ein Zertifikat aus, signiert es mit ihrem Privaten Schlüssel, und gibt es demjenigen, der den CSR gestellt hat. Der installiert das Zertifikat, seinen Privaten Schlüssel, sowie eventuelle Intermediate-Zertifikate auf seinem Webserver und konfiguriert ihn entsprechend. Die Intermediate-Zertifikate sind dabei wichtig, denn die CAs unterschreiben nicht mit ihrem Trusted Key -- also jenem Schlüssel, dem die Browser vertrauen. Anstelle dessden stellen sie sich mit diesem Schlüssel signierte Zwischenzertifikate aus, die den Signierschlüssel mit ihrem eigentlichen Trusted Key verbinden. Auf diese Weise können die Trusted Keys auf Systemen liegen, die nicht mit dem Netz verbunden sind (Air Gap Security), was eine weitere starke Sicherheitsschicht einzieht und zudem dafür sorgt, daß gebrochene Intermediate-Zertifikate zurückgezogen werden können, wenn sie kompromittiert werden sollten oder sich eine Sicherheitslücke in einem der beteiligten Verschlüsselungsalgorithmen entdeckt wird. Übrigens wird das Thema des Zurückziehens (Revoke) von Zertifikaten häufig eher stiefmütterlich behandelt; tatsächlich ist es aber so, daß alle "richtigen" CAs sogenannte Certificate Revocation Lists (CRL) veröffentlichen, in denen dann die zurückgezogenen, also: für ungültig erklärten Zertifikate aufgeführt sind. An sich müßte ein Client beim Aufbau einer TLS-Verbindung bei der CA nachfragen, ob das Serverzertifikat zurückgezogen wurde, das tun allerdings leider die wenigsten. Stattdessen prüfen die meisten Clients nur, ob das Zertifikat des Servers noch gültig ist (Ablaufdatum) und ob das Zertifikat von einer vertrauenswürdigen CA (mithin: einer, deren Trusted Certificate schon im System oder der Clientsoftware hinterlegt ist) ausgestellt wurde. Detaillierte Informationen mit allem 'drum und 'dran finden sich in "Bulletproof SSL and TLS" von Ivan Ristic, für OpenSSL im "OpenSSL Cookbook" vom selben Autor. Viel Spaß und Erfolg damit! :-)
Jemand schrieb: > Tatsächlich erstellt der Client ein Schlüsselpaar, also einen privaten > und einen öffentlichen Schlüssel, bei dem sich der Hostname (kann auch > ein Wildcard-Name wie *.example.com sein) im Canonical Name (CN) des > Subject befindet, sowie eventuelle weitere Hostnamen im X509 Subject > Alternative Name. Das ist so nicht richtig. Das Schlüsselpaar hat mit X.509 erstmal nichts zu tun, hat also auch keinen CN. Diese Informationen tauchen erst im CSR auf - und natürlich im daraufhin ausgestellten Zertifikat.
Ich frage mich gerade, wie die Signatur eines Endnutzer-Zertifikats entlang der Chain-of-Trust geprüft wird. Muss der Endnutzer alle Public Keys der CA's beesitzen, die sich in der Chain-of-Trust befinden, und die Signaturen der Intermediate-Zertifikate mit dem jeweiligen Public Key prüfen?
Torben S. schrieb: > Muss der Endnutzer alle Public Keys der CA's beesitzen Nur die Root-CAs müssen dem Client-System bekannt sein. Intermediate-CAs können von einer Webseite mitgeschickt werden, da der Client sie anhand der ihm bekannten Root-CA kontrollieren kann.
:
Bearbeitet durch User
Hallo, ich habe versucht, das was ich hier gelesen habe, noch einmal mit eigenen Worten wiederzugeben. Kann jemand prüfen, ob mein Erdachtes halbwegs korrekt ist? Mir geht’s darum, ob ich das Prinzip richtig verstanden habe, ungeachtet von technischen Details. Ich gehe beispielhaft davon aus, dass ein Endbenutzer auf einen Webserver zugreift und beim Verbindungsaufbau insgesamt drei Zertifikate bekommt: Ein Server-Zertifikat, ein Zwischenzertifikat und Root-Zertifikat. Das Server-Zertifikat ist vom Webserver signiert worden und bestätigt, dass der öffentliche Schlüssel, der beim Verbindungsaufbau zwischen den Kommunikationspartnern ausgetauscht wurde, zum Webserver gehört. Das Zertifikat enthält u. a. die Signatur und den öffentlichen Schlüssel, mit dem der Client die Signatur verifizieren kann. Der Webserver selbst besitzt ein weiteres Zertifikat, welches ihm bescheinigt, dass er der nächsthöheren Zertifizierungsstelle (CA I) trauen kann. Dies ist das Zwischenzertifikat. Darin enthalten: eine weitere Signatur und der öffentliche Schlüssel der nächsthöheren CA (CA I). Das Zertifikat wird ebenfalls dem Client übermittelt. Die Zertifizierungsstelle CA I besitzt schließlich ein Root-Zertifikat, das ihr bescheinigt, dass man der nächsthöheren CA (Root-CA) trauen kann. Das Zertifikat enthält u. a. eine Signatur, die mit dem privaten Schlüssel der Root-CA erstellt wurde. Der öffentliche Schlüssel dieser Root-CA wurde (z. B. bei der Windows- oder Browser-Installation) im Betriebssystem hinterlegt. Dieses Zertifikat wird dem Client ebenfalls beim Verbindungsaufbau übermittelt. Clientseitig prüft eine Software, ob sich die Signatur in diesem Zertifikat mit dem öffentlichen Schlüssel der Root-CA verifizieren lässt.
Torben S. schrieb: > Das Server-Zertifikat ist vom Webserver signiert worden Nö. Von der Zertifizierungsstelle. Wenn du ernste Zertifikate meinst. Für self signed certificates stimmts, aber die sind lokale Spielerei, bieten ausserhalb des eigenen Bauchnabels keine Sicherheit. > Der Webserver selbst besitzt ein weiteres Zertifikat, welches ihm > bescheinigt, dass er der nächsthöheren Zertifizierungsstelle (CA I) > trauen kann. Dies ist das Zwischenzertifikat. Zwischenzertifikate sind meist von der Root-CA selbst, nicht von Dritten. Dadurch kann diese CA den privaten Teil des Root-Zertifikats vom Netz fernhalten, weil der nur bei der Erzeugung eines Zwischenzertifikats benötigt wird. Was der internen Sicherheit der CA sehr zugute kommt. Ist ein Zwischenzertifikat verbrannt, wird es zurückgezogen und es gibt ein neues. Muss das Root-Zertifikat verworfen werden, kann der Laden eigentlich dicht machen, denn das kennt dann erst einmal niemand.
:
Bearbeitet durch User
Torben S. schrieb: > Ich gehe beispielhaft davon aus, dass ein Endbenutzer auf einen > Webserver zugreift und beim Verbindungsaufbau insgesamt drei Zertifikate > bekommt: Ein Server-Zertifikat, ein Zwischenzertifikat und > Root-Zertifikat. Üblicherweise bekommt der Client nur das Server-Zertifikat und das Zwischenzertifikat geliefert. Die Root-Zertifikate sind Bestandteil des Betriebssystems und/oder des Browsers. Torben S. schrieb: > Das Server-Zertifikat ist vom Webserver signiert worden Nein, das Zertifikat wurde von der CA ausgestellt und mit deren Zwischenzertifikat (früher auch oft direkt mit dem Root-Zertifikat) signiert. Torben S. schrieb: > Der Webserver selbst besitzt ein weiteres Zertifikat, welches ihm > bescheinigt, dass er der nächsthöheren Zertifizierungsstelle (CA I) > trauen kann. Abgesehen von der (relativ seltenen) Client-Authentifizierung per Zertifikat traut der Webserver niemandem. Er liefert das Zwischenzertifikat mit aus, damit der Browser die Hierarchie bis zum Root-Zertifikat (das ihm vorliegt) überprüfen kann. Die Hierarchie ist also von unten nach oben: Server-Zertifikat (liefert der Server) - Zwischenzertifikat (liefert der Server) - Root-Zertifikat (hat der Browser lokal vorliegen). Bei Server-Zertifikaten geht es darum, dass der Client weiss, dass er mit dem richtigen Server kommuniziert, nicht umgekehrt!
(prx) A. K. schrieb: > Torben S. schrieb: >> Das Server-Zertifikat ist vom Webserver signiert worden > > Nö. Von der Zertifizierungsstelle. Wenn du ernste Zertifikate meinst. Wikipedia meint zum Thema TLS, der Server sende dem Client ein X.509v3-Zertifikat, das eine Unterschrift von zuvor ausgetauschten Nachrichten enthält. Damit beweise der Server, dass er einen Secret-Key besitzt, der zu dem auf dem Server-Zertifikat enthaltenen Public-Key passt. Bezieht sich das auf self signed certificates? Hmmm schrieb: > Torben S. schrieb: >> Das Server-Zertifikat ist vom Webserver signiert worden > > Nein, das Zertifikat wurde von der CA ausgestellt und mit deren > Zwischenzertifikat (früher auch oft direkt mit dem Root-Zertifikat) > signiert. Mit dem Zwischenzertifikat signiert bedeutet, dass das Zwischenzertifikat mit dem privaten Schlüssel der CA verschlüsselt wurde?
Torben S. schrieb: > Hmmm schrieb: >> Torben S. schrieb: >>> Das Server-Zertifikat ist vom Webserver signiert worden >> >> Nein, das Zertifikat wurde von der CA ausgestellt und mit deren >> Zwischenzertifikat (früher auch oft direkt mit dem Root-Zertifikat) >> signiert. > Mit dem Zwischenzertifikat signiert bedeutet, dass das > Zwischenzertifikat mit dem privaten Schlüssel der CA verschlüsselt > wurde? Ein Zertifikat ist nicht verschlüsselt, sondern signiert. Für die Generierung des Server-Zertifikats wurde der zum Zwischenzertifikat gehörige private Schlüssel verwendet. Für die Generierung des Zwischenzertifikats wurde der zum Root-Zertifikat gehörige private Schlüssel verwendet, der an einem sicheren Ort verwahrt und nur sehr selten (wenn die Zwischenzertifikate ausgetauscht werden) ausgepackt wird. Das Root-Zertifikat ist self-signed und wird nur deshalb als vertrauenswürdig anerkannt, weil es mit dem Browser oder Betriebssystem ausgeliefert wird.
Torben S. schrieb: > Wikipedia meint zum Thema TLS, Vergiss diesen Wikipedia-Text und schau da vorbei: https://tls.ulfheim.net/
Hmmm schrieb: > Für die Generierung des Server-Zertifikats wurde der zum > Zwischenzertifikat gehörige private Schlüssel verwendet. Wie kann aber der Client die Signatur des Zwischenzertifikats prüfen? Er müsste über den öffentlichen Schlüssel der CA verfügen, dieser ist im Server-Zertifikat allerdings nicht enthalten. Aha! Dieser müsste aber Bestandteil des Zwischenzertifikats sein, das ja beim Verbindungsaufbau dem Client mitgeliefert wird, richtig?
Torben S. schrieb: > Wie kann aber der Client die Signatur des Zwischenzertifikats prüfen? Wie schon beschrieben, hangelt sich der Client in der Hierarchie nach oben, bis er beim Root-Zertifikat angekommen ist, und das ist lokal gespeichert. Also in etwa: "Ich kenne zwar nicht denjenigen, der das Server-Zertifikat ausgestellt hat, aber jemand, dem ich vertraue, bürgt für ihn."
Torben S. schrieb: > Wie kann aber der Client die Signatur des Zwischenzertifikats prüfen? Er > müsste über den öffentlichen Schlüssel der CA verfügen, dieser ist im > Server-Zertifikat allerdings nicht enthalten. Nein, aber im Browser bzw. Betriebssystem. Der oder das hat die Zertifikate der CAs. Diese Zertifikate enthalten jeweils den öffentlichen Schlüssel. Gib unter Windows in einem Kommandofenster mal certmgr.msc ein. Dann such dir unter "Vertrauenswürdige Stammzertifizierungsstellen" oder "Drittanbieter-Stammzertifizierungsstellen" und --> "Zertifikate" ein Zertifikat raus. Zum Beispiel eins, dass in "Beabsichtigte Zwecke" am Ende auch "Serverauthentifizierung" stehen hat. Doppelklick drauf, auf "Details", runterscrollen zu "Öffentlicher Schlüssel". Da ist der öffentliche Schlüssel der CA. Das sind die Zertifikate die Internet-Explorer und Edge kennen. Firefox verwaltet seine Zertifikate selber (irgendwo unter Optionen). Was Chrome macht weiß ich gerade nicht. > Aha! Dieser müsste aber Bestandteil des Zwischenzertifikats sein, das ja > beim Verbindungsaufbau dem Client mitgeliefert wird, richtig? Nein, du brauchst das jeweils drüber liegend Zertifikat. Ausgenommen die Root-Zertifikate. Die sind self-signed und denen muss man so vertrauen.
Hannes J. schrieb: > Nein, du brauchst das jeweils drüber liegend Zertifikat. Ausgenommen die > Root-Zertifikate. Die sind self-signed und denen muss man so vertrauen. Ich habe aus der Perspektive des Server-Zertifikats argumentiert und bin davon ausgegangen, dass das darüber liegende Zertifikat das Zwischenzertifikat ist. Hmmm schrieb: > Also in etwa: "Ich kenne zwar nicht denjenigen, der das > Server-Zertifikat ausgestellt hat, aber jemand, dem ich vertraue, bürgt > für ihn." Das würde aber auch bedeuten, dass dem Client sämtliche Zwischenzertifikate vollständig vorliegen müssten, oder? Was passiert denn, wenn in einer langen Kette aus Zwischenzertifikaten eine Unterbrechung vorhanden ist und der Client ein Zwischenzertifikat nicht zuordnen kann? Kann dann nicht der Server die fehlenden Zwischenzertifikate an den Client senden, sodass die Kette wiede rgeschlossen ist? Hannes J. schrieb: > Gib unter Windows in einem Kommandofenster mal certmgr.msc ein. Dann > such dir unter "Vertrauenswürdige Stammzertifizierungsstellen" oder > "Drittanbieter-Stammzertifizierungsstellen" und --> "Zertifikate" ein > Zertifikat raus. Zum Beispiel eins, dass in "Beabsichtigte Zwecke" am > Ende auch "Serverauthentifizierung" stehen hat. Habe ich gemacht. Danke für den Tipp. War sher aufschliussreich, allerdings steht bei mir überall nur Clientauthentifizierung bei beabsichtigte Zwecke.
Torben S. schrieb: > Das würde aber auch bedeuten, dass dem Client sämtliche > Zwischenzertifikate vollständig vorliegen müssten, oder? Normalerweise ist es genau eines, und das muss der Server mitliefern. Torben S. schrieb: > Was passiert denn, wenn in einer langen Kette aus Zwischenzertifikaten > eine Unterbrechung vorhanden ist und der Client ein Zwischenzertifikat > nicht zuordnen kann? Dann gibt's eine Fehler-/Warnmeldung.
Hmmm schrieb: > Normalerweise ist es genau eines, und das muss der Server mitliefern. bWas aber wenn es eine längere Kette an Zwischenzertifikaten ist wie in diesem Beispiel dargestellt: https://miro.medium.com/max/829/1*5MKWig_oIO-5ZomgpkzgXA.jpeg ? Kann in einem solchen Fall mehrere Zwischenzertifikate mitliefern?
Torben S. schrieb: > Kann in einem solchen Fall mehrere Zwischenzertifikate mitliefern? Genau. Ist z.B. für TLS 1.2 in RFC5246 beschrieben:
1 | This is a sequence (chain) of certificates. The sender's |
2 | certificate MUST come first in the list. Each following |
3 | certificate MUST directly certify the one preceding it. Because |
4 | certificate validation requires that root keys be distributed |
5 | independently, the self-signed certificate that specifies the root |
6 | certificate authority MAY be omitted from the chain, under the |
7 | assumption that the remote end must already possess it in order to |
8 | validate it in any case. |
Torben S. schrieb: > Kann in einem solchen Fall mehrere Zwischenzertifikate mitliefern? Er kann es nicht nur, er sollte es auch. Die SSL Labs betreiben eine Seite, die für eine angegebene URL die Möglichkeiten und Risiken der SSL-Implementierung und Konfiguration des Webservers überprüft. Wenn der Webserver nicht alle Zwischenzertifikate mitliefert, gibts einen Minuspunkt.
Torben S. schrieb: > Das würde aber auch bedeuten, dass dem Client sämtliche > Zwischenzertifikate vollständig vorliegen müssten, oder? Ja, die muss der Server liefern. > Was passiert > denn, wenn in einer langen Kette aus Zwischenzertifikaten eine > Unterbrechung vorhanden ist und der Client ein Zwischenzertifikat nicht > zuordnen kann? Dann ist das doof und der Client kann den Server nicht sicher identifizieren. Da es viele kaputte Clients und Server gibt wird in vielen Anwendungen (beliebt ist z.B. IoT-Schrott) trotzdem weiter gemacht. Bis vor ein paar Jahren haben auch viele Browser einfach weggesehen. > Kann dann nicht der Server die fehlenden > Zwischenzertifikate an den Client senden, sodass die Kette wiede > rgeschlossen ist? Er muss. Wie schon vor Wochen geschrieben: Hannes J. schrieb: > Torben S. schrieb: ... > Der Certificate-Chain verbindet in dem Fall wenn die Signierung nicht > von einer Root-CA stammt das Web-Server Zertifikat über die signierende > Intermediate-CA und eventuell weitere Intermediate-CAs mit einer > Root-CA. ... >> 9. Webserver schickt dem Client das Zertifikat. > > So grob ja. Der ganze Certificate-Chain ist auch dabei. > Habe ich gemacht. Danke für den Tipp. War sher aufschliussreich, > allerdings steht bei mir überall nur Clientauthentifizierung bei > beabsichtigte Zwecke. Der certmgr.msc hat dich ein bisschen verarscht. Zieh die Spalte "Beabsichtigte Zwecke" mal sehr breit. Hinter "Clientauthentifizierung" stehen häufig weitere Zwecke. Am besten zuerst mal den certmgr auf Vollbild und dann die Spalte so breit ziehen wie es geht.
:
Bearbeitet durch User
Was mir aber noch nicht ganz klar ist, dienen die Zwischenzertifikate dazu, mehr sichrheit zu gewährleisten, oder steckt ein kommerzieller Gedanke dahinter? Außerdem kann ich nicht ganz einsehen, warum Zertifikate irgendwie Authentizität gewährleisten. Ein "Man in the Middle" könnte die IP-Adresse des Zielservers im DNS-Server so geändert haben, dass sie auf seinen betrügerrischen Server zeigt und den kann er ja durch ein Zertifikat vertrauenswürdig machen. Wie will ein normaler Benutzer dann die Authentizität festtsellen.
Torben S. schrieb: > dienen die Zwischenzertifikate dazu, mehr sichrheit zu gewährleisten, > oder steckt ein kommerzieller Gedanke dahinter? Beitrag "Re: Digitale Zertifikate und CAs" Torben S. schrieb: > und den kann er ja durch ein Zertifikat vertrauenswürdig machen Dazu benötigt er den privaten Schlüssel zum Zertifikat mit jenem Namen, den der Client erreichen will.
Hallo, Grundsätzlich besitzen ja Zertifikate eine Signatur und einen öffentlichen Schlüssel. Dient der öffentliche Schlüssel dazu die Signatur des Zertifikats zu prüfen?
Torben S. schrieb: > Ein "Man in the Middle" könnte die > IP-Adresse des Zielservers im DNS-Server so geändert haben, dass sie auf > seinen betrügerrischen Server zeigt und den kann er ja durch ein > Zertifikat vertrauenswürdig machen. Wenn er die Kontrolle über die Domain bzw. deren Nameserver hat, helfen nur noch EV-Zertifikate. Gegenüber Let's Encrypt weist man nur nach, die jeweilige Domain zu kontrollieren. Um Routing-Tricks bei den LE-Challenges zu vermeiden, kommen die Requests von wechselnden Servern. Torben S. schrieb: > Dient der öffentliche Schlüssel dazu die Signatur des Zertifikats zu > prüfen? Einfach nochmal den Thread lesen, wurde alles schon durchgekaut.
> Grundsätzlich besitzen ja Zertifikate eine Signatur und einen > öffentlichen Schlüssel. > > Dient der öffentliche Schlüssel dazu die Signatur des Zertifikats zu > prüfen? Nein. Die Signatur kommt von der CA. Der öffentliche Schlüssel ist Teil der signierten Daten und gehört zum privaten Schlüssel des Zertifikatsinhabers. Zur Signaturüberprüfung wird der öffentliche Schlüssel der CA benötigt. Du beschäftigst dich jetzt seit über 6 Wochen mit dem Thema und hast immer noch nicht die Basics drin?
@foobar Du hast Recht und das ist auch ein Armutszeugnis für mich, aber dieses Forum ist in den meisten Fällen mein erster Ansprechpartner. Mit Zertifikatsinhaber meinst du jetzt z. B. den Server, der Inhaber des Server-Zertifikats ist? Und der öffentliche Schlüssel des Server-Zertifikats dient der Verschlüsselung zwischen Server und Client. Der Öffentliche Schlüssel des Zwischenzertifikts und des Root-Zertifikats dient der Signaturüberprüfung?
Thread beobachten
Seitenaufteilung abschalten
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.