Zertifikat- & Schlüssel-Matcher
Legen Sie eine beliebige Mischung aus Zertifikaten, privaten Schlüsseln und CSRs ab — PEM oder DER — und diese Werkbank beweist, welcher Schlüssel zu welchem Zertifikat passt, ordnet Zertifikate zu einer Kette, konvertiert Formate und erzeugt CSRs. Private Schlüssel verlassen Ihren Browser nie: Alles wird lokal in diesem Tab geparst, Schlüssel werden nur im Speicher gehalten und nie hochgeladen, protokolliert oder gespeichert, und diese Seite stellt keine Netzwerkanfrage. Um ein Zertifikat im Detail zu dekodieren, nutzen Sie den SSL-Zertifikatsparser; für ein schnelles selbstsigniertes Zertifikat den Generator für selbstsignierte Zertifikate.
Zertifikate, Schlüssel und CSRs hinzufügen
Abgleich-Urteil
Fügen Sie ein Zertifikat und einen privaten Schlüssel hinzu, und das Urteil erscheint hier: welcher Schlüssel zu welchem Zertifikat passt, bewiesen durch einen identischen öffentlichen Schlüssel — nie aus Dateinamen geraten.
Kettenbauer
Sind zwei oder mehr Zertifikate geladen, ordnet der Bauer sie mit dem Blatt zuerst, dann dem/den Zwischenzertifikat(en), dann der Wurzel, indem er Aussteller- und Subjektnamen abgleicht — und dann, wo die Kryptografie des Browsers es erlaubt, prüft er die tatsächliche Signatur an jedem Glied, statt den Namen zu vertrauen.
Eine CSR erzeugen
Eine Zertifikatsignieranforderung für einen hier, in Ihrem Browser, erzeugten Schlüssel: Tragen Sie das Subjekt ein, wählen Sie den Schlüsseltyp und laden Sie die CSR herunter, um sie an Ihre CA zu senden — plus den privaten Schlüssel, den Sie selbst sicher aufbewahren müssen. Der Schlüssel wird nur hier gezeigt; diese Seite behält ihn nicht.
Zertifikatsignieranforderung (PEM)
Privater Schlüssel (PEM) — bewahren Sie diesen Schlüssel sicher auf, er wird nur hier gezeigt
Wie der Abgleich tatsächlich funktioniert
Ein Zertifikat und ein privater Schlüssel sind nicht zwei Hälften einer Datei; sie sind zwei Dateien, die sich ein mathematisches Objekt teilen. Wenn ein Schlüsselpaar erzeugt wird, wird die öffentliche Hälfte in das Zertifikat gelegt (und in jede mit dem Schlüssel erstellte CSR), während die private Hälfte in der Schlüsseldatei bleibt. Zwei Einträge passen genau dann zusammen, wenn sie denselben öffentlichen Schlüssel tragen — für RSA denselben Modulus und Exponenten; für EC denselben Punkt auf derselben Kurve. Diese Seite kodiert diesen öffentlichen Schlüssel in seiner Standardhülle (dem SubjectPublicKeyInfo), hasht die Kodierung mit SHA-256 und gruppiert jeden geladenen Eintrag nach diesem Hash. Der auf jeder Karte gezeigte Hash ist daher der Beweis, nicht eine Zusammenfassung: Identische Hashes können nicht zufällig entstehen, und eine Nichtübereinstimmung ist ebenso sicher, weshalb das Urteil klar ausgesprochen werden kann — dieser Schlüssel passt zu diesem Zertifikat, oder kein geladener Schlüssel tut es. Der klassische Fehler, den dies abfängt, ist in wenn Ihr Schlüssel nicht zu Ihrem Zertifikat passt beschrieben: das Neuladen um 2 Uhr nachts, bei dem das erneuerte Zertifikat auf der Platte zu einem anderen Schlüssel gehört als dem, den der Server geladen hat.
Dateinamen beweisen nichts. Ein Verzeichnis voller server.crt, server.key, final-v2.pem und einer CSR aus dem Erneuerungsversuch des letzten Jahres ist der Normalzustand geerbter Infrastruktur, und die Namen sind Archäologie, keine Dokumentation. Auch eine passende Dateiendung oder ein passendes Datum beweist nichts. Und die traditionelle openssl-Prüfung — den Modulus-Hash des Zertifikats mit dem Modulus-Hash des Schlüssels zu vergleichen? Sie ist exakt die Prüfung dieser Seite, begrenzt auf RSA und auf ein Paar zurzeit, und sie übersieht EC-Schlüssel vollständig, weil EC-Schlüssel keinen Modulus haben. Der Fingerabdruck des öffentlichen Schlüssels deckt jeden Algorithmus einheitlich ab, weshalb er hier der Gruppierungsschlüssel ist.
Ketten, Reihenfolge und was „verifiziert“ bedeutet
Von Servern wird erwartet, dass sie zuerst das Blattzertifikat präsentieren, dann jedes Zwischenzertifikat in Reihenfolge, damit ein Client die Aussteller-zu-Subjekt-Glieder bis zu einer Wurzel durchlaufen kann, der er bereits vertraut. Dieselben Zertifikate in der falschen Reihenfolge zu präsentieren — oder mit einem fehlenden Zwischenzertifikat — erzeugt die klassische Fehlerfamilie „unable to get local issuer certificate“ bei Clients, die das fehlende Glied nicht selbst abrufen können. Der Bauer oben rekonstruiert die Reihenfolge allein aus den Namen, was immer möglich ist, und geht dann einen Schritt weiter: Für RSA- und ECDSA-Signaturen importiert er den öffentlichen Schlüssel des Ausstellers und prüft die Signatur über den signierten Bytes des Zertifikats. Ein Glied mit der Bezeichnung Signatur verifiziert ist kryptografisch bewiesen. Ein Glied mit der Bezeichnung nur Namensübereinstimmung ist es nicht — die Namen ketten sich, aber die Signatur verwendet einen Algorithmus, den diese Plattform nicht prüft (RSA-PSS ist der übliche Fall), und die Seite sagt das, statt eine Namensübereinstimmung als Beweis zu verkleiden. Schlägt eine Signaturprüfung fehl, waren die Namen ein Zufall oder eine Fälschung, und der Bauer zeigt den Fehler in Rot, statt still ein Bündel zu erzeugen.
Formate: PEM, DER und die .pfx-Frage
PEM sind DER-Bytes, in Base64 verpackt und mit einer beschrifteten Kopfzeile versehen; DER ist die rohe Kodierung. Zwischen ihnen zu konvertieren verliert nichts und beweist nichts — es ist dasselbe Objekt in einem anderen Umschlag —, weshalb jede Karte beide Downloads anbietet. Windows und manche Java-Werkzeuge bevorzugen DER oder PKCS#12; die meisten Unix-Werkzeuge wollen PEM. PKCS#12 (.pfx/.p12) ist eine andere Sache: Es ist ein verschlüsselter Container mit eigenem Integritäts-MAC, und einen zu erzeugen, den jeder Verbraucher akzeptiert — mit einem Schutz, der den Namen verdient —, ist nichts, was man in einer Webseite von Hand bauen sollte. Dieses Werkzeug bietet es bewusst nicht an. Um ein abgeglichenes Paar selbst zu verpacken, führen Sie openssl dort aus, wo die Dateien leben: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx — nachdem diese Seite Ihnen gesagt hat, welcher Schlüssel, welches Zertifikat und welche Kette tatsächlich zusammengehören.
Parsen und Ketten sind handgeschriebener DER-Code für diese Seite (BSD-Stil, kein fremder Parser); Hashen, Signaturprüfung und Schlüsselerzeugung nutzen das WebCrypto des Browsers. Kein Teil dieses Werkzeugs stellt eine Netzwerkanfrage.
Häufig gestellte Fragen
Wie beweist der Matcher, dass ein Schlüssel und ein Zertifikat zusammengehören?
Indem er den öffentlichen Schlüssel vergleicht, nicht die Dateien. Jedes Zertifikat, jede CSR und jeder private Schlüssel liefert denselben kodierten öffentlichen Schlüssel (das SubjectPublicKeyInfo); diese Seite hasht ihn mit SHA-256 und gruppiert Einträge, deren Hashes übereinstimmen. Ein identischer öffentlicher Schlüssel bedeutet, dass der private Schlüssel mathematisch derjenige ist, für den das Zertifikat ausgestellt wurde — dieselbe Prüfung, die openssl mit seinem Modulus-Vergleich durchführt, für jede Datei auf einmal und für EC-Schlüssel ebenso wie für RSA.
Ist es sicher, einen echten privaten Schlüssel in eine Webseite zu laden?
Auf dieser Seite ja, wegen der Art, wie sie gebaut ist: Alles wird lokal in Ihrem Browser geparst, Schlüssel werden nur im Speicher dieses Tabs gehalten, nichts wird hochgeladen, protokolliert oder in irgendeinen Speicher geschrieben, und die Seite stellt keine Netzwerkanfrage. Die Gewohnheit, die man behalten sollte, ist, diese Behauptung bei jedem Werkzeug zu prüfen, bevor man einen Schlüssel einfügt — und einen privaten Schlüssel nie in einen Chat, ein Ticket oder einen serverseitigen „Prüfer“ einzufügen, der ihn remote verarbeitet.
Was bedeutet „nur Namensübereinstimmung“ im Kettenbauer?
Der Kettenbauer ordnet Zertifikate, indem er den Ausstellernamen jedes Zertifikats mit dem Subjektnamen des nächsten abgleicht, und versucht dann, die tatsächliche Signatur mit dem öffentlichen Schlüssel des Ausstellers zu verifizieren. Wo der Signaturalgorithmus einer ist, den das WebCrypto des Browsers prüfen kann (in der Praxis RSA und ECDSA), wird das Glied als „Signatur verifiziert“ bezeichnet oder, wenn die Prüfung fehlschlägt, als „Signatur FEHLGESCHLAGEN“. Alles andere — RSA-PSS ist der übliche Fall — wird ehrlich als „nur Namensübereinstimmung“ bezeichnet: Die Namen stimmen überein, aber diese Seite hat das Glied nicht kryptografisch bewiesen.
Warum gibt es keinen PKCS#12- (.pfx-) Export?
Eine PKCS#12-Datei verpackt einen Schlüssel und ein Zertifikat in passwortbasierter Verschlüsselung mit MAC-Integrität — ein Format, das sorgfältige, gut getestete Kodierung braucht. Statt eine handgebaute Version auszuliefern, die Dateien erzeugen könnte, die andere Software ablehnt (oder, schlimmer, schwach geschützte Schlüssel), konvertiert diese Seite zwischen PEM und DER und überlässt die .pfx-Verpackung openssl: Der Befehl wird auf der Seite gezeigt, damit Sie ihn dort ausführen können, wo der Schlüssel bereits lebt.
Kann diese Seite einen verschlüsselten privaten Schlüssel lesen?
Sie kann einen erkennen und das sagen, aber sie kann ihn nicht verwenden: Ein verschlüsselter (passwortgeschützter) Schlüssel offenbart seinen öffentlichen Schlüssel erst, wenn er entschlüsselt wird, und der Abgleich erfolgt über den öffentlichen Schlüssel. Entschlüsseln Sie eine Kopie lokal mit openssl (pkcs8 -topk8 -nocrypt, oder rsa/ec) und laden Sie die entschlüsselte Kopie — auf einem Rechner, dem Sie vertrauen, und löschen Sie die Kopie danach.