Wenn ich versuche, irgendetwas über SSL zu verstehen, habe ich immer Schwierigkeiten, den Überblick zu behalten, worauf sich “Schlüssel” und “Zertifikat” beziehen. Ich fürchte, viele Leute verwenden sie falsch oder austauschbar. Gibt es einen Standardunterschied zwischen einem Schlüssel und einem Zertifikat?
Ein Zertifikat enthält einen öffentlichen Schlüssel.
Das Zertifikat enthält neben dem öffentlichen Schlüssel zusätzliche Informationen, wie z. B. den Aussteller, wofür das Zertifikat verwendet werden soll, und andere Arten von Metadaten.
Normalerweise wird ein Zertifikat selbst von einer Zertifizierungsstelle (CA) unter Verwendung des privaten Schlüssels der CA signiert. Dadurch wird die Authentizität des Zertifikats überprüft.
Diese beiden Bilder zusammen erklären mir alles:
Quelle: linuxvoice
Quelle: infosecinstitute
Nehmen wir an, Unternehmen A hat ein Schlüsselpaar und muss seinen öffentlichen Schlüssel für die öffentliche Nutzung (aka ssl auf seiner Website) veröffentlichen.
Der öffentliche Schlüssel von Firma A, der mit einem gültigen privaten Schlüssel der CA signiert ist, wird also als Zertifikat von Firma A bezeichnet.
Lassen Sie mich das anhand eines Beispiels erklären.
In einer normalen PKI, die auf einem Schlüsselpaar basiert, gibt es einen privaten Schlüssel und einen öffentlichen Schlüssel.
In einem zertifikatsbasierten System gibt es einen privaten Schlüssel und ein Zertifikat. Das Zertifikat enthält mehr Informationen als der öffentliche Schlüssel.
Demo (Sie können ein Zertifikat und einen privaten Schlüssel erzeugen): http://www.selfsignedcertificate.com/
Sie können die Datei des privaten Schlüssels und die Zertifikatsdatei herunterladen, Sie sehen, dass die Zertifikatsdatei viele Informationen enthält, wie unten gezeigt.
Sie können Ihr generiertes Zertifikat (Öffnen mit einem Texteditor) und Ihren privaten Schlüssel (Öffnen mit einem Texteditor) von dieser Website 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 das Zertifikat vom Client oder von einem vertrauenswürdigen Agenten (CA) des Clients ausgestellt wurde.
Es gibt jedoch Probleme bei einer nur auf dem privaten Schlüssel und dem Zertifikat basierenden Kommunikation.
Denn jeder kann sein eigenes Zertifikat und seinen eigenen privaten Schlüssel generieren, so dass ein einfacher Handshake nichts über den Server beweist, 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 einen Satz von einem oder mehreren Zertifikaten hat, denen er vertraut. Wenn das Zertifikat nicht in der Menge ist, ist dem Server nicht zu trauen.
Dieser einfache Ansatz hat mehrere Nachteile. Server sollten in der Lage sein, im Laufe der Zeit auf stärkere Schlüssel aufzurüsten (“Schlüsselrotation”), wodurch der öffentliche Schlüssel im Zertifikat durch einen neuen ersetzt wird. Leider muss nun die Client-App aktualisiert werden, weil sich die Konfiguration des Servers geändert hat. 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 ist auch problematisch, wenn die App mit beliebigen Servern kommunizieren muss, z. B. mit einem Webbrowser oder einer E-Mail-App.
Um diesen Nachteilen zu begegnen, werden Server typischerweise mit Zertifikaten von bekannten Herausgebern konfiguriert, die als Zertifizierungsstellen (CAs) bezeichnet werden. ie Host-Plattform (Client) enthält in der Regel eine Liste von bekannten CAs, denen sie vertraut. Ähnlich wie ein Server hat auch eine CA ein Zertifikat und einen privaten Schlüssel. Wenn sie ein Zertifikat für einen Server ausstellt, signiert die CA das Server-Zertifikat mit ihrem privaten Schlüssel. Der Client kann dann überprüfen, ob der Server ein Zertifikat besitzt, das von einer der Plattform bekannten CA ausgestellt wurde.
Die Verwendung von CAs löst zwar einige Probleme, führt jedoch ein weiteres ein. Da die CA Zertifikate für viele Server ausstellt, benötigen Sie immer noch eine Möglichkeit, um sicherzustellen, dass Sie mit dem gewünschten Server sprechen. Um dies zu beheben, identifiziert das von der CA ausgestellte Zertifikat den Server entweder mit einem bestimmten Namen wie gmail.com oder mit einem Platzhaltersatz wie *.google.com.
Das folgende Beispiel soll diese Konzepte ein wenig konkreter machen. In dem folgenden Ausschnitt aus einer Befehlszeile schaut sich der Befehl s_client des Tools openssl die Serverzertifikatsinformationen von Wikipedia an. Er 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 über Zertifikate gemäß dem X.509-Standard formatiert. Insbesondere fragt der Befehl nach dem Betreff, der die Servernamen-Informationen enthält, und dem Aussteller, der die CA identifiziert.
$ 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, die auf *.wikipedia.org passen, von der RapidSSL CA ausgestellt wurde.
Wie Sie sehen können, kann der Client aufgrund dieser zusätzlichen Informationen, die von der CA an die Server gesendet werden, leicht erkennen, 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 in der Regel das Logo der Authentifizierung und auch die öffentlichen Schlüssel, die zum Ver- und Entschlüsseln von Daten, die an den Computer gesendet werden sollen, erforderlich sind. SSL-Schlüssel Funktionen
Während einer Sitzung können mehrere SSL Schlüssel erzeugt werden. Sie werden zum Ver- und Entschlüsseln der zum und vom Computer gesendeten Daten verwendet, um sicherzustellen, dass die Daten nicht verändert oder manipuliert wurden.
Unterschied im Lebenszyklus
Zertifikate halten länger als SSL-Schlüssel. SSL-Zertifikate werden von einer Zertifizierungsstelle bezogen, die von Banken und Unternehmen regelmäßig erneuert werden kann. SSL-Schlüssel oder Sitzungsschlüssel hingegen werden einmalig während der Sitzung generiert und verworfen, wenn die Sitzung endet. Lesen Sie hier mehr
OK, lassen Sie uns das so aufschlüsseln, dass es auch Nicht-Techniker verstehen können.
Stellen Sie es sich so vor. Ein Zertifikat ist wie ein Schließfach bei Ihrer Bank. Es enthält eine Menge wichtiger Dinge; im Allgemeinen Dinge, die Ihre Identität enthalten. Das Zertifikat hat einen öffentlichen Schlüssel und benötigt einen privaten Schlüssel, um es zu öffnen.
Auch Ihr Bankschließfach braucht zwei Schlüssel zum Öffnen, genau wie ein Zertifikat.
& Bei einem Bankschließfach ist der Schlüssel der Bank wie der öffentliche Schlüssel, da er bei der Bank bleibt und der öffentliche Schlüssel beim Zertifikat bleibt. Sie haben den privaten Schlüssel, der benötigt wird, um “Ihr Zertifikat zu bekommen” und im Beispiel des Bankschließfachs wird zusätzlich zum öffentlichen Schlüssel auch der private Schlüssel benötigt.
Bevor Sie Ihr Schließfach tatsächlich öffnen können, müssen Sie zunächst Ihre Identität verifizieren (ähnlich wie bei einer Zertifikatsanforderung); sobald Sie identifiziert wurden, verwenden Sie Ihren privaten Schlüssel zusammen mit dem öffentlichen Schlüssel, um Ihr Schließfach zu öffnen. Das ist ein bisschen so, wie wenn Sie eine Zertifikatsanforderung stellen und dann Ihr Zertifikat von der Zertifizierungsstelle erhalten (solange Sie identifiziert werden können (vertrauenswürdig) und Sie den richtigen Schlüssel haben).