Neue VPN-Anmeldungen scheitern bei gültigen Zertifikaten: die CRL prüfen

Zertifikate mit Monaten Restlaufzeit und Anmeldungen, die sofort scheitern, deuten auf zwei verschiedene Objekte mit zwei verschiedenen Uhren hin. Der Server weist Verbindungen ab, weil die Liste der gesperrten Zertifikate, die er heranzieht, ihr eigenes Ablaufdatum überschritten hat, nicht weil die Zertifikate der Nutzer veraltet sind. Das Erneuern eines Nutzerzertifikats ändert nichts an dieser Liste.

Die beiden Zeitpläne zu trennen ist die ganze Diagnose, und sie verändert, wie die Lösung aussehen muss.

Zwei Uhren, und nur eine davon ist das Zertifikat

Ein Zertifikat trägt ein Gültigkeitsfenster. Eine Zertifikatssperrliste trägt ihr eigenes Fenster, dazu einen Aussteller und eine Signatur, und Prüfer weigern sich, einer Liste zu vertrauen, deren Zeitpunkt der nächsten Aktualisierung verstrichen ist. Wenn das geschieht, legt der Client ein vollkommen gültiges Zertifikat vor, und der Server trennt die Verbindung trotzdem mit einer Meldung über die Liste. Nutzer lesen diese Meldung als 'das Zertifikat ist abgelaufen', was die Erneuerungsanfrage an die falsche Stelle schickt.

Die beiden Objekte haben außerdem verschiedene Eigentümer: das Zertifikat kommt von der CA, die es ausgestellt hat, während die Liste nach einem Zeitplan von demjenigen erzeugt wird, der diese CA betreibt. Ein Nutzer kann sie nicht aktualisieren, und das Neuausstellen von Zertifikaten kann sie nicht verlängern.

Lies die Liste, die der Dienst tatsächlich lädt

Beginne bei der laufenden Konfiguration statt bei der Datei, die du erwartest. Der Pfad bei crl-verify kann absolut sein, relativ zum Profil oder eine in ein Image eingebackene Kopie, und der Prüfer liest diese Kopie. Untersuche sie an Ort und Stelle mit openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate und vergleiche die Daten mit der Uhr des Servers.

Bestätige dann, dass die Datei wirklich die verwendete ist: prüfe ihre Signatur mit openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, das ein Prüfergebnis meldet, statt still Felder auszugeben. Eine Liste, die von einer anderen CA signiert wurde, oder eine veraltete Kopie in einem zweiten Verzeichnis scheitert genau wie eine abgelaufene.

Neu erzeugen aus der Sperrdatenbank, nicht von Grund auf

Die neue Liste muss aus der aktuellen Sperrdatenbank der CA stammen, über den genehmigten Signaturvorgang. Eine leere Liste zu erzeugen oder aus einer alten Sicherung des Index neu zu erzeugen hebt stillschweigend die Sperrung jeder Identität auf, die seit dieser Sicherung hinzugefügt wurde. Das verwandelt einen Anmeldeausfall in einen Sicherheitsrückschritt, und niemand merkt es, weil das Symptom verschwindet.

Halte den Erzeugungsschritt zusammen mit dem übrigen CA-Werkzeug unter Versionskontrolle, damit Intervall und Signaturschlüssel dokumentiert und nicht nur erinnert werden. Ein Runbook-Eintrag, der den Befehl, den Unterzeichner und das Veröffentlichungsziel nennt, genügt. Dann kann jeder im Bereitschaftsdienst neu erzeugen, ohne zu raten, welche Indexdatei maßgeblich ist. Speichere Seriennummer und Zeitpunkt der nächsten Aktualisierung der Liste zusammen mit dem Ausrollprotokoll.

Verteile dorthin, wo der Prüfer nachsieht

Kopiere die neue Liste an den Pfad, den der Dienst liest, setze Eigentümer und Modus so, dass das Dienstkonto sie lesen kann, andere aber nicht, und lade neu oder starte neu gemäß dem dokumentierten Verhalten. Wenn der Daemon die Liste beim Start zwischenspeichert, ändert das Ersetzen der Datei ohne Neuladen nichts, was der laufende Prozess bemerken würde. Bestätige den Zeitstempel, den der Prozess nach dem Neuladen meldet.

Wenn mehrere Dienste Clients prüfen, verteile an jeden von ihnen. Einen Endpunkt zu aktualisieren und einen anderen mit der alten Kopie zurückzulassen erzeugt einen Fehler, der nur bei den Nutzern auftritt, die auf dem zweiten landen. Halte eine kurze Liste dieser Endpunkte im selben Runbook. Prüfe nach dem Rollout das gemeldete Listendatum jedes Endpunkts, statt anzunehmen, dass die Kopie angekommen ist.

Mach die nächste Frist sichtbar, bevor sie verstreicht

Ein längeres Veröffentlichungsintervall senkt die Häufigkeit dieses Vorfalls, ohne einen Prozess zu schaffen. Wähle das Intervall nach der Richtlinie des Betreibers und alarmiere dann auf das Feld für die nächste Aktualisierung der verteilten Liste, mit genug Vorlauf zum Neuerzeugen und Verteilen. Alarmiere auf die verteilte Kopie, nicht auf den CA-Host, denn die verteilte Kopie ist das, was scheitert.

Prüfe nach dem Ausrollen beide Richtungen: ein erlaubter Nutzer verbindet sich, und eine bekannte gesperrte Identität scheitert weiterhin. Die zweite Prüfung ist die, die eine unvollständige Neuerzeugung abfängt, und sie kostet einen Befehl gegen ein Testprofil, das du genau zu diesem Zweck vorhältst.