Erneuertes VPN-Zertifikat: manche Clients lehnen es weiterhin ab

Die Hälfte des Bestands verbindet sich nach der Erneuerung wieder, und drei Geräte verweigern, jedes mit einer Warnung zur Identität des Gateways. Die Erneuerung selbst ist Routine. Was diese drei Geräte halten, ist ein Pin auf das alte Objekt, und ein Pin ist keine CA-Liste, keine Namensprüfung und kein Eintrag in einem Trust Store. Vergleichen Sie die drei Mechanismen, bevor Sie irgendeinen Client anfassen.

Eine Erneuerung, zwei Verhaltensweisen

Die Clients, die sich wieder verbinden, haben eine Vertrauensentscheidung, die noch besteht, und die, die verweigern, haben eine Anforderung, die das neue Zertifikat nicht erfüllt. Dieser Unterschied ist Information, kein Rauschen. Lesen Sie die Meldung des scheiternden Clients genau. Eine Namensabweichung, ein unbekannter Aussteller und ein geänderter Fingerabdruck sind drei verschiedene Urteile, und nur das letzte deutet auf einen Pin.

Prüfen Sie außerdem, welches Profil der scheiternde Client gewählt hat. Eine importierte Kopie, die in ihrem eigenen Speicher lebt, ändert sich nicht, wenn der Administrator die Originaldatei anderswo bearbeitet.

Die Erneuerung ersetzt das Objekt, nicht nur das Datum

Ein Fingerabdruck identifiziert den kodierten Zertifikatsinhalt. Eine Erneuerung erzeugt ein neues Zertifikat, sodass sich der Fingerabdruck ändert, selbst wenn der Subjektname und der öffentliche Schlüssel identisch bleiben. Das ist erwartet und harmlos für Clients, die einer CA vertrauen und den Namen prüfen. Es ist fatal für einen Client, der so konfiguriert ist, dass er genau ein Zertifikat akzeptiert, und es ist auch fatal für einen Client, dessen Trust Store den neuen Aussteller nie erhalten hat.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

Die zweite Zeile beantwortet eine andere Frage: ob das Schlüsselpaar überlebt hat. Eine Erneuerung, die den Schlüssel wiederverwendet hat, behält diesen Wert und ändert nur das Zertifikat, was genau der Fall ist, in dem ein Administrator versucht ist, anzunehmen, dass sich nichts geändert hat. Prüfen Sie das Zertifikat, das bereitgestellt ist, nicht das auf dem Build-Host. Der Vergleich einer Datei in einem Repository beweist, was erzeugt wurde, nicht was ein Listener gerade präsentiert.

Lesen Sie, worauf der Client pinnt

Manche Clients halten einen Fingerabdruck in ihrem Profil und vergleichen ihn bei jeder Verbindung. Andere speichern ihn in einem Plattform-Trust-Store, und wieder andere verlassen sich nur auf eine CA. Die Reparatur unterscheidet sich in jedem Fall, also identifizieren Sie zuerst den Mechanismus.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Der erste Befehl zeigt einen Pin in einem konventionellen Profil; der zweite zeigt den Fingerabdruck, den der Endpunkt gerade tatsächlich ausliefert. Wenn sich die beiden unterscheiden, haben Sie den Fehler ohne Raten lokalisiert. Kleben Sie den neuen Wert nicht in jeden Client, der sich beschwert. Ein Client, der aus Aussteller-Gründen verweigert, wird weiter verweigern, und Sie haben sich selbst beigebracht, dass der Fingerabdruck das Problem war, als er es nicht war.

Vergleichen Sie das Zertifikat, das jeder Backend ausliefert

Wechselhafte Ergebnisse bedeuten meist mehr als einen Endpunkt, und eine Erneuerung, die auf einen Knoten angewendet wurde, lässt die anderen das alte Objekt präsentieren. Vergleichen Sie jeden Backend nach Adresse statt nach dem gemeinsamen Namen.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Ein Pool, in dem ein Knoten hinterherhinkt, erklärt einen Client, der beim zweiten Versuch verbindet und beim ersten scheitert. Es erklärt auch eine Überwachungsprüfung, die besteht, während Benutzer sich beschweren. Beheben Sie zuerst den Rückstand. Das Ausrollen der Vertrauenskonfiguration, bevor jeder Knoten das neue Zertifikat ausliefert, schafft ein Fenster, in dem nichts funktioniert, und das Ausrollen danach lässt Clients unvorhersehbar scheitern.

Ändern Sie Vertrauen über den verwalteten Weg

Bestätigen Sie den Ersatz über einen bereits vertrauenswürdigen administrativen Kanal, bevor Sie ihn irgendwo akzeptieren. Ein plausibles Ablaufdatum ist kein Eigentumsnachweis. Aktualisieren Sie die verwaltete Konfiguration über den Prozess, der sie besitzt, mit jeder geplanten Überschneidung akzeptabler Identitäten, und behalten Sie die Namensprüfung bei, die die Bereitstellung verlangt. Ein Pin ohne Namensprüfung ist ein schwächeres Design als das CA-Vertrauen, das er ersetzt hat.

Prüfen Sie dann pro Client: verbinden, die akzeptierte Identität bestätigen und die Zertifikatsversion notieren, der er jetzt vertraut. Eine einmal abgetane Warnung kehrt bei der nächsten Erneuerung gern zurück.