Was ist der Unterschied zwischen einem Zertifikat und einem Schlüssel in Bezug auf SSL?

Diese beiden Bilder zusammen erklärten mir alles:

Quelle: linuxvoice

Quelle: infosecinstitut

Nehmen wir an, Firma A hat ein Schlüsselpaar und muss seinen öffentlichen Schlüssel für die öffentliche Nutzung veröffentlichen (auch bekannt als SSL auf seiner Website).

• Unternehmen A muss eine Zertifikatsanforderung (CR) an eine Zertifizierungsstelle (CA) stellen, um ein Zertifikat für sein Schlüsselpaar zu erhalten.
  
• Der öffentliche, aber nicht der private Schlüssel des Schlüsselpaares von Firma A ist Teil der Zertifikatsanforderung.
  
• Die CA verwendet dann die Identitätsinformationen von company A, um zu bestimmen, ob die die Anforderung erfüllt die Kriterien der Zertifizierungsstelle für die Ausstellung eines Zertifikats.
  Wenn die CA die Anfrage genehmigt, stellt sie ein Zertifikat an Firma A aus. Kurz gesagt signiert die CA den öffentlichen Schlüssel von Firma A mit seinem (CA ' s) privaten Schlüssel, der seine Echtheit überprüft.
  

Daher wird der öffentliche Schlüssel von Unternehmen A, der mit dem privaten Schlüssel einer gültigen Zertifizierungsstelle signiert ist, als Zertifikat von Unternehmen A bezeichnet.

Lassen Sie mich mit einem Beispiel erklären.

Im normalen schlüsselpaarbasierten PKI gibt es privaten Schlüssel und öffentlichen Schlüssel.

In einem zertifikatbasierten System gibt es einen privaten Schlüssel und ein Zertifikat. Zertifikat enthält mehr Informationen als der öffentliche Schlüssel.

Demo (Sie können ein Zertifikat und einen privaten Schlüssel generieren): http://www.selfsignedcertificate.com/

Sie können download öffnen sie die private schlüssel datei und zertifikat datei, sie sehen zertifikat datei enthält viele informationen wie unten gezeigt.

Sie können Ihr generiertes Zertifikat (Öffnen mit einem Texteditor) und Ihren privaten Schlüssel (Öffnen mit einem Texteditor) von dieser Site aus abgleichen: https://www.sslshopper.com/certificate-key-matcher.html

Wenn das Zertifikat mit dem privaten Schlüssel des Clients übereinstimmt, ist der Client sicher, dass dieses Zertifikat vom Client oder vom vertrauenswürdigen Agenten (CA) des Clients erteilt wird.

Es gibt jedoch Probleme nur bei privaten Schlüsseln und zertifikatsbasierte Kommunikation.

Weil jeder sein eigenes Zertifikat und seinen privaten Schlüssel generieren kann, beweist ein einfacher Handshake nichts über den Server, außer dass der Server den privaten Schlüssel kennt, der mit dem öffentlichen Schlüssel des Zertifikats übereinstimmt. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, dass der Client eine Menge von einem oder mehreren Zertifikaten hat, denen er vertraut. Wenn das Zertifikat nicht im Set enthalten ist, ist dem Server nicht zu vertrauen.

Es gibt mehrere Nachteile dieses einfachen Ansatzes. Server sollten im Laufe der Zeit auf stärkere Schlüssel upgraden können ("Schlüsselrotation"), wodurch der öffentliche Schlüssel im Zertifikat durch einen neuen ersetzt wird. Leider muss die Client-App jetzt aktualisiert werden, da es sich im Wesentlichen um eine Serverkonfigurationsänderung handelt. Dies ist besonders problematisch, wenn der Server nicht unter der Kontrolle des App-Entwicklers steht, z. B. wenn es sich um einen Webdienst eines Drittanbieters handelt. Dieser Ansatz hat auch Probleme, wenn die App mit Ihnen sprechen muss server wie ein Webbrowser oder eine E-Mail-App.

Um diese Nachteile zu beheben, werden Server in der Regel mit Zertifikaten von bekannten Emittenten konfiguriert, die als Certificate Authorities (CAs) bezeichnet werden. die Host-Plattform (Client) enthält im Allgemeinen eine Liste bekannter CAs, denen sie vertraut. Ähnlich wie bei einem Server verfügt eine CA über ein Zertifikat und einen privaten Schlüssel. Bei der Ausstellung eines Zertifikats für einen Server signiert die CA das Serverzertifikat mit seinem privaten Schlüssel. Der Client kann dann überprüfen, ob der Server verfügt über ein Zertifikat, das von einer der Plattform bekannten Zertifizierungsstelle ausgestellt wurde.

Bei der Lösung einiger Probleme führt die Verwendung von CAs jedoch zu einem anderen. Da die CA Zertifikate für viele Server ausstellt, benötigen Sie noch eine Möglichkeit, um sicherzustellen, dass Sie mit dem gewünschten Server sprechen. Um dies zu beheben, identifiziert das von der Zertifizierungsstelle ausgegebene Zertifikat den Server entweder mit einem bestimmten Namen wie gmail.com oder ein Wildcard - Satz von Hosts wie *.google.com.

Das folgende Beispiel macht diese Konzepte zu einem etwas konkreter. Im folgenden Snippet über eine Befehlszeile betrachtet der Befehl s_client des openssl-Tools die Serverzertifikatsinformationen von Wikipedia. Es gibt Port 443 an, da dies der Standard für HTTPS ist. Der Befehl sendet die Ausgabe von openssl s_client an openssl x509, das Informationen zu Zertifikaten gemäß dem X. 509-Standard formatiert. Insbesondere fragt der Befehl nach dem Betreff, der die Servernameninformationen enthält, und dem Aussteller, der die CA.

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

Sie können sehen, dass das Zertifikat für Server ausgestellt wurde, die *entsprechen.wikipedia.org von der RapidSSL CA.

Wie Sie sehen, kann der Client aufgrund dieser zusätzlichen Informationen, die von CA an Server gesendet werden, leicht wissen, ob er mit seinem Server kommuniziert oder nicht.

Ein SSL-Zertifikat wird von einer vertrauenswürdigen Zertifizierungsstelle bezogen, die für eine sichere Verbindung der Website bürgt . SSL-Zertifikate enthalten normalerweise das Logo der Authentifizierung und auch die öffentlichen Schlüssel, die zum Verschlüsseln und Entschlüsseln von Daten erforderlich sind, die an den Computer gesendet werden sollen. SSL-Schlüssel-Funktionen

Während einer Sitzung können mehrere SSL Schlüssel generiert werden. Sie werden zum Verschlüsseln und Entschlüsseln der Informationen verwendet, die an und vom Computer gesendet werden.Die Schlüssel werden verwendet um zu überprüfen, ob die Informationen nicht geändert oder manipuliert wurden.

Lebenszyklusunterschied

Zertifikate halten länger als SSL-Schlüssel. SSL-Zertifikate erhalten Sie von der Zertifizierungsstelle, die regelmäßig von Banken und Unternehmen erneuert werden kann. SSL-Schlüssel oder Sitzungsschlüssel hingegen werden während der Sitzung eindeutig generiert und am Ende der Sitzung verworfen.

Lesen Sie hier mehr

OK, lass uns das aufschlüsseln, damit nicht-technische Leute es verstehen können.

Denke so darüber nach. Ein Zertifikat ist wie ein Schließfach bei Ihrer bank. Es enthält viele wichtige Dinge; im Allgemeinen Dinge, die Ihre Identität enthalten. Das Zertifikat verfügt über einen öffentlichen Schlüssel und benötigt zum Öffnen einen privaten Schlüssel.

Ihr Schließfach braucht zwei Schlüssel, um es zu öffnen, genau wie ein Zertifikat.
Mit einem Safe ist der Schlüssel des Bankiers wie der öffentliche Schlüssel, da er bleibt bei der Bank und der öffentliche Schlüssel bleibt beim Zertifikat. Sie haben den privaten Schlüssel, der benötigt wird, um "Ihr Zertifikat zu erhalten" und im Beispiel des Schließfachs wird neben dem öffentlichen Schlüssel auch Ihr privater Schlüssel benötigt.

Bevor Sie Ihr Schließfach tatsächlich öffnen können, müssen Sie zuerst Ihre Identität überprüfen (eine Art Zertifikatsanforderung); Sobald Sie identifiziert wurden, verwenden Sie Ihren privaten Schlüssel zusammen mit dem öffentlichen Schlüssel, um Ihr Schließfach zu öffnen. Dies ist ein bisschen wie das Anfordern Ihres Zertifikats und das Abrufen Ihres Zertifikats von der Zertifizierungsstelle (solange Sie identifiziert werden können (vertrauenswürdig) und den richtigen Schlüssel haben).