Ein VPN-Zertifikat untersuchen, ohne seinen Schlüssel auszugeben

Das Lesen der öffentlichen Felder eines Zertifikats erfordert nie, den zugehörigen privaten Schlüssel anzuzeigen, und die Werkzeuge dafür gehören zu jedem System, das ein VPN terminiert. Das Risiko liegt einen Schritt früher: Die Datei, die Sie erhalten haben, ist vielleicht gar kein Zertifikat. Ein PEM-Zertifikat, ein DER-Blob, ein PKCS#12-Bündel und ein OpenVPN-Profil können unter demselben Namen eintreffen und sehr unterschiedliches Material enthalten; bestimmen Sie daher den Container, bevor Sie einen Befehl wählen.

Drei Tatsachen entscheiden, welcher Befehl sicher ist: was die Datei enthält, was Sie daraus lesen müssen und wer die Ausgabe sieht. Liegt eines davon falsch, wird die Untersuchung selbst zum Vorfall.

Welche der drei Dateien Sie erhalten haben

Ein PEM-Zertifikat ist Text mit sichtbaren BEGIN- und END-Markern, eine DER-Datei ist binär und braucht ein Flag für das Eingabeformat, und ein Bündel ist ein Container, der einen Schlüssel neben dem Zertifikat enthalten kann. file server.crt trennt Text in einer Sekunde von Binärdaten, und ein Blick auf die erste Zeile trennt ein nacktes Zertifikat von einem Profil, das eines einbettet. Raten ist hier das, was eine Untersuchung in einen Vorfall verwandelt.

Ist die Datei ein Profil und kein Zertifikat, behandeln Sie sie als Anmeldedatum, bis das Gegenteil bewiesen ist. Diese Annahme kostet nichts und verhindert den häufigsten Fehler in dieser ganzen Aufgabe.

Die öffentlichen Felder eines PEM-Zertifikats lesen

Für ein Zertifikat, das Sie prüfen dürfen, gibt der Unterbefehl x509 mit -noout nur die von Ihnen gewählten Felder aus und sonst nichts. Das Unterdrücken des Rumpfes hält die Ausgabe bei Metadaten, und genau das macht sie sicher zum Einfügen in ein Ticket. Die folgenden Selektoren sind die öffentlichen, und die Dokumentation zu openssl x509 listet die übrigen.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

Auf einem lokal erzeugten Testzertifikat gibt dieser Befehl eine Subjekt- und eine Ausstellerzeile, das Paar notBefore und notAfter sowie einen SHA-256-Fingerabdruck aus. Diese Felder identifizieren das Objekt; sie begründen keinen gültigen Vertrauenspfad, was eine eigene Prüfaufgabe mit eigenem Befehl und eigener Antwort ist. Eine Ketten-Datei gibt möglicherweise nur das erste Zertifikat aus, wenn Sie die Datei nicht selbst durchlaufen. Zwei Dateien so zu vergleichen kostet einen Befehl und klärt, welche davon die Gegenseite tatsächlich vorzeigt.

Bündel, die einen Schlüssel neben dem Zertifikat enthalten

Eine .p12- oder .pfx-Datei kann einen privaten Schlüssel enthalten, und der Analysierbefehl gibt ihn aus, wenn Sie diesen Teil der Ausgabe nicht unterdrücken. Mit -nokeys meldet derselbe Befehl weiterhin die Struktur des Containers, einschließlich eines verschleierten Schlüsselbeutels, ohne Schlüsselmaterial auszugeben; lassen Sie das Flag weg, erscheint ein Schlüsselblock in Ihrem Terminal und in Ihrer Shell-Historie.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

Ein OpenVPN-Profil bettet dasselbe Material als Text ein, sodass die Grenze sichtbar ist, wenn man weiß, wo man hinsehen muss. Öffentliches Material steht zwischen BEGIN CERTIFICATE und END CERTIFICATE, während alles zwischen BEGIN PRIVATE KEY und der zugehörigen END-Zeile der Schlüssel ist und den Host nicht verlassen darf. Das Profil vollständig zu kopieren veröffentlicht beides.

Den Referenzwert von anderer Stelle holen

Ein Fingerabdruck, der aus der Verbindung gelesen wird, die Sie prüfen wollen, beweist nichts, weil ihn die Partei geliefert hat, der Sie misstrauen. Das ist kein Argument gegen Fingerabdrücke; es ist ein Argument über die Herkunft. Vergleichen Sie den Wert mit einem, der über einen Kanal beschafft wurde, in den die Gegenseite nicht schreiben kann, etwa das in einem internen Repository veröffentlichte Zertifikat oder der in einem signierten Änderungsdatensatz abgedruckte Hash.

Wo ein Vertrauensspeicher die Validierung durchführt, lassen Sie ihn das tun, und lesen Sie den Fehler, den er erzeugt, statt ihn durch Ihren eigenen Vergleich zu ersetzen. Der entscheidende Unterschied ist, wer die Referenz geliefert hat, nicht welche Hashfunktion verwendet wurde.

Das Ergebnis teilen und was nach einem Fehler zu tun ist

Senden Sie den genauen Validierungsfehler, die relevanten Datumsangaben und nur die Identitätsangaben, die der Empfänger braucht. Interne Hostnamen und Kontobezeichner bleiben sensibel, auch wenn kein Schlüssel vorhanden ist, und ein öffentlicher Paste-Dienst ist für all das der falsche Zielort. Fügen Sie in das Ticket ein, nicht in einen Zwischenspeicher, den jemand anderes teilt.

Falls Schlüsselmaterial doch auf dem Bildschirm oder in einer Datei aufgetaucht ist, behandeln Sie es als kompromittiert und rotieren Sie es, statt zu hoffen, dass niemand hingesehen hat. Schreiben Sie dann auf, welche Datei untersucht wurde, welcher Befehl verwendet wurde und wohin die Ausgabe ging, denn dieser Eintrag verwandelt einen Schrecken in ein Verfahren. Rotation ist billig gegenüber den Kosten der Annahme, niemand habe einen Screenshot behalten, und derselbe Eintrag sagt dem nächsten Ingenieur, welche Dateien überhaupt berührt wurden. Tun Sie beides, bevor das Ticket geschlossen wird.