Ablaufendes ConnMan-OpenConnect-Cookie, kein Zertifikatsproblem

ConnMan funktioniert einen Nachmittag lang und verweigert dann, und die Journalzeile nennt die Zertifikatsprüfung. Diese Zeile schickt Leute zu CA-Bündeln, die nie kaputt waren. Zwei verschiedene Fehler erzeugen fast dieselbe Form des Scheiterns: Das Sitzungs-Cookie läuft ab, oder das Serverzertifikat hat sich tatsächlich geändert. Sie lassen sich in etwa einer Minute trennen, und nur einer von beiden hat überhaupt mit dem Fingerabdruck zu tun.

Zwei Fehler, eine verwirrende Logzeile

Sie trennen sich an zwei Beobachtungen, von denen keine ein zweites Lesen braucht. Die erste ist, wann der Fehler begann: Ein abgelaufenes Cookie kommt nach Stunden oder Tagen Arbeit, und ein ersetztes Zertifikat kommt direkt nach einer Gateway-Änderung.

Der Test dauert eine Minute und ist der authenticate-Lauf unten. Vergleichen Sie dessen FINGERPRINT mit OpenConnect.ServerCert in der Datei. Ein identischer Fingerabdruck mit einem anderen COOKIE bedeutet, nur das Cookie zu ersetzen. Ein anderer Fingerabdruck bedeutet, dass das Serverzertifikat wirklich gewechselt hat, also heften Sie es bewusst neu an und halten Sie fest, wer das genehmigt hat.

Erzeugen Sie das Material, statt es zu tippen

ConnMan hat keinen Importschritt für ein OpenConnect-Profil, anders als NetworkManager. Es liest eine Provisioning-Datei, deren Werte vorab erzeugt werden müssen, und der unterstützte Weg, sie zu erzeugen, ist der authenticate-Modus von OpenConnect.

sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
  --authenticate --user myuser vpn.example.com

Die Ausgabe druckt vier Werte: POST, COOKIE, HOST und FINGERPRINT. Der Fingerabdruck mit dem Präfix sha256: ist die Server-Anheftung. Das Cookie ist das Sitzungsartefakt mit einer Lebensdauer, die das Gateway bestimmt. Behandeln Sie beide als verschiedene Arten von Geheimnis: Sie laufen nach unterschiedlichen Zeitplänen ab, und nur bei einem wird erwartet, dass er sich ändert.

Die Datei trägt beides, und beides altert unterschiedlich

Die Provisioning-Datei liegt unter /var/lib/connman-vpn/ und wird pro Verbindung vom VPN-Daemon gelesen, nicht vom Tray-Applet. Behalten Sie den Verbindungsnamen im globalen Abschnitt und die Protokolldetails im Anbieterabschnitt.

[global]
Name = Company VPN

[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...

Verwenden Sie den Hostnamen, den das Portal tatsächlich bedient. Eine nackte IP-Adresse kann die Zertifikatsprüfung bestehen und trotzdem scheitern, weil die Appliance auf dem virtuellen Host routet und den Namen erwartet.

systemctl status connman-vpn --no-pager   # is the daemon even installed and running
sudo systemctl restart connman-vpn       # after the file edit
journalctl -u connman-vpn --since '1 hour ago'  # after the connection attempt

Was das Journal tatsächlich zeigt

Der Tooltip im Tray wird nicht sagen, welchen Fehler Sie haben. Das Journal schon, wenn Sie die Abfolge lesen statt der ersten beunruhigenden Zeile. Ein veraltetes Cookie zeigt typischerweise, dass die TLS-Aushandlung abgeschlossen ist und die HTTP-Schicht danach ablehnt; deshalb stehen die Worte über Zertifikate neben einem Autorisierungsfehler.

Vergleichen Sie einen frischen authenticate-Lauf mit den Werten in der Datei. Stimmt der Fingerabdruck und unterscheidet sich nur das Cookie, haben Sie Ihre Antwort, ohne Vertrauenseinstellungen anzufassen.

Erneuern Sie das abgelaufene Feld

Wiederholen Sie den authenticate-Befehl, ersetzen Sie OpenConnect.Cookie und starten Sie den Daemon neu. Lassen Sie den Fingerabdruck in Ruhe, es sei denn, die frische Ausgabe zeigt einen anderen Wert; dann wurde das Serverzertifikat wirklich ersetzt, und ein neues Anheften ist eine Entscheidung, die jemand festhalten sollte, statt sie aus einer Fehlermeldung zu kopieren.

Die Erneuerung zu automatisieren ist vernünftig: Ein kleines Skript liest das Passwort von der Standardeingabe, führt den authenticate-Modus aus und schreibt nur die Cookie-Zeile neu. Halten Sie die Anmeldedaten aus dem Skript heraus und nur für das Konto lesbar, das es ausführt, und machen Sie das Neuschreiben atomar, damit ein fehlgeschlagener Lauf keine halb geschriebene Datei hinterlässt.

Wenn die Erneuerung alle paar Stunden nötig ist, schreiben Sie das Intervall auf. Es ist eine Eigenschaft der Sitzungsrichtlinie des Gateways, und sie entscheidet, ob die Erneuerung automatisiert oder eine längere Sitzung verlangt werden sollte.