Ein CSR allein ist keine Registrierung: Was eine VPN-CA prüfen muss

Eine Zertifikatsignaturanforderung enthält einen öffentlichen Schlüssel und einen gewünschten Subject, signiert mit dem passenden privaten Schlüssel. Diese Signatur belegt, dass der Antragsteller den Schlüssel besitzt. Sie belegt nicht, dass der Antragsteller Anspruch auf den Namen, das Gerät oder die VPN-Rolle hat, die er beantragt, und wer sie so behandelt, als würde sie das belegen, macht aus einem Helpdesk-Ticket eine Zugangsgewährung.

Zwei Registrierungsmodelle sollte man danach vergleichen, was sie binden, nicht danach, welches Protokoll sie sprechen.

Eine Anforderung behauptet einen Namen, sie beweist ihn nicht

Lesen Sie die Anforderung für das, was tatsächlich darin steht: ein öffentlicher Schlüssel, ein vom Antragsteller gewählter Subject und eine Selbstsignatur über beides. Nichts in dieser Struktur verweist auf Ihr Inventar, Ihr Kontoverzeichnis oder Ihren Genehmigungsablauf. Ein Subject wie cn=finance-laptop ist eine Zeichenkette, die jemand eingetippt hat. Erst wenn der Ausstellungsprozess diese Zeichenkette gegen einen Datensatz prüft, dem er vertraut, ist das Zertifikat eine Behauptung mit angehängter Signatur. Dieser Unterschied ist der ganze Grund, warum es einen Registrierungsprozess gibt.

Die Folge ist betrieblich wichtig. Eine Zertifizierungsstelle braucht nie den privaten Schlüssel des Clients, um ein Zertifikat auszustellen, und ein Ablauf, der danach fragt, hat Signieren mit Schlüsselverwahrung verwechselt. Lassen Sie die Erzeugung am Endpunkt und senden Sie nur die öffentliche Hälfte.

Vergleichen Sie die Modelle danach, was sie binden

Manuelles Signieren bindet das, woran der Operator zu prüfen denkt. Ein automatisierter Registrierungsdienst bindet eine authentifizierte Anforderung an eine Entscheidung, die der Dienst durchsetzen kann, und RFC 7030 beschreibt ein solches Design, bei dem sich der Client authentifiziert, bevor ein Zertifikat zurückgegeben wird. Der Unterschied, der ein Audit übersteht, ist nicht die Automatisierung; es ist die Frage, ob die Identitätsprüfung im Ausstellungspfad stattfindet oder daneben.

Beide Modelle müssen weiterhin dieselben drei Fragen beantworten. Wer fragt, auf welchem Gerät oder in welcher Rolle, und für wie lange. Ein Ticketsystem, das die Antworten festhält, leistet echte Arbeit; eine Warteschlange, in der jemand einen Common Name anschaut, nicht, so sorgfältig das Zertifikat später auch formatiert wird.

Wählen Sie das Modell nach der Zahl der erwarteten Registrierungen und der Fluktuation der Geräte. Ein paar Server im Jahr überstehen eine manuelle Prüfung mit einer schriftlichen Checkliste. Eine Flotte von Laptops nicht.

Halten Sie den Lebenszyklus ab der ersten Ausstellung fest

Speichern Sie Kennung des Zertifikats, Eigentümer, vorgesehenen Verwendungszweck, Ablauf und Entfernungspfad im Moment der Ausstellung, nicht beim ersten Vorfall. Der vorgesehene Verwendungszweck gehört über eine erweiterte Schlüsselverwendung in das Zertifikat selbst, und der Datensatz sollte dazu passen. Ein Zertifikat, das für die Client-Authentifizierung ausgestellt wurde, sollte nicht von einem für einen Server ununterscheidbar sein.

Planen Sie Erneuerung und Widerruf bei Geräteverlust, bevor Sie das zehnte Profil ausstellen. Ein Zertifikat, das eine Abteilung teilt, macht aus einer gezielten Entfernung einen Ausfall, und diese Entscheidung ist jetzt viel billiger zu überdenken als während eines Vorfalls am Freitag.

Prüfen Sie das ausgestellte Zertifikat, dann den Zugang

Prüfen Sie nach der Registrierung, was ausgestellt wurde, und bestätigen Sie, dass es zu der erwarteten Stelle verkettet. Zwei Befehle decken die häufigen Fehler ab: ein Zertifikat mit falschem Verwendungszweck und eine Kette, die nur funktioniert, weil der Client so konfiguriert ist, dass er die Validierung ignoriert.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Testen Sie dann den Zugang statt des Artefakts. Ein Zertifikat stellt Identität fest, und die Richtlinie entscheidet weiterhin, welche Dienste diese Identität erreichen darf. Prüfen Sie beides, denn ein korrektes Artefakt mit einer zu weiten Richtlinie besteht eine Prüfung ebenfalls nicht. Bestätigen Sie, dass der Client sich authentifiziert und nur die vorgesehenen Routen oder Ressourcen erhält. Notieren Sie, was Sie beobachtet haben, nicht was das Profil tun sollte.

Ein Profil, das aus dem falschen Grund funktioniert, etwa ein passender Common Name und keine Identitätsprüfung, funktioniert weiter, nachdem die Kontrolle, von der Sie glaubten, sie zu haben, entfernt wurde.