Zertifikat- & Privatschlüssel-Abgleich

Fügen Sie das Zertifikat ein, das ein Server verwendet, und den privaten Schlüssel, den Sie damit einsetzen wollen. Diese Seite beantwortet dann die Frage, an der eine bereitgestellte Website scheitert: Stammen beide aus demselben Schlüsselpaar? Die Antwort ist keine Vermutung aus Modulus-Längen oder Fingerabdrücken allein — die Seite signiert eine feste Challenge mit dem privaten Schlüssel und prüft diese Signatur mit dem öffentlichen Schlüssel im Zertifikat. Besteht die Prüfung, gehören beide zusammen; schlägt sie fehl, hilft kein Bearbeiten der Konfiguration. Beide Lesarten werden nebeneinander mit Algorithmus, Schlüssellänge, Subject Key Identifier und Fingerabdruck des öffentlichen Schlüssels angezeigt, und nichts, was Sie einfügen, verlässt den Browser.
1. Zertifikat oder Kette
Fügen Sie beliebig viele Blöcke ein. Jedes Zertifikat wird mit jedem Schlüssel geprüft, sodass eine Kette plus ein Schlüssel genau anzeigt, zu welchem Zertifikat der Kette dieser Schlüssel gehört — eine häufige Überraschung auf einem Server, der aus einem Bundle das falsche Zertifikat ausliefert. PEM, reiner Base64- oder Hexadezimalkörper und eine PKCS#7-Datei .p7b werden gelesen; der Zertifikatsprüfer auditiert das Zertifikat selbst, sobald der Schlüssel feststeht.
2. Privater Schlüssel oder öffentlicher Schlüssel
PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 (BEGIN RSA PRIVATE KEY), SEC1 (BEGIN EC PRIVATE KEY) und ein reiner öffentlicher SPKI-Schlüssel (BEGIN PUBLIC KEY) werden erkannt, ebenso eine Schlüsseldatei, die als Base64 oder Hexadezimal eingefügt wurde. Ein verschlüsselter PKCS#8-Schlüssel (BEGIN ENCRYPTED PRIVATE KEY) kann von einem Browser nicht gelesen werden; das wird angezeigt, zusammen mit dem Befehl, der die Passphrase entfernt.
noch nichts geprüft
Das Beispiel ist ein selbstsigniertes Zertifikat und der dazugehörige private Schlüssel, beides nur für diese Seite erstellt und ohne Schutzwirkung. Ersetzen Sie den Schlüssel durch einen anderen, um das andere Ergebnis zu sehen, oder fügen Sie anstelle des privaten Schlüssels den Block mit dem öffentlichen Schlüssel ein, um den Abgleich des öffentlichen Schlüssels zu sehen.
Bevor Sie einen privaten Schlüssel in eine Webseite einfügen, überlegen Sie kurz. Diese Seite besteht aus einer einzigen Datei mit einfachem JavaScript, lädt nichts von irgendwoher und stellt keine Anfrage. Der Schlüssel wird also in diesem Tab gelesen, verwendet und vergessen. Das ist allerdings eine Zusage des Codes, den Sie lesen können, und keine Garantie eines Netzwerks, das Sie sehen können: Wenn Sie einen Produktionsschlüssel bearbeiten, arbeiten Sie offline und betrachten Sie denselben openssl-Befehl auf Ihrem eigenen Server als die sicherste Prüfung. Ein hier eingefügter Schlüssel wird nie gespeichert, nie in eine Datei geschrieben und nie irgendwohin gesendet — auch nicht durch die Exportschaltflächen, die Befunde über den Schlüssel schreiben, aber nie den Schlüssel selbst.
Warum die Signatur die Antwort ist. Zwei Dateien können gleich aussehen und trotzdem nicht zusammenpassen: In den meisten Anleitungen werden RSA-Schlüssel über den Modulus verglichen, das funktioniert aber nur bei RSA, und ein Schlüssel kann den richtigen Modulus haben, während der Exponent beschädigt oder das Padding falsch ist. Diese Seite beweist das Paar so, wie es ein Handshake tut — sie signiert eine feste Challenge mit dem privaten Schlüssel und prüft die Signatur mit dem öffentlichen Schlüssel im Zertifikat. Das Ergebnis gilt daher gleichermaßen für RSA, ECDSA und Ed25519. Wird nur die öffentliche Hälfte eingefügt, werden die Bytes des öffentlichen Schlüssels mit denen im Zertifikat verglichen; das ist für die Identität ebenso eindeutig, beweist aber nicht, dass jemand den privaten Teil besitzt.

Was ein Treffer nicht bedeutet. Er sagt nicht, dass dieser Schlüssel der ist, den der Server tatsächlich geladen hat, dass dem Zertifikat vertraut wird, dass die Schlüsseldatei auf dem Datenträger unversehrt ist oder dass niemand sie kopiert hat. Er sagt auch nicht, ob das Zertifikat dasjenige ist, das ein Client erhält, denn ein Load Balancer oder ein CDN vor der Website kann ein anderes ausliefern. Um zu prüfen, was ein laufender Server tatsächlich präsentiert, führen Sie openssl s_client -connect example.com:443 -servername example.com -showcerts aus und fügen die Ausgabe in das Zertifikatsfeld ein.

Woher die Dateien stammen. Das Zertifikat ist das, mit dem Ihr Server konfiguriert ist, oder das aus einem Browser exportierte bzw. aus einem .p7b-Bundle entnommene. Der private Schlüssel ist die Datei, die Ihr Webserver beim Start liest, typischerweise etwa privkey.pem oder server.key. Ist Ihr Schlüssel verschlüsselt, entschlüsseln Sie zuerst eine Kopie mit openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-plain.pem, fügen diese ein und löschen die Kopie danach.
Abgleichbericht
Noch nichts geprüft. Fügen Sie oben ein Zertifikat und einen Schlüssel ein und drücken Sie Prüfen, ob sie zusammenpassen. Das Ergebnis erscheint hier mit den zugrunde liegenden Belegen, und der Bericht lässt sich kopieren oder speichern.
Dieselbe Prüfung mit openssl, auf Ihrem eigenen Rechner
# öffentlicher Schlüssel im Zertifikat openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256 # öffentlicher Schlüssel im privaten Schlüssel openssl pkey -in key.pem -pubout | openssl pkey -pubin -outform DER | openssl sha256 # die beiden Digests sind nur dann gleich, wenn das Paar zusammengehört # der ältere, nur für RSA geltende Weg: Moduli vergleichen openssl x509 -in cert.pem -noout -modulus | openssl md5 openssl rsa -in key.pem -noout -modulus | openssl md5
Der Vergleich der Digests funktioniert für jeden Schlüsseltyp und entspricht dem, was diese Seite als Fingerabdruck des öffentlichen Schlüssels ausgibt; der Modulus-Vergleich gibt es dagegen nur für RSA. Keiner der beiden beweist, dass jemand die private Hälfte besitzt — das leistet die oben beschriebene Signaturprüfung, weshalb diese Seite sie verwendet.
Was der Bericht enthält. Das Ergebnis, das Lesepaar, aus dem es hervorgegangen ist (Algorithmus, Schlüssellänge, Kurve, Subject Key Identifier und Fingerabdruck des öffentlichen Schlüssels, jeweils für das Zertifikat und für den Schlüssel), sowie der genaue durchgeführte Test. Der Bericht enthält nie den privaten Schlüssel selbst: Der Schlüssel dient nur dazu, eine Signatur zu erzeugen, und wird weder in den Text, das JSON noch in die Zwischenablage geschrieben. Was Sie kopieren oder speichern, lässt sich sicher an ein Ticket anhängen; der eingefügte Schlüssel dagegen nicht, und die Zwischenablage ist der einzige andere Ort, an dem er je existiert hat.

Datenschutz: Zertifikat und Schlüssel werden im Tab selbst gelesen, nichts wird hochgeladen, und die Seite stellt überhaupt keine Anfrage — es gibt hier keine Prüfung und keine Abfrage. Ein passendes Paar erstellen Sie mit dem Generator für selbstsignierte Zertifikate; ein Zertifikat für einen vorhandenen Schlüssel beantragen Sie mit dem CSR-Generator; den Inhalt eines Zertifikats lesen Sie mit dem Zertifikat-Decoder.