Ein gemeinsamer Name, zwei Zertifikate: Positivliste oder Widerruf?

Ein Laptop-Zertifikat unter demselben gemeinsamen Namen neu auszustellen fühlt sich wie ein Ersatz an, und alle gehen davon aus, dass das alte tot ist. Ist es nicht. Der Vorgänger bleibt ein gültiges Zertifikat, das dieselbe Behörde signiert hat, und jede Kontrolle, die Clients nach Namen zulässt, wird ihn weiterhin zulassen. Was eine Identitätsprüfung von einer Anmeldedatenprüfung trennt, ist die Seriennummer, und dort gehört die Korrektur hin.

Beginnen Sie mit der Namensrichtlinie, die der Server verwendet

Zwei Kontrollen werden verwechselt: einen Client zuzulassen, weil er behauptet, wer er ist, und ein bestimmtes Zertifikat außer Betrieb zu nehmen. Die erste ist eine Namensprüfung, die zweite eine Widerrufsprüfung. Sie beantworten unterschiedliche Fragen, und ein Deployment kann die eine ohne die andere haben.

Lesen Sie die Serverkonfiguration und notieren Sie, welche Identitätsquelle im Spiel ist. username-as-common-name macht den authentifizierten Benutzernamen zum effektiven Namen für klientspezifische Abfragen. Ohne ihn wird der Common Name des Subjekts aus dem Zertifikat verwendet. Wie die Antwort auch lautet, schreiben Sie sie auf, bevor Sie eine Positivliste anfassen.

Die beiden Wege ergeben einen unterschiedlichen Satz zulässiger Namen für dasselbe Zertifikat. Raten bedeutet hier, die falsche Datei zu bearbeiten und zu schließen, dass die Kontrolle nicht funktioniert.

Prüfen Sie, was einen Client tatsächlich zulässt

Eine client-config-dir mit passender Datei liefert Optionen pro Client; für sich genommen ist sie keine Zulassungsregel. Die Zulassung nach Namen erfordert ccd-exclusive, die Clients ohne passende Datei ablehnt. Wird das in einem laufenden Deployment aktiviert, trennt es alle, deren Name keine Datei hat, also zählen Sie die Dateien, bevor Sie etwas umstellen.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Die Anzahl ist die Prüfung: Vergleichen Sie das Verzeichnislisting mit den Identitäten, die Sie erwarten.

Bestätigen Sie dann, dass jeder Dateiname exakt der effektiven Identität entspricht, einschließlich Groß- und Kleinschreibung und Leerzeichen. Eine Datei für office-laptop bewirkt nichts für ein Zertifikat, dessen Subjekt Office-Laptop lautet. Nachgestellte Leerzeichen verbergen sich zudem vor einem einfachen Listing, und so bleibt eine Datei, die vorhanden aussieht, ungelesen.

Prüfen Sie die CRL, die das Gateway lädt

Eine CRL nennt gesperrte Zertifikate nach Aussteller und Seriennummer, also die Granularität, die einer Namensprüfung fehlt. Zwei Zertifikate können denselben gemeinsamen Namen teilen und sich in der Seriennummer unterscheiden, und nur eine Liste auf Seriennummernebene trennt sie.

Bestätigen Sie den konfigurierten Pfad, das Ausstellungsdatum und das Feld für die nächste Aktualisierung, bevor Sie der Datei überhaupt trauen.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

Vergleichen Sie die Seriennummer in der CRL mit der Seriennummer auf dem Zertifikat, das Sie behalten wollen. Dieser Vergleich ist der ganze Test, und ihn einmal mit dem Auge zu machen ist mehr wert, als einem Skript zu trauen, das niemand gelesen hat. Verteilen Sie die aktualisierte CRL über den Pfad, den das Gateway bereits liest. Eine CRL im falschen Verzeichnis erzwingt nichts, und kein Client-Log wird sie erwähnen.

Ersetzen, dann beide Ergebnisse beweisen

Stellen Sie den Ersatz unter demselben gemeinsamen Namen aus, notieren Sie beide Seriennummern, und widerrufen Sie erst dann die alte. Diese Reihenfolge hält eine funktionierende Identität verfügbar, während Sie die Änderung vorbereiten.

Testen Sie zuerst den Ersatz: Er sollte sich authentifizieren und erreichen, worauf sein Name Anspruch hat. Testen Sie dann das alte Zertifikat und bestätigen Sie, dass es abgelehnt wird, denn ein erfolgreicher Ersatz sagt nichts über den Widerruf aus. Wenn sich beide noch verbinden, wird die Widerrufseingabe nicht gelesen oder die alte Seriennummer wurde nie aufgeführt. Wenn sich keines verbindet, haben Sie die Zulassungsregel gebrochen, nicht die Anmeldedaten.

Bereits aufgebaute Sitzungen sind eine separate Angelegenheit, da der Widerruf für neue Authentifizierungen gilt, sofern das Gateway nicht auch so konfiguriert ist, dass es laufende Verbindungen trennt. Entscheiden Sie, ob eine sofortige Entfernung erforderlich ist, bevor Sie sie jemandem versprechen.

Was eine Namensprüfung niemals leisten kann

Eine Positivliste beantwortet, ob diese Identität sich verbinden darf. Sie kann nicht sagen, welches Zertifikat diese Identität verwendet hat, und sie wird ältere Anmeldedaten zulassen, solange sie gültig und nicht widerrufen bleiben. Diese Lücke zeigt sich während eines Vorfalls, wenn der Ersatz vor Monaten ausgestellt wurde und der Vorgänger noch funktioniert.

Wo Kontrolle auf Zertifikatsebene erforderlich ist, verwenden Sie einen Mechanismus, der das Zertifikat benennt: CRL-Einträge oder einen Verifizierungs-Hook, der einen Fingerabdruck prüft, den der Betreiber pflegt. Beides kostet Wartung, und beides ist ehrlich über das Objekt, das es untersucht. Das OpenVPN-2.6-Handbuch dokumentiert crl-verify und klientspezifische Zulassung als getrennte Optionen aus genau diesem Grund.

Schreiben Sie auf, welche Kontrolle welche Aufgabe erledigt, und testen Sie dann den negativen Fall. Ein Widerruf, den Sie nie eine Verbindung haben ablehnen sehen, ist eine Konfiguration, von der Sie hoffen, dass sie funktioniert.