Warum lehnt OpenConnect das Gateway nach einem Zertifikatstausch ab?

Gateways tauschen Zertifikate aus, und ein Client, der gestern noch verbunden war, bleibt beim ersten TLS-Austausch stehen. Die Meldung nennt einen Prüfgrund statt eines Netzwerkfehlers, und die Maschine selbst hat sich nicht verändert, was der nützliche Hinweis ist. Was zerbrochen ist, ist die Beziehung zwischen dem jetzt vorgelegten Zertifikat und den Wurzeln, die der Client zu berücksichtigen bereit ist. Das zu reparieren ist eine Vertrauensentscheidung, also treffen Sie sie, bevor Sie eine Option eintippen.

Lesen Sie den Fehler, bevor Sie irgendeine Vertrauenseinstellung ändern

Ein Fehler der Art „fehlender Unterzeichner“ bedeutet, dass die Kette an etwas endet, das der Client nicht akzeptiert. Das kann ein erneuertes Zertifikat einer internen Stelle sein, ein Ersatz von einer öffentlichen Stelle oder ein Gerät in der Mitte, das sein eigenes Zertifikat vorlegt. Allein der Wortlaut kann diese Fälle nicht unterscheiden, also sehen Sie sich den Aussteller an, bevor Sie entscheiden.

Führen Sie die Verbindung einmal im Vordergrund aus und lassen Sie sie scheitern, denn die interaktive Ausgabe enthält den Servernamen, die Ausstellerkette und den Fingerabdruck, den der Client berechnet hat. Vergleichen Sie diesen Aussteller mit einer Stelle, die Ihre Organisation tatsächlich betreibt. Wenn sich der Fingerabdruck geändert hat, der Aussteller aber nicht, behandeln Sie das als verdächtig, bis eine Erneuerung über einen Kanal bestätigt wird, dem Sie bereits vertrauen. An dieser Stelle zu raten, ist der Weg, auf dem jemand am Ende den Schlüssel eines Abfängers anheftet.

Notieren Sie die Client-Version in derselben Notiz. Ein guter Teil der Fehler, die wie Vertrauensprobleme aussehen, kommt von einem älteren Client, der auf einen neueren Gateway-Austausch trifft.

Zwischen Vertrauen in den Aussteller und dem Anheften eines Schlüssels wählen

Beide Optionen lassen die Verbindung gelingen. Sie brechen später auf entgegengesetzte Weise, deshalb gehört die Wahl zu dem Fehler, den Sie tolerieren können.

Greifen Sie zur CA-Datei, wenn das Zertifikat von einer Stelle stammt, die Sie unabhängig prüfen können, denn Erneuerungen funktionieren dann weiter, ohne Client-Argumente anzufassen. Paaren Sie sie mit dem Schalter, der Systemwurzeln deaktiviert, sonst kann eine öffentliche Stelle die Prüfung in Ihrem Namen erfüllen. Heften Sie stattdessen an, wenn das Gateway keine CA hat, die Sie beschaffen können, oder wenn die engstmögliche Ausnahme das Ziel ist. Keiner der Wege ist abstrakt sicherer: Die CA skaliert über Erneuerungen, das Anheften ist leichter zu überprüfen.

Welchen Sie auch wählen, der vertrauenswürdige Wert muss über einen Kanal eintreffen, dem schon vor der Änderung vertraut wurde. Ein Administrator, eine Konsolensitzung auf dem Gateway oder eine vorab genommene Kopie qualifizieren sich alle. Den Fingerabdruck zu kopieren, den die Abfrage anzeigt, ist bequem und genau das, worauf ein Abfänger hofft.

Setzen Sie den Wert in den Befehl, den Sie tatsächlich starten

Das Anheften reist in einer Serverzertifikat-Option, und ihr Präfix entscheidet über die Kodierung: hexadezimale Public-Key-Digests unter sha1 oder sha256 und das base64-Schlüsselanhängen unter pin-sha256. Wird sie angegeben, ist auch das Systemvertrauen für diesen Lauf deaktiviert, sodass der angeheftete Schlüssel die ganze Entscheidung wird.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Der Client gleicht einen gekürzten Digest ab und akzeptiert nur vier Zeichen nach dem Präfix, was eine Falle und keine Bequemlichkeit ist. Ein verkürzter Wert läuft lokal durch und identifiziert dennoch nicht das Gateway, das Sie beabsichtigt hatten. Kopieren Sie die vollständige Zeichenkette, die der Client beim ersten Versuch ausgegeben hat, statt sie aus einer Meldung neu zu tippen. Verschieben Sie dann die fertige Option in das Wrapper-Skript, die Unit-Datei oder das Profil, das die Verbindung startet, damit die Vertrauensentscheidung überprüfbar bleibt und spätere Bearbeitungen bewusst erfolgen.

Desktop-Starter und das NetworkManager-Plugin speichern ihre eigene Kopie der Verbindungsargumente. Ein auf der Platte bearbeitetes Skript erreicht kein früher importiertes Profil, sodass der gespeicherte Wert weiter gewinnt.

Bewältigen Sie eine Schlüsselrotation, ohne sich auszusperren

Die Option darf mehrfach angegeben werden, sodass eine geplante Änderung den alten und den neuen Schlüssel gemeinsam akzeptieren kann. Fügen Sie das neue Anheften hinzu, bevor das Gateway umschaltet, behalten Sie beide in der Liste, solange Sitzungen migrieren, und entfernen Sie das ausgemusterte, sobald der alte Schlüssel weg ist. Dieses Zeitfenster braucht einen Verantwortlichen, denn ein vergessenes doppeltes Anheften lässt einen Schlüssel vertraut, ohne dass jemand ihn beobachtet. Ein Neuaufbau, der ein frisches Schlüsselpaar erzeugt, bricht ein reines Anheften, und die Wiederherstellung ist dasselbe Verfahren in die andere Richtung.

Schreiben Sie das Änderungsdatum neben das Anheften. Ein Anheften ohne Überprüfungsdatum ist ein künftiger Ausfall mit einer verwirrenden Fehlermeldung.

Schließen Sie die Client-Version aus, bevor Sie Vertrauen bearbeiten

Ein veralteter Client kann scheitern, während er eine Authentifizierungsantwort parst, die das Gateway seither verändert hat, und die Oberflächenmeldung spricht noch von der Verbindung statt vom Parser. Vergleichen Sie die installierte Version mit dem, was das Gateway dokumentiert, und testen Sie ein aktuelles Paket in einem Wegwerfprofil, bevor Sie eine Vertrauenseinstellung ändern.

openconnect --version

Prüfen Sie nach der Reparatur zwei Dinge statt eines: Das Portal lädt durch den Tunnel, und eine gewöhnliche interne Adresse antwortet. Ein abgeschlossener Handshake beweist nur, dass die Vertrauensentscheidung akzeptiert wurde.