Einen VPN-Client hinzufügen, ohne die CA neu aufzubauen

Sie brauchen ein weiteres Zertifikat für einen weiteren Laptop, doch das erste Tutorial in den Suchergebnissen beginnt mit einem Befehl, der das PKI-Verzeichnis löscht. Dieser Befehl gehört zur Ersteinrichtung, nicht zur Registrierung, und er kostet Sie die CA, die Ausstellungshistorie und jedes Clientprofil, das dem alten Aussteller vertraute. Die Entscheidung ist enger: Hat Ihr Aussteller noch brauchbaren Zustand, und passt das neue Gerät in Ihre Registrierungsrichtlinie? Drei Bedingungen entscheiden, nur eine rechtfertigt einen Neuaufbau.

Was ein Neuaufbau wirklich zerstört

Eine PKI neu zu initialisieren ersetzt das Verzeichnis durch eine leere Struktur: neuer CA-Schlüssel und neues Zertifikat, leere Ausstellungsdatenbank, neuer Seriennummernzähler. Clients folgen nicht stillschweigend; ihre Profile binden die alte CA, also muss jedes vorhandene Gerät neu registriert werden, unerreichbare Geräte von Hand.

Der leisere Verlust ist die Buchführung. Widerruf setzt voraus, dass Sie wissen, welche Seriennummern Sie wem ausgestellt haben. Löschen Sie den Index, können Sie weiter signieren, aber nicht mehr sicher sagen, welche der offenen Zertifikate Sie widerrufen wollten. Ein CA-Verzeichnis mit Zertifikaten ohne passenden Ausstellerzustand ist ein Backup, das die falsche Hälfte des Systems wiederherstellt.

Den privaten CA-Schlüssel neben den laufenden Server zu kopieren ist die andere Abkürzung, die man ablehnen sollte: Sie macht eine Signaturinstanz, die offline stehen muss, zu einer weiteren Datei auf einem Host mit nicht vertrauenswürdigem Verkehr.

Erste Bedingung: Ist der Ausstellerzustand noch erreichbar?

Finden Sie zuerst das Verzeichnis, dem der Server wirklich vertraut. Vergleichen Sie das Zertifikat, das der Server als CA präsentiert, mit dem im PKI-Verzeichnis über den Fingerabdruck, nicht über den Dateinamen:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Stimmen die Fingerabdrücke überein, ist die Registrierung inkrementell und Sie bauen nichts neu. Weichen sie ab, signieren Sie mit einer CA, der der Server nicht vertraut: Das Zertifikat installiert sich sauber und scheitert beim Handshake, und dieser Fehler wird stundenlang als Clientfehler fehldiagnostiziert.

Suchen Sie dann den Ausstellungszustand: Indexdatei, Seriennummernzähler und Datei der CRL-Nummer. Fehlt der Index, lebt aber der Schlüssel, können Sie ausstellen, erben aber ein Problem bei der Widerrufsaufzeichnung. Notieren Sie das im Änderungsprotokoll, denn der nächste Widerruf wird es zeigen.

Zweite Bedingung: Wer hält den neuen privaten Schlüssel?

Diese Entscheidung spüren die Nutzer, also treffen Sie sie ausdrücklich. Ein clientseitig erzeugter Schlüssel, als Antrag eingereicht, lässt die private Hälfte ab dem ersten Befehl auf dem Gerät, und der Administrator berührt sie nie. Ein serverseitig erzeugter Schlüssel ist einfacher für Geräte ohne Werkzeuge, macht den Administrator aber zum Verwalter jedes Client-Schlüssels und vergrößert die Wirkung einer Serverkompromittierung.

Mit Easy-RSA 3 gegen eine bestehende CA sind Import und Signatur eines Antrags zwei Befehle:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Wählen Sie den Zertifikatstyp bewusst. Ein als Server- statt Clientzertifikat signierter Antrag ergibt eine Datei, die ordentlich aussieht und vom Partner abgelehnt wird, und die Fehlermeldung sagt selten warum. Bei openssl ca steckt dieselbe Wahl in den übergebenen Erweiterungen, nicht im Standardabschnitt.

Dritte Bedingung: Braucht der Server mehr als ein Zertifikat?

Für einen gewöhnlichen OpenVPN-Server mit Zertifikatsauthentifizierung ist das Zertifikat die Registrierung: Der Common Name wird die Clientidentität, und jedes Clientverzeichnis, jede gepushte Route oder statische Adresse hängt an diesem Namen. Fügen Sie das Zertifikat hinzu und vergessen die Konfiguration, verbindet der Tunnel, aber die nötigen Routen erscheinen nie.

Plattformen ändern das. OpenVPN Access Server führt eine eigene Benutzerdatenbank, ein signiertes Zertifikat ist also kein Konto; das Konto muss existieren und erlaubt sein. Andere Gateways ordnen eine Identitätszeichenfolge einer Gruppe zu. Ein Gerät zu registrieren berührt meist zwei Systeme, und das Zertifikat ist nur das erste.

Das inkrementelle Verfahren und wann ein Neuaufbau richtig ist

Die Reihenfolge, die ein Gerät ohne Schaden hinzufügt: Aussteller per Fingerabdruck bestätigen, frisches Backup des PKI-Verzeichnisses ziehen, den Antrag für die Clientrolle importieren und signieren, das Zertifikat mit Kette über den freigegebenen Kanal liefern, dann vor dem Verbinden prüfen:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

Die Zweckzeile sollte SSL client zeigen. Schließen Sie mit einer Aktualisierung des CA-Backups nach der Ausstellung ab, denn ein Backup von vor der neuen Seriennummer stellt einen Zustand ohne das gerade hinzugefügte Gerät her.

Ein Neuaufbau ist in drei Fällen richtig: Der CA-Schlüssel ist kompromittiert, der Ausstellungszustand ist unwiederbringlich verloren, oder Sie ändern bewusst Schlüsselalgorithmus oder Zertifikatsrichtlinie. Alle drei sind Projekte mit Neu-Registrierungsplan für jeden Client, keine Schritte in einem Antrag für ein Gerät. Trifft nichts zu, registrieren Sie inkrementell und lassen den Aussteller in Ruhe.