L'expiration du cookie ConnMan OpenConnect, pas un problème de certificat

ConnMan fonctionne un après-midi puis refuse, et la ligne du journal mentionne la vérification du certificat. Cette ligne envoie les gens vers des lots de CA qui n'ont jamais été cassés. Deux pannes différentes produisent presque la même forme d'échec : le cookie de session expire, ou le certificat du serveur a réellement changé. On les sépare en une minute environ, et une seule des deux concerne l'empreinte.

Deux pannes, une ligne de journal trompeuse

Elles se séparent sur deux observations, dont aucune ne demande une seconde lecture. La première est le moment où la panne a commencé : un cookie expiré arrive après des heures ou des jours de fonctionnement, et un certificat remplacé arrive juste après un changement de passerelle.

Le test d'une minute est l'exécution authenticate ci-dessous. Comparez son FINGERPRINT à OpenConnect.ServerCert dans le fichier. Une empreinte identique avec un COOKIE différent signifie qu'il faut remplacer le cookie seulement. Une empreinte différente signifie que le certificat du serveur a réellement changé : réépinglez-le délibérément et notez qui l'a approuvé.

Générez le matériel au lieu de le taper

ConnMan n'a pas d'étape d'importation pour un profil OpenConnect, contrairement à NetworkManager. Il lit un fichier de provisionnement dont les valeurs doivent être produites à l'avance, et la manière prise en charge de les produire est le mode authenticate d'OpenConnect.

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

La sortie affiche quatre valeurs : POST, COOKIE, HOST et FINGERPRINT. L'empreinte, préfixée par sha256:, est l'épinglage du serveur. Le cookie est l'artefact de session dont la durée de vie est décidée par la passerelle. Traitez-les comme deux types de secret différents : ils expirent selon des calendriers différents, et un seul est censé changer.

Le fichier porte les deux, et ils vieillissent différemment

Le fichier de provisionnement vit sous /var/lib/connman-vpn/ et est lu par connexion par le démon VPN, non par l'applet de la barre système. Gardez le nom de la connexion dans la section globale et les détails du protocole dans la section du fournisseur.

[global]
Name = Company VPN

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

Utilisez le nom d'hôte que le portail sert réellement. Une adresse IP nue peut passer le contrôle du certificat et échouer quand même, parce que l'appareil route sur l'hôte virtuel et attend le nom.

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

Ce que le journal montre réellement

L'infobulle de la barre système ne dira pas quelle panne vous avez. Le journal le dira, si vous lisez la séquence plutôt que la première ligne alarmante. Un cookie périmé montre généralement que la négociation TLS s'achève et que la couche HTTP refuse ensuite, ce qui explique pourquoi les mots sur les certificats voisinent avec un échec d'autorisation.

Comparez une exécution authenticate fraîche aux valeurs du fichier. Si l'empreinte correspond et que seul le cookie diffère, vous avez votre réponse sans toucher aux réglages de confiance.

Rafraîchissez le champ expiré

Répétez la commande authenticate, remplacez OpenConnect.Cookie et redémarrez le démon. Laissez l'empreinte tranquille sauf si la sortie fraîche montre une valeur différente ; dans ce cas le certificat du serveur a réellement été remplacé et un nouvel épinglage est une décision que quelqu'un doit consigner, pas un copier-coller depuis un message d'erreur.

Automatiser le rafraîchissement est raisonnable : un petit script lit le mot de passe sur l'entrée standard, exécute le mode authenticate et ne réécrit que la ligne du cookie. Gardez l'identifiant hors du script et lisible uniquement par le compte qui l'exécute, et rendez la réécriture atomique pour qu'une exécution ratée ne laisse pas un fichier à moitié écrit.

Si le rafraîchissement est nécessaire toutes les quelques heures, notez l'intervalle. C'est une propriété de la politique de session de la passerelle, et elle décide s'il faut automatiser le rafraîchissement ou demander une session plus longue.