Was passiert, wenn Sie eine VPN-Zertifizierungsstelle ersetzen

Eine VPN-Zertifizierungsstelle zu ersetzen ist kein Dateitausch. In dem Moment, in dem die neue CA ihr erstes Zertifikat signiert, muss jeder Validator, der weiterhin nur der alten vertraut, eine Entscheidung treffen, und Hosts, die den neuen Anker nie erhalten, weisen weiterhin gute Peers zurück. Ich habe es in beide Richtungen schiefgehen sehen: Das Gateway lernte die neue CA, die Clients nicht, also scheiterten neue Verbindungen, während bereits bestehende Tunnel stehen blieben und den Ausfall wie ein Routingproblem aussehen ließen. Hier steht, was sich ändert, in der Reihenfolge, in der Fehler auftreten.

Ein Austausch, zwei getrennte Änderungen

Eine Zertifizierungsstelle ist ein Name, ein öffentlicher Schlüssel und der private Schlüssel, der signiert. Validatoren vertrauen nie „der CA“ im Abstrakten. Sie vertrauen einem bestimmten Zertifikat, das bereits in einem Trust Store liegt, und akzeptieren einen Aussteller nur, wenn eine Signaturkette bis zu dieser gespeicherten Kopie reicht. Der Austausch der CA ändert daher zwei Dinge, die unabhängig voneinander scheitern: welche Anker akzeptiert werden und welche Peer-Identitäten unter ihnen ausgestellt wurden.

Die meisten VPN-Installationen validieren in beide Richtungen. Der Client authentifiziert das Gateway-Zertifikat, und das Gateway authentifiziert das Client-Zertifikat. Ein Wechsel, der nur das Client-Bundle erneuert, lässt den Server jeden Client zurückweisen, der noch eine Identität der alten CA vorzeigt, und der umgekehrte Fall ist ebenso häufig. Erfassen Sie zuerst die Durchsetzungspunkte: Client-Trust-Stores, die ca-Datei des Gateways, jeden TLS-terminierenden Proxy davor und die Prüfung, die den Endpunkt von außen testet.

Was ein Validator prüft, der Reihe nach

Die Pfadvalidierung steigt vom Peer-Zertifikat über etwaige Zwischenzertifikate auf, bis sie einen vertrauenswürdigen Anker erreicht. Auf jeder Stufe prüft sie die Signatur, kontrolliert, dass jedes Zertifikat in seinem Gültigkeitsfenster liegt, und bestätigt, dass Grundbeschränkungen und Schlüsselverwendung dem Aussteller das Signieren erlauben. Erst dann sieht die Anwendung das Blattzertifikat an: Die alternativen Subjektnamen müssen den angewählten Namen abdecken, und die erweiterte Schlüsselverwendung muss Server- oder Client-Authentifizierung erlauben.

Um diesen Durchlauf offline nachzustellen, richten Sie -CAfile auf genau das Bundle, das Sie ausrollen werden, und nicht auf den System-Store. Sonst testen Sie den Host, nicht die Änderung:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Dieser Befehl funktioniert nur gegen einen einfachen TLS-Listener wie die HTTPS-Administrationsseite des Gateways; der Steuerkanal von OpenVPN kommt vor TLS, deshalb kann s_client den Tunnel-Handshake nicht inspizieren.

Die Pfadbildungsregeln hinter diesen Fehlern stehen in RFC 5280 Abschnitt 6. Sie erklären die Fehlschläge, die sonst willkürlich wirken: ein abgelaufenes Zwischenzertifikat, an das sich niemand erinnerte, ein Zertifikat, dessen Schlüsselverwendung das Signieren verbietet, oder eine Namensbeschränkung, die den getesteten Host ausschließt.

Warum der alte Tunnel weiterläuft

TLS und OpenVPN halten eine etablierte Sitzung am Leben, nachdem der Handshake abgeschlossen ist. Nichts validiert das Peer-Zertifikat pro Paket neu, also leitet ein Client, der sich vor der Änderung verbunden hat, weiterhin Verkehr, bis er neu verhandelt, sich neu verbindet oder der Tunnel wegfällt. Genau diese Lücke sorgt dafür, dass ein CA-Austausch eine Stunde lang gut aussieht und dann im schlechtesten Moment scheitert: Ein Laptop wacht aus dem Ruhezustand auf, eine NAT-Zuordnung läuft ab, ein Gateway startet neu.

Sitzungswiederaufnahme dehnt die Illusion weiter. Ein TLS-Session-Ticket erlaubt dem Client die Rückkehr ohne erneutes Senden von Zertifikaten, und die Wiederaufnahme überspringt die Pfadvalidierung, weil der erste Handshake sie bereits erledigt hat. Der ehrliche Test ist deshalb ein vollständiger Handshake in einem frischen Prozess. Starten Sie den Client neu, statt den Tunnel neu zu verbinden, und erwägen Sie in einem Testprofil, Tickets zu deaktivieren, damit der Wiederaufnahmepfad eine kaputte Kette nicht verbergen kann.

Halten Sie die Ebene des statischen Schlüssels davon getrennt. tls-auth fügt dem Steuerkanal einen HMAC hinzu, tls-crypt verschlüsselt und authentifiziert ihn, und keines von beiden trägt Zertifikatsmaterial, sodass die Rotation eines der beiden eine eigene Änderung mit eigenem Fehlermodus ist. Installationen, die beides vermengen, enden mit einem Client, dessen statischer Schlüssel in Ordnung ist, dessen Zertifikat veraltet ist und dessen Fehlermeldung keines von beidem erwähnt.

Die Falle des wiederverwendeten Subjektnamens

Es ist verlockend, den Distinguished Name des Vorgängers wiederzuverwenden, damit sich nachgelagert nichts ändern muss. Das hält die Ausstellerzeile in der Oberfläche stabil und zerstört das eine Signal, das Sie brauchen. Zwei Zertifikate mit identischen Subjekten und verschiedenen Schlüsseln lassen sich nicht am Namen unterscheiden, also gibt ein Bundle mit beiden Ankern dem Validator zwei Kandidaten und keine Regel zur Auswahl.

Die Pfadbildung kann dann den falschen wählen, „lokales Ausstellerzertifikat nicht abrufbar“ melden, obwohl der richtige Anker vorhanden ist, oder auf einem Host gelingen und auf einem anderen mit demselben Bundle scheitern, weil die Kandidatenreihenfolge abwich. Muss der Name wiederverwendet werden, halten Sie beide Anker während der Übergangszeit in getrennten Dateien und laden sie ausdrücklich, und führen Sie sie erst zusammen, wenn jeder Peer den neuen Aussteller vorzeigt. Andernfalls geben Sie dem Ersatz einen eigenen Common Name — ein Generations- oder Datumssuffix genügt —, damit Protokolle und Fehlertexte sagen, unter welcher Autorität ein scheiternder Peer ausgestellt wurde.

Ein Wechsel, der das Netz nicht ausfallen lässt

Für einen geplanten Austausch akzeptieren Sie beide Anker für ein begrenztes Zeitfenster, statt in einem Schritt umzuschalten. Stellen Sie die neue CA und ihre Zwischenzertifikate aus, legen Sie den neuen Anker neben dem alten in das Bundle jedes Validators, und beginnen Sie erst danach, Peer-Zertifikate daraus auszustellen. Peers mit alten Identitäten validieren gegen den alten Anker; neue arbeiten gegen den neuen Anker.

In dieser Reihenfolge durchgeführt ist jeder Schritt umkehrbar. Der Fehlschlag, den Sie vermeiden, ist die gleichzeitige Umschaltung, bei der ein Client, der das Bundle-Update verpasst hat, auf ein Gateway trifft, das den alten Anker bereits zurückgezogen hat, der Handshake stirbt und kein Protokoll sagt, welche Seite veraltet ist.

Ziehen Sie in der Gegenrichtung zurück. Stellen Sie jede Identität neu aus, die überleben muss, bestätigen Sie, dass jede die neue Kette vorzeigt, und entfernen Sie dann den alten Anker aus den Bundles. Nehmen Sie den privaten Schlüssel der alten CA außer Betrieb, denn ein Aussteller, der noch signieren kann, bedeutet, dass der Wechsel nicht abgeschlossen ist. Bewahren Sie Zertifikate und Ausstellungsnachweise für Audits auf. Ein verlorener Aussteller wird auf dasselbe Vertrauen zurückgeführt; eine Offenlegung erfordert neue Identitäten und keine Rückkehr zum alten Anker.

Prüfen Sie das Ergebnis, nicht die Dateiliste

Eine Vertrauensdatei im erwarteten Verzeichnis beweist wenig. Die Anwendung kann einen anderen Pfad, ein anderes Format oder eine Kopie in einem Paket lesen, das ein Upgrade ersetzt. Prüfen Sie das Verhalten an beiden Enden, nicht die Existenz einer Datei.

Bestätigen Sie, dass eine frische Verbindung mit einer neuen Identität gelingt, und bestätigen Sie dann, dass eine von der zurückgezogenen CA ausgestellte Identität abgelehnt wird. Dieser zweite Test ist der, den alle überspringen, und der einzige, der zeigt, dass die alte Autorität keinen Zugang mehr gewährt. Wo die Installation auf CRLs oder OCSP setzt, prüfen Sie, ob die Verteilungspunkte in den neuen Zertifikaten auflösen und der Responder von den abfragenden Peers erreichbar ist.

Schließen Sie mit einem Client ab, der sich nie verbunden hat: Löschen Sie seinen Profilzustand, verbinden Sie ihn und lesen Sie die ausgehandelte Kette. Ein Peer, der eine gecachte Sitzung wiederaufnimmt, wird munter melden, die Migration habe funktioniert, obwohl er nichts validiert hat.