it-swarm.com.de

Überprüfung der SSL-Zertifikatskette

Nachdem ich viele Artikel gelesen und viele Tutorials angesehen hatte, entschied ich mich, genau zu sein, da es einige Dinge über Überprüfung der SSL-Zertifikatskette gibt und Überprüfung der SSL-Zertifikate im Allgemeinen , die ich nicht gegen alle überprüfen konnte Tutorials, die ich gelesen habe und die ich nicht gesehen habe.

FALL 1:

Lassen Sie mich einen Fall annehmen, in dem ich ein Zertifikat von Verisign besitze. Nach dem Überprüfungsprozess haben sie mir ein öffentliches/privates Schlüsselpaar gegeben.

Mein Server sendet den öffentlichen Schlüssel (mein Zertifikat) an den Browser. Der Browser besitzt eine Kopie des öffentlichen Schlüssels Verisign .

Die folgenden Fragen mögen dumm erscheinen, aber es gibt keine Übereinstimmung zwischen den Tutorials und jedes Mal, wenn ich zu verstehen versuche, bin ich in eine andere Ecke geraten.

  • Wie wird der Browser mit Verisign public key erkennen, dass mein öffentlicher Schlüssel tatsächlich ein gültiger Verisign Schlüssel ist, der zum Verschlüsseln von Nachrichten verwendet werden kann, die mein Verisign privater Schlüssel kann entschlüsseln? Ich gehe davon aus, dass es sich um die Verisign public key digitale Signatur handelt, die gegen den Server getestet wird öffentliche Signatur digitale Signatur ? , Ich kann mich irren , aber selbst wenn ich Recht habe, freue ich mich über ein bisschen Klarstellung.
  • Für den Fall, dass tatsächlich die digitale Signatur getestet wird, gehe ich davon aus, dass es eine Beziehung zwischen allen Verisign öffentlichen Schlüsseln gibt? Oder vielleicht gibt es nur eine Beziehung zwischen jedem öffentlichen Schlüssel Verisign einem bestimmten Client (Website/Gerät/etc) und dem öffentlichen Schlüssel den Browser/das Betriebssystem einschließlich zuweisen.

FALL 2:

Zwischenzertifikate.

  • Ich verstehe, dass die Notwendigkeit für sie Sicherheit ist, so dass der private Schlüssel der Stammzertifizierungsstelle offline bleiben kann, wenn es weitere Gründe gibt, die ich gerne über sie hören würde.
  • In Bezug auf die Kettenüberprüfung gehe ich davon aus, dass der öffentliche Schlüssel des Servers digitale Signatur gegen den Server getestet wird Zwischenzertifikat Digitale Signatur , wenn er jetzt gültig ist, ist das Zwischenzertifikat an der Reihe Digitale Signatur , die mit der vorinstallierten öffentlichen Signatur des öffentlichen Schlüssels Browser/Betriebssystem getestet werden soll , und wenn dies auch gültig ist, hat der Client sowohl das Zwischenzertifikat als auch den öffentlichen Schlüssel des öffentlichen Schlüssels erfolgreich validiert Server.

Ich weiß, dass ich wahrscheinlich alles verpasst habe. Wenn mir jemand helfen kann, bin ich sehr dankbar.

17
Aviel Fedida

Mir ist überhaupt nicht klar, was du nicht verstehst, also werde ich es sehr langsam angehen.

Zuerst eine Terminologie. Es ist wichtig, dies klar zu machen, da Sie sonst nicht richtig wissen können, was Sie hören und sagen.

Schlüsselpaar: a privater Schlüssel und ein entsprechender öffentlicher Schlüssel, die mathematisch verwandt sind und für Kryptographie mit öffentlichem Schlüssel verwendet werden (PKC) auch genannt asymmetrische Kryptographie. Für RSA, die normalerweise die einzige PKC ist, die jemand kennt, wenn er sie nicht angibt, besteht der öffentliche Schlüssel aus einem Modul N, der das Produkt zweier großer Primzahlen ist, und einem öffentlichen Exponenten E, der klein sein kann und normalerweise klein ist (tatsächlich) es ist normalerweise entweder 3 oder 65537); der private Schlüssel enthält mindestens N und einen privaten Exponenten D, so dass E x D = 1 mod phi (N); In der Praxis enthält der private Schlüssel häufig zusätzliche Werte, die eine schnellere Berechnung ermöglichen. Es gibt jedoch noch einige andere Fragen, sodass ich sie nicht wiederholen werde.

Digitale Signatur: ein Wert, der für einen bestimmten Datenblock (fast immer ein Hash der "echten" Daten) unter Verwendung eines privaten Schlüssels berechnet wurde, sodass der entsprechende öffentliche Schlüssel verwendet werden kann, um zu bestimmen, ob der Die angegebene Signatur ist für die angegebenen Daten korrekt und konnte nur mit dem angegebenen privaten Schlüssel generiert werden. Auf diese Weise kann der Prüfer feststellen, dass die Daten nicht geändert oder gefälscht wurden und die Daten vom Inhaber des privaten Schlüssels gesendet oder zumindest gesehen wurden, sagt jedoch nichts darüber aus, wer dieser Inhaber ist.

(X.509 aka PKIX) (Identity) -Zertifikat: eine Datenstruktur mit einem öffentlichen Schlüssel für eine Entität ​​und die Identität dieser Entität; sowie einige andere Informationen in Bezug auf das Unternehmen und/oder die Zertifizierungsstelle; alle von einer (im Allgemeinen) anderen Entität unterzeichnet, die als Certificate Authority oder CA bezeichnet wird. Ich hoffe, Sie meinten Verisign nur als Beispiel; es ist eine Zertifizierungsstelle, aber nicht die einzige; Sie können ein ebenso gutes Internet-Zertifikat von anderen wie GoDaddy, Comodo, erhalten. StartCom LetsEncrypt usw. Wenn Sie einer bestimmten Zertifizierungsstelle vertrauen, dass sie Zertifikate korrekt ausstellt, können Sie der viel größeren Anzahl öffentlicher Schlüssel und Identitäten in den von ihr ausgestellten Zertifikaten vertrauen. Update 2017 : StartCom ist nicht mehr gut, da es von WoSign gekauft wurde, der dann beim Verstoß gegen die CABforum-Regeln ertappt wurde und jetzt weitgehend misstrauisch . OTOH LetsEncrypt ist jetzt weithin vertrauenswürdig und kostenlos. Was die Wichtigkeit mehrerer Zertifizierungsstellen weiter unterstreicht!

Benutzerzertifikat (Endentität): ein Zertifikat, das den Schlüssel und die Identität für etwas anderes als eine Zertifizierungsstelle enthält, z. B. einen SSL-Server, einen SSL-Client, ein Mailsystem usw.

(CA) Stammzertifikat: ein Zertifikat, das den öffentlichen Schlüssel einer Stammzertifizierungsstelle enthält. Da sich keine CA "über" dem Stamm befindet, wird eine Dummy-Signatur verwendet, die den eigenen privaten Schlüssel der CA verwendet, die jedoch keinen Sicherheitswert hat. Sie müssen entscheiden (oder delegieren), ob Sie diesem Schlüssel "out of band" vertrauen möchten, dh aus anderen Gründen als kryptografischen Berechnungen.

Ketten- oder Zwischenzertifikat (und Zertifizierungsstelle): (wie Ihre Frage zeigt) Die meisten Zertifizierungsstellen arbeiten jetzt hierarchisch, wobei der Stammschlüssel nicht zum direkten Ausstellen von Benutzerzertifikaten verwendet wird. Stattdessen werden die Stammzertifizierungsstelle und ihr Stammschlüssel (privater Schlüssel) zum Signieren von Zertifikaten für mehrere Zwischen- oder untergeordnete Zertifizierungsstellen verwendet, von denen jede über ein eigenes Schlüsselpaar verfügt. Jede Zwischenzertifizierungsstelle kann dann Benutzerzertifikate oder manchmal eine zweite Ebene von Zwischenzertifikaten ausstellen. Dies kann auf mehrere Ebenen erweitert werden, wird aber nur sehr selten benötigt.

Da Sie einen Browser erwähnen, beschäftigen Sie sich anscheinend (nur?) Mit Zertifikaten (und Schlüsseln) für HTTPS (HTTP über SSL/TLS). Dies ist eine häufige und wichtige Verwendung von Zertifikaten und PKC, jedoch nicht die einzige.

Nun, Fall 1. Da dieser Fall Kette/Zwischenstufe nicht berücksichtigt und Verisign dies verwendet, verwende ich stattdessen eine hypothetische SimpleCA. Erstens hat no CA jemals Ihren privaten Schlüssel oder sendet Ihnen diesen. Sie generieren Ihr Schlüsselpaar und senden Ihren öffentlichen Schlüssel an die Zertifizierungsstelle in einer Datenstruktur namens Certificate Signing Request ​​oder CSR . Die CSR sollte auch Ihren Namen enthalten. Bei einem SSL-Server ist dies normalerweise der Domänenname (FQDN) des Servers. Die CSR enthält einige andere Daten, die Sie vorerst ignorieren können. Die Zertifizierungsstelle überprüft Ihre beanspruchte Identität (für SSL-Server, dass Sie den angegebenen Domänennamen "kontrollieren"), erhebt normalerweise eine Gebühr und erstellt dann ein Zertifikat, das Folgendes enthält:

  • ihr Name (hier FQDN des SSL-Servers) als Subject ​​und/oder ein oder mehrere Namen als SubjectAlternativeNames insbesondere in den letzten Jahren
  • ihr öffentlicher Schlüssel als SubjectPublicKey und normalerweise ein Hash davon als SubjectKeyID
  • a ValidityPeriod Angabe, wie lange das Zertifikat gültig ist, ausgewählt von der Zertifizierungsstelle, teilweise basierend darauf, wie viel Sie bezahlen
  • der Name des CA als Aussteller und normalerweise ein AuthorityKeyID, der auch die Zertifizierungsstelle identifiziert
  • einige andere Daten, die Sie vorerst ignorieren können

diese gesamte Struktur wird mit dem privaten Schlüssel der Zertifizierungsstelle signiert (was bedeutet, dass sie mit dem öffentlichen Schlüssel der Zertifizierungsstelle überprüft werden kann). Die Zertifizierungsstelle sendet dieses Zertifikat an Sie zurück, um es zusammen mit dem bereits vorhandenen privaten Schlüssel auf Ihrem Server zu verwenden.

Unter der Annahme, dass SimpleCA gezeigt hat, dass es vertrauenswürdig ist, Bewerber angemessen zu überprüfen und eine Gebühr zu zahlen, haben die Browser-Anbieter (Microsoft, Mozilla, Google, Apple usw.) zuvor zugestimmt, ihren öffentlichen Schlüssel in ihre Browser aufzunehmen. normalerweise in Form des SimpleCA-Stammzertifikats. Wenn nun ein Browser eine Verbindung zu Ihrem Server herstellt und Sie Ihr Zertifikat mit der Aufschrift "Von SimpleCA genehmigter Aviel-Server" senden, findet der Browser das Stammzertifikat von SimpleCA und damit den öffentlichen Schlüssel von SimpleCA und verwendet dieses, um - Verifizieren dass Ihr Zertifikat ​​korrekt signiert ist, nd dass der Servername in Ihrem Zertifikat mit dem Server in der vom Benutzer gewünschten URL übereinstimmt; Wenn beide erfolgreich sind, akzeptiert es den öffentlichen Schlüssel in Ihrem Zertifikat ​​als den richtigen öffentlichen Schlüssel für Sie und verwendet ihn, um den SSL/TLS-Handshake abzuschließen. Wenn nicht, wird eine Warnung oder ein Fehler angezeigt.

Es sei denn, das heißt, Ihr Zertifikat war widerrufen. Wenn Ihr privater Schlüssel kompromittiert ist oder wenn die Zertifizierungsstelle feststellt, dass Sie die beanspruchte Identität nicht mehr kontrollieren (auch wenn sie feststellen, dass Sie sie in der Anwendung nie getäuscht haben), veröffentlicht die Zertifizierungsstelle, dass Ihr Zertifikat widerrufen wird und Browser dies daher nicht tun Vertrauen Sie ihm, obwohl die Signatur noch überprüft wird (da die RSA-Berechnung ein fester mathematischer Prozess ist, der unabhängig von Zeit oder Umgebung ist). Aber Widerruf, und ob und wann und wie gut er funktioniert, ist ein kompliziertes Thema für sich, und diese Antwort ist bereits groß genug. (Bearbeiten) Wie funktioniert das OCSP-Heften? deckt den Widerruf (eigentlich sowohl OCSP als auch CRLs) mit Ursin-Gründlichkeit ab. Wenn Ihr Zertifikat abgelaufen ist (nach Ablauf der Gültigkeitsdauer), ist es ebenfalls ungültig. Dieser ist für den Browser leicht zu überprüfen. Formal kann ein Zertifikat auch vor Beginn seiner Gültigkeitsdauer ungültig sein. In der Praxis stellen Zertifizierungsstellen jedoch keine nachträglichen Zertifikate aus, es sei denn, jemand hat die Zeitzone oder etwas anderes durcheinander gebracht.

Der in einem Browser bereitgestellte Satz von CA-Stammzertifikaten ist jedoch normalerweise nur der Standard. Der Browser-Benutzer kann entscheiden, ob er neue Roots hinzufügen oder vorhandene löschen möchte, wenn er dies wünscht. Und wenn ja, kann dies dazu führen, dass Ihr Server vertrauenswürdig ist, wenn er nicht vorher war, oder nicht vertrauenswürdig, wenn er vorher war.

Fall 2 (Kette). Ein Grund für Zwischenzertifizierungsstellen und damit Zwischen- oder Kettenzertifikate besteht darin, den Stammschlüssel wie gesagt offline zu halten. Ein weiterer Grund besteht darin, dass die Zwischenzertifizierungsstellen ähnlich wie Benutzer verwaltet werden können: Sie können begrenzte Gültigkeitszeiträume haben und erneuert werden. Wenn sie kompromittiert werden (oder einfach nicht mehr gewünscht werden), können sie widerrufen werden. Dies geschieht automatisch und nahezu unsichtbar. Wenn Sie andererseits einen Stamm erweitern, ersetzen oder widerrufen müssen, muss grundsätzlich jeder Browser auf der Welt aktualisiert werden. Das ist eine Menge Arbeit und wird nie vollständig erledigt, da Benutzer die Installation eines Updates ablehnen oder vergessen und einer nicht sicheren Zertifizierungsstelle und damit wahrscheinlich nicht legitimen Servern vertrauen. Auch für Widerrufe, die auf ältere Weise unter Verwendung einer Zertifikatsperrliste (Certificate Revocation List, CRL) veröffentlicht werden, die die ausgestellten Zertifikate auf mehrere Zwischenzertifizierungsstellen verteilt, erleichtert die CRL-Verwaltung.

Mit einem einzelnen Zwischen-/Kettenzertifikat wird der Prozess wie folgt geändert. Angenommen, VerisignServerB wird unter VerisignRoot ​​ausgegeben und wird wiederum zur Ausgabe von Aviel-Server verwendet. (Die tatsächlichen Namen sind länger, aber dies ist leichter zu erkennen.) Dann ist Ihr Server so konfiguriert, dass sowohl Aviel-Server als auch VerisignServerB an den Browser gesendet werden. Der Browser überprüft, ob der VerisignServerB cert ​​unter dem VerisignRoot public key (wie zuvor, normalerweise als selbstsigniertes Stammzertifikat gespeichert) korrekt signiert ist UND ob der Aviel-Server cert ​​ist unter VerisignServerB public key von diesem Zertifikat korrekt signiert, und dieser Aviel-Server cert name stimmt mit dem gewünschten überein. Es spielt keine Rolle, in welcher Reihenfolge die Signaturen geprüft werden, solange beide.

SSL Certificate Framework 101: Wie überprüft der Browser tatsächlich die Gültigkeit eines bestimmten Serverzertifikats? hat ein schönes grafisches Beispiel dafür, das Ihnen helfen kann.

Bei Verwendung mehrerer Zwischen-/Kettenzertifikate sollte die Erweiterung jetzt offensichtlich sein.

38

Wie erkennt der Browser mit dem öffentlichen Verisign-Schlüssel, dass mein öffentlicher Schlüssel tatsächlich ein gültiger Verisign-Schlüssel ist, der zum Verschlüsseln von Nachrichten verwendet werden kann, die mein privater Verisign-Schlüssel entschlüsseln kann?

Es muss nur die Signatur von Verisign überprüft werden. Die Unterschrift von Verisign auf Ihrem Zertifikat ist ein Beweis dafür, dass das Zertifikat wirklich von Verisign stammt und beispielsweise nicht auf Ihrem Computer hergestellt wurde. Die Signatur ist einfach eine Nachricht, die mit ihrem privaten Schlüssel signiert ist. Da der private Schlüssel nur den zugehörigen öffentlichen Schlüssel entschlüsselt (dies funktioniert auf beide Arten), kann der Browser diese Signatur mit seinem öffentlichen Schlüssel entschlüsseln (da er öffentlich ist, kann jeder eine Kopie davon erhalten und sie ist in Ihrem Zertifikat enthalten , also bekommt der Browser es von dort). Wenn es diese Nachricht entschlüsseln kann, bedeutet dies, dass sie mit ihrem privaten Schlüssel verschlüsselt wurde, was wiederum bedeutet, dass sie von ihnen stammt.

Womit sollte der Browser diese entschlüsselte Nachricht vergleichen? Signaturen sind einfach ein Hash des gesamten Zertifikats. Es muss also den Hash selbst berechnen (zum Beispiel 123XYZ) und mit der entschlüsselten Signatur vergleichen. Wenn es auch 123XYZ bekommt, bedeutet das zwei Dinge:

  1. dieses Verisign ist wahrlich der Autor dieses Zertifikats (andernfalls würde die entschlüsselte Nachricht nicht mit dem berechneten Hash übereinstimmen).
  2. dass das Zertifikat nicht geändert wurde (andernfalls würden sich die Hashes unterscheiden)

Ich gehe davon aus, dass es sich um die digitale Signatur des öffentlichen Schlüssels von Verisign handelt, die anhand der digitalen Signatur des öffentlichen Schlüssels des Servers getestet wird.

Nein, es wird gegen den Zertifikat-Hash getestet. Siehe vorherige.

Falls es sich tatsächlich um die getestete digitale Signatur handelt, gehe ich davon aus, dass zwischen allen öffentlichen Verisign-Schlüsseln eine Beziehung besteht.

Verisign verfügt über einen einzigen eindeutigen öffentlichen und einen privaten Schlüssel. Die Frage macht keinen Sinn.

Oder es gibt nur eine Beziehung zwischen jedem öffentlichen Schlüssel, den Verisign einem bestimmten Client (Website/Gerät/usw.) zuweist, und dem öffentlichen Schlüssel, den der Browser/das Betriebssystem enthält.

Genauer gesagt: Sie können öffentliche Schlüssel für Sie erstellen, aber Sie können ihnen auch Ihren öffentlichen Schlüssel geben, wenn Sie bereits einen haben, und sie werden ihn signieren .

Die Beziehung zwischen dem Zertifikat, das sie für Sie signieren, und dem Zertifikat im Browser lautet: Das Zertifikat im Browser ist das Stammzertifikat, dem Browser standardmäßig vertrauen. Das an den Client gelieferte Zertifikat wird standardmäßig nicht in allen Browsern als vertrauenswürdig eingestuft. Daher muss ein Browser überprüfen, wer dieses Zertifikat ausgestellt hat. Wenn dem Aussteller vertraut wird, vertraut der Browser Ihrem Zertifikat und gewährt Ihnen Zugriff auf die von Ihnen angeforderte Website. Wenn nicht, wird der Emittent des Emittenten überprüft, falls vorhanden, und festgestellt, ob er vertrauenswürdig ist. Es wird weiterhin nach den Vorfahren des Ausstellers gesucht, bis es eine vertrauenswürdige Stammzertifizierungsstelle erreicht, oder es wird dem Zertifikat nicht vertraut, wenn es keine findet.

In Ihrem Fall wird also festgestellt, dass Verisign der Aussteller ist (mit einem Zwischenzertifikat) und der Aussteller von Verisign Verisign selbst ist (jedoch mit einem anderen Zertifikat, das als Stammzertifikat bezeichnet wird). Da das Stammzertifikat von Verisign in jedem Browser installiert ist, ist dies der Fall vertrauenswürdig, was wiederum dazu führt, dass Sie Ihrem Zertifikat vertrauen.

Ich verstehe, dass die Notwendigkeit für sie Sicherheit ist, so dass der private Schlüssel der Stammzertifizierungsstelle offline bleiben kann, wenn es weitere Gründe gibt, die ich gerne über sie hören würde.

Sicherheit ist ein guter Grund, ja.

Bei der Kettenüberprüfung gehe ich davon aus, dass die digitale Signatur des öffentlichen Schlüssels des Servers anhand der digitalen Signatur des Server-Zwischenzertifikats getestet wird. Wenn sie jetzt gültig ist, muss die digitale Signatur des Zwischenzertifikats anhand der vorinstallierten öffentlichen Browser-/Betriebssystemsignatur getestet werden Schlüssel digitale Signatur, und wenn dies auch gültig ist, hat der Client sowohl das Zwischenzertifikat als auch den öffentlichen Schlüssel des Servers erfolgreich validiert.

Siehe vorherige


Während ich lernte, wie SSL funktioniert, habe ich dieses Diagramm erstellt. Es könnte hilfreich sein.

2
ychaouche