Widerrufenes VPN-Zertifikat verbindet weiter? CRL-Durchsetzung prüfen

Sie haben das Zertifikat widerrufen, eine frische Liste erzeugt, und das alte Profil baut weiterhin einen Tunnel auf. Am Widerruf selbst ist nichts kaputt: Eine CRL ist eine signierte Aussage, dass eine Seriennummer nicht mehr gültig ist, und sie ändert den Zugriff erst, wenn die TLS-beendende Komponente sie für den richtigen Aussteller lädt, bevor sie die Annahmeentscheidung trifft. Genau dort liegen die meisten dieser Fälle, und deshalb sind Widerruf und Ablehnung zwei verschiedene Tatsachen.

Arbeiten Sie die fünf Prüfungen unten in der Reihenfolge durch, und halten Sie bei der ersten an, die nicht zutrifft, denn jede spätere Prüfung setzt die früheren als wahr voraus.

Prüfen, welche Komponente die Annahmeentscheidung trifft

Benennen Sie den Prozess, der das Clientzertifikat validiert, denn nur dieser Prozess kann eine Liste durchsetzen. Auf einem OpenVPN-Server ist es der Daemon selbst, konfiguriert mit crl-verify. Bei ocserv ist es die Zeile crl in ocserv.conf. Bei strongSwan sind die Eingaben die geladenen CRLs zusammen mit strictcrlpolicy. Ein TLS-beendender Proxy oder eine Appliance vor dem VPN kann der eigentliche Prüfer sein, und wenn das so ist, sieht der Daemon dahinter das Clientzertifikat nie.

WireGuard gehört in eine andere Kategorie. Es hat keine Zertifikate und keine Widerrufsliste; ein Peer wird über seinen öffentlichen Schlüssel in der Konfiguration zugelassen, der Zugriffsentzug bedeutet also, diesen Schlüssel zu entfernen. Wenn Sie in einer reinen WireGuard-Bereitstellung nach einer CRL suchen, gibt es diesen Mechanismus dort nicht.

Achten Sie auch auf die Falle auf Clientseite. Ein Client, der die Verbindung ablehnt, weil ihm das Serverzertifikat nicht gefällt, setzt die Kette des Servers durch und widerruft nicht seine eigene Berechtigung. Ein Benutzerzertifikat wird nur dort widerrufen, wo dieses Benutzerzertifikat validiert wird, und das ist fast immer die Serverseite.

Prüfen, für welchen Aussteller die Liste signiert wurde

Eine CRL gilt nur für eine ausstellende CA. Bei einer Root und einer Intermediate stammen die Endzertifikate von der Intermediate, die maßgebliche Liste ist also die CRL der Intermediate; die Liste der Root sagt nichts über diese Endzertifikate aus. Ein Prüfer, der auf die falsche Datei zeigt, parst sie fröhlich, findet keinen passenden Eintrag und akzeptiert alles.

Bestätigen Sie die Paarung, bevor Sie den Daemon anfassen. Der Aussteller im Zertifikat muss zum Subject der Liste passen:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Wenn beide von derselben CA stammen, ist die im Zertifikat angegebene Seriennummer der Wert, der in der Liste stehen muss. Wenn sie nicht übereinstimmen, haben Sie die falsche CRL oder die falsche Kopie davon in der Hand.

Die Gültigkeit gehört zur selben Prüfung. Ein nextUpdate in der Vergangenheit macht die Liste veraltet, und ein Prüfer, der fail-closed arbeitet, weist dann jeden Client ab statt nur den widerrufenen.

Prüfen, ob die Seriennummer in der geladenen Kopie steht

Der Widerruf schreibt einen Eintrag in die CA-Datenbank, und das Neuerzeugen schreibt eine neue Datei. Keine der beiden Aktionen erreicht einen laufenden Daemon, der die alte Kopie beim Start geladen hat. Dumpen Sie die Liste und suchen Sie die Seriennummer:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Prüfen Sie dann, wie Ihre Implementierung die Datei aufnimmt. OpenVPN liest einen Pfad, der crl-verify übergeben wurde, einmal beim Start, eine neue Liste braucht also einen Neustart oder ein Neustartsignal; dieselbe Option, auf ein Verzeichnis gerichtet, wird bei jeder Verbindung neu gelesen, und deshalb gibt es den Verzeichnismodus. strongSwan muss seine Credentials neu laden, zum Beispiel mit swanctl --load-creds. Dass die Datei auf der Platte korrekt ist und dass der Prüfer sie verwendet, sind zwei verschiedene Tatsachen.

Prüfen Sie die Richtlinie für eine fehlende oder abgelaufene Liste

Das ist die Entscheidung, die viele Bereitstellungen nie ausdrücklich treffen, und sie entscheidet, ob der Widerruf Sie schützt oder alle aussperrt. Fail-closed bedeutet, dass ohne brauchbare Widerrufsinformationen eine Ablehnung erfolgt; fail-open bedeutet, dass der Prüfer ohne sie weiterfährt. strongSwan stellt die Wahl als strictcrlpolicy bereit. OpenVPN mit crl-verify verweigert den Start bei einer Datei, die es nicht lesen oder parsen kann, und eine abgelaufene Liste erscheint als TLS-Verifikationsfehler über eine abgelaufene CRL statt als stilles Akzeptieren.

Egal welche Richtung Sie wählen, die Automatisierung zählt mehr als die Wahl: Ein Job, der die CRL vor nextUpdate neu erzeugt, und eine Warnung, wenn die eingesetzte Kopie älter wird, halten jede der beiden Richtlinien davon ab, ein Vorfall zu werden. Die Online-Prüfung per OCSP verlagert die Aktualität auf einen Responder, aber dieselbe Regel gilt, denn ein Prüfer, der nicht für die Prüfung der Antwort konfiguriert ist, ändert nichts.

Prüfen Sie die laufende Sitzung, dann die Kopien des Schlüssels

Der Widerruf wird während der Zertifikatsvalidierung ausgewertet, die beim Verbinden und bei der Neuverhandlung stattfindet. Eine bestehende Sitzung läuft weiter, bis sie neu verhandelt, und OpenVPNs Standard ist einmal pro Stunde mit reneg-sec 3600. Wenn die Person jetzt aus dem Netz sein muss, beenden Sie die Sitzung und veröffentlichen Sie die Liste, dann bestätigen Sie, dass die Wiederverbindung abgelehnt wird.

Trennen Sie die Berechtigung von ihren Kopien. Das Löschen eines Profils auf einem Laptop hindert eine andere Kopie desselben privaten Schlüssels nicht an der Authentifizierung; der Widerruf ist es, der jede Kopie nutzlos macht, und zwar erst, wenn die früheren Prüfungen zutreffen. Geben Sie einem Ersatzgerät ein eigenes Zertifikat, damit eines widerrufen werden kann, ohne das andere anzutasten.

Bevor Sie es als erledigt betrachten: Die validierende Komponente ist benannt, der Aussteller der Liste passt zum Aussteller des Endzertifikats, die widerrufene Seriennummer steht in der Kopie, die der Daemon tatsächlich geladen hat, die Richtlinie für fehlende oder abgelaufene Listen ist bewusst gewählt und überwacht, und die aktive Sitzung wurde beendet statt abgewartet. Die Formate dahinter sind in RFC 5280 spezifiziert.