Ihr VPN-Zertifikat läuft heute ab: Was tatsächlich stoppt

Der Ablaufalarm wird ausgelöst, der Tunnel überträgt weiterhin Verkehr, und niemand ist sich einig, ob das Datum eine Rolle spielt. Es spielt eine Rolle, aber nicht immer in dem Augenblick, der auf dem Zertifikat steht. Ein abgelaufenes Zertifikat stoppt neue Authentifizierungen und es stoppt die Revalidierungen, die manche Implementierungen innerhalb einer langlebigen Sitzung durchführen. Ob Ihr bestehender Tunnel um Mitternacht stirbt, hängt vom Protokoll, vom Client und von den Neuverhandlungseinstellungen des Servers ab. Planen Sie die Erneuerung vor dem Datum und prüfen Sie sie mit einer neuen Anmeldung statt mit der Sitzung, die bereits offen war.

Finden Sie heraus, welches Zertifikat tatsächlich abläuft

Ein Deployment enthält ein Server-Blattzertifikat, Client-Anmeldedaten, ein oder mehrere Zwischenzertifikate und einen Vertrauensanker, und sie laufen nicht gemeinsam ab. Lesen Sie das im Fehler genannte Zertifikat und die Kette, mit der es vorgelegt wurde, nicht die erste Datei im Profilverzeichnis. Ein Server-Blattzertifikat, das sich sauber erneuern lässt, kann trotzdem fehlschlagen, wenn das Zwischenzertifikat darüber abgelaufen ist. Notieren Sie Subject, Aussteller, not-after und den Deployment-Ort jeder Datei, bevor Sie etwas ändern.

Der Vertrauensanker ist normalerweise das langlebigste Objekt und die unwahrscheinlichste Ursache.

Warum eine laufende Sitzung das Datum überleben kann

Die Authentifizierung erfolgt beim Verbindungsaufbau, und manche Protokolle prüfen die Identität später erneut. OpenVPN verhandelt den Datenkanal per Timer neu, sodass eine Neuverhandlung mit einem abgelaufenen Zertifikat fehlschlägt, obwohl der Tunnel seit Stunden läuft. Implementierungen, die nie revalidieren, können eine etablierte Sitzung über das Ablaufdatum hinaus tragen, weshalb «es funktioniert noch» kein Beweis ist. Keines der beiden Verhaltensweisen ist etwas, worauf man planen kann.

Behandeln Sie das Datum als Frist für neue Anmeldungen und die Sitzungslebensdauer als geliehene Zeit.

Prüfen Sie die Uhr, bevor Sie das Zertifikat beschuldigen

Die Gültigkeit wird gegen die lokale Uhr bewertet, daher meldet ein Gerät mit falscher Zeit einen Gültigkeitsfehler für ein völlig aktuelles Zertifikat. Prüfen Sie Client, Server und jedes Gerät auf dem Pfad.

Eine Uhr, die beim Start zurückgesetzt wird, erklärt Fehler, die erst nach einem Stromausfall auftreten.

Erneuern Sie über die Autorität, die es ausgestellt hat

Behalten Sie die Identität, den vorgesehenen Zweck und eine kompatible Schlüsselkonfiguration bei. Wenn die Erneuerung einen neuen Aussteller oder ein angeheftetes Zertifikat einführt, brauchen Clients eine koordinierte Vertrauensaktualisierung statt eines Dateiaustauschs auf dem Server. Schützen Sie private Schlüssel während Ausstellung und Verteilung, denn ein erneuertes Zertifikat widerruft keinen kompromittierten alten Schlüssel. Ein Passwort-Reset ist keine Erneuerung, was auch immer das Ticket sagt.

Veröffentlichen Sie die neue Kette vollständig, denn ein Blatt ohne sein Zwischenzertifikat ist eine halbe Erneuerung, die nur auf Rechnern funktioniert, die es bereits zwischengespeichert haben.

Beweisen Sie es mit einer neuen Anmeldung, behalten Sie einen Rollback

Stellen Sie nach dem Deployment eine neue zulässige Verbindung von einem repräsentativen Client her und testen Sie die tatsächliche Anwendung. Prüfen Sie, ob die Kette so ausgeliefert wird, wie Clients es erwarten, und ob etwaige Sperrinformationen erreichbar sind. Behalten Sie einen Rollback, der nicht darauf angewiesen ist, abgelaufenem Material zu vertrauen, damit Sie ohne Schwächung der Prüfung zum vorherigen Zustand zurückkehren können. Entfernen Sie die veralteten Dateien erst, nachdem der Ersatz verifiziert ist.

Bestehende Sitzungen spiegeln möglicherweise noch den früheren Zustand wider, beweisen also in keine Richtung etwas.

Die Reihenfolge, die ich am Tag verwende

Bestätigen Sie das ablaufende Objekt und seine Kette, dann bestätigen Sie die Uhren:

• Welches Zertifikat abläuft und zu welcher Kette es gehört.
• Ob jedes Zwischenzertifikat deployt und veröffentlicht ist.
• Client- und Serveruhr stimmen innerhalb einer angemessenen Marge überein.
• Eine neue Anmeldung gelingt von einem repräsentativen Client.
• Sperrinformationen sind erreichbar.
• Es gibt einen Rollback, der die Prüfung nicht schwächt.

Erneuern Sie dann, deployen Sie die vollständige Kette, testen Sie mit einer neuen Anmeldung und räumen Sie erst danach auf. Gültigkeitszeiträume und die Regeln zu ihrer Bewertung sind in RFC 5280 definiert, und das Datum ist keine Überraschung, wenn Ihr Monitoring das Objekt beobachtet hat, das tatsächlich abläuft.