So erzeugen Sie einen VPN-Client-Schlüssel und reichen eine CSR zum Signieren ein

Behalten Sie den privaten Schlüssel beim Client und senden Sie nur die Anfrage. Prüfen Sie die CSR, genehmigen Sie die Identität, signieren Sie mit expliziten Erweiterungen und bestätigen Sie dann das Paar.

Früher oder später bietet ein VPN-Benutzer an, einen privaten Schlüssel per E-Mail zu schicken, damit der Administrator ein Zertifikat erstellen kann, und genau dieses Angebot gilt es abzulehnen. Der funktionierende Ablauf behält den Schlüssel ab dem ersten Befehl beim Client: Der Client erzeugt ihn, sendet eine Anfrage zur Zertifikatssignierung, der Aussteller prüft und autorisiert sie, und das signierte Zertifikat kommt zurück und liegt neben dem Schlüssel, der es erzeugt hat. Die Checkliste unten schlägt bei jedem Schritt geschlossen fehl, und das ist der Punkt, denn zwei der fünf Schritte sind genau die, die Leute in Eile überspringen.

Schritt 1: Erzeugen Sie den Schlüssel dort, wo er leben wird

Erzeugen Sie ihn auf der Maschine, die den Schlüssel halten wird, und lassen Sie ihn dort. Ein Softwareschlüssel landet in einer Datei mit strengen Berechtigungen; ein hardwaregestützter Schlüssel oder ein Schlüssel in einem verwalteten Speicher wird nie eine Datei, und sein Registrierungspfad ist meist ein separates Werkzeug statt eines OpenSSL-Befehls. So oder so muss niemand die private Hälfte sehen.

Der Softwareablauf sieht so aus, wobei Schlüssel und Anfrage in einer Sitzung entstehen:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

Die Zeile umask ist wichtiger, als sie aussieht. Ohne sie wird der Schlüssel auf einem standardmäßig freizügigen System weltlesbar geschrieben, und das Herumkopieren der Datei verbreitet das später. Einen vorhandenen Schlüssel weiterzuverwenden ist legitim, wenn er bereits geschützt ist und zu Ihrer Richtlinie passt; pro Gerät einen frischen zu erzeugen ist leichter zu begründen.

Schritt 2: Setzen Sie die Identität in die Anfrage, nicht in die E-Mail

Entscheiden Sie, was die VPN tatsächlich authentifiziert, bevor die Anfrage entsteht, denn diese Antwort gehört in die CSR. OpenVPN bindet die Client-Identität traditionell an den Common Name des Zertifikats, und Werkzeuge wie strongSwan gleichen eine Identitätszeichenfolge mit dem Subject oder einem Subject Alternative Name ab. Eine E-Mail, die sagt, ich heiße alice, ist kein Nachweis, und eine Anfrage, deren Subject dasselbe sagt, ist nur unwesentlich besser.

Fügen Sie einen Subject Alternative Name hinzu, wenn Ihr Prüfer einen prüft, da moderne Abgleiche den alten CN oft ignorieren:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Halten Sie den CN kurz, stabil und an das Konto gebunden statt an ein Laptop-Modell. Ein Name, der die Seriennummer des Benutzergeräts enthält, ist ein Supportproblem, das auf den ersten Hardwaretausch wartet.

Schritt 3: Prüfen Sie die Anfrage, bevor Sie sie signieren

Der Aussteller prüft zwei verschiedene Dinge, und sie zu vermengen ist der klassische Fehler. Erstens, dass die Anfrage intern stimmig ist: Die Signatur wird gegen den mitgeführten öffentlichen Schlüssel geprüft. Zweitens, dass der Antragsteller berechtigt ist, was die Anfrage verlangt, und darauf kann keine kryptografische Prüfung antworten.

Der mechanische Teil ist ein Befehl, und er sollte ein Prüfergebnis zusammen mit dem Subject ausgeben:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Beachten Sie, was das beweist. Eine Anfrage, die sich prüfen lässt, zeigt nur, dass der Absender zum Abgabezeitpunkt den passenden privaten Schlüssel besaß; sie beweist nicht, dass der Absender die im Subject genannte Person ist, und sie autorisiert nicht den Gruppen- oder Routenzugriff, der verlangt wird. Die Registrierungsprüfung ist ein separates Tor, und eine Anfrage für eine Gruppe, die niemand genehmigt hat, sollte abgelehnt statt still bearbeitet werden.

Schritt 4: Autorisieren, dann mit expliziten Erweiterungen signieren

Signieren ist der Punkt, an dem die CA Richtlinie entscheidet, statt die Anfrage wörtlich zu übernehmen. Gültigkeit, Schlüsselverwendung und die Rollenerweiterung gehören in eine Erweiterungsdatei, nicht in Voreinstellungen, die Sie sechs Monate später nicht mehr erinnern. Ein Client-Zertifikat zur VPN-Authentifizierung braucht die Client-Authentifizierung als Zweck.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Verwenden Sie -CAserial mit der vorhandenen Serialdatei, falls bereits eine genutzt wird, und halten Sie den CA-Schlüssel offline oder in dem geschützten Speicher, den Ihre Richtlinie nennt. Zertifikatsseriennummern müssen je Aussteller eindeutig sein; die Serialdatei von Grund auf neu zu erzeugen riskiert Kollisionen, die den Widerruf mehrdeutig machen.

Halten Sie fest, was ausgestellt wurde: Seriennummer, Subject, angefragte Identität, genehmigende Person und Ablauf. Dieser Datensatz ist es, worauf sich eine Widerrufsentscheidung später stützt, und er lässt sich nicht allein aus dem Zertifikat rekonstruieren, wenn die Registrierungsspur nur in einem Postfach lebt.

Schritt 5: Installieren Sie es neben dem passenden Schlüssel und beweisen Sie die Paarung

Der Client erhält das Zertifikat und die Ausstellerkette, niemals einen Schlüssel. Bestätigen Sie vor dem Verbinden, dass das Zertifikat tatsächlich mit dem bereits auf der Festplatte liegenden Schlüssel paart, denn ein nicht passendes Paar erzeugt viel später einen verwirrenden Handshake-Fehler:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Die beiden Digests müssen übereinstimmen. Verbinden Sie dann und bestätigen Sie, dass die Identität, die der Server protokolliert, die von Ihnen autorisierte ist, und nicht bloß, dass der Tunnel hochkam. Wenn der Schlüssel verloren geht oder das Gerät ersetzt wird, lautet die Antwort Widerruf plus eine neue Anfrage vom neuen Gerät; den Administrator zu bitten, einen Schlüssel von woanders zurückzuschicken, stellt das Original nicht wieder her und bricht still das Modell, das die Anfrage sicher machte.

Ähnliche Artikel