Pourquoi OpenConnect rejette-t-il la passerelle après un changement de certificat ?

Les passerelles remplacent des certificats, et un client qui se connectait hier commence à s’arrêter dès le premier échange TLS. Le message nomme une raison de vérification plutôt qu’une panne réseau, et la machine elle-même n’a pas changé, ce qui est l’indice utile. Ce qui a cassé, c’est la relation entre le certificat présenté désormais et les racines que le client accepte d’envisager. Réparer cela relève d’une décision de confiance, alors prenez-la avant de taper une option.

Lisez l’échec avant de changer le moindre réglage de confiance

Une erreur de type signataire manquant signifie que la chaîne s’arrête sur quelque chose que le client n’accepte pas. Il peut s’agir d’un certificat renouvelé par une autorité interne, d’un remplacement par une autorité publique, ou d’un dispositif au milieu qui présente son propre certificat. Le libellé seul ne peut pas distinguer ces cas, alors regardez l’émetteur avant de décider.

Lancez la connexion une fois au premier plan et laissez-la échouer, car la sortie interactive porte le nom du serveur, la chaîne d’émetteurs et l’empreinte calculée par le client. Comparez cet émetteur à une autorité que votre organisation exploite réellement. Si l’empreinte a changé alors que l’émetteur non, traitez-la comme suspecte jusqu’à ce qu’un renouvellement soit confirmé par un canal auquel vous faites déjà confiance. Deviner à ce stade, c’est ainsi qu’une personne finit par épingler la clé d’un intercepteur.

Notez la version du client dans la même note. Une bonne part des échecs qui ressemblent à des problèmes de confiance viennent d’un client plus ancien rencontrant un échange de passerelle plus récent.

Choisir entre faire confiance à l’émetteur et épingler une clé

Les deux options font réussir la connexion. Elles cassent ensuite de manières opposées, aussi le choix appartient-il à l’échec que vous pouvez tolérer.

Recourez au fichier d’AC quand le certificat vient d’une autorité que vous pouvez vérifier indépendamment, car les renouvellements continuent alors de fonctionner sans toucher aux arguments du client. Associez-le à l’interrupteur qui désactive les racines système, sinon une autorité publique peut satisfaire le contrôle à votre place. Épinglez plutôt lorsque la passerelle n’a pas d’AC que vous puissiez obtenir ou lorsque l’exception la plus étroite possible est l’objectif. Aucune voie n’est plus sûre dans l’absolu : l’AC s’adapte au fil des renouvellements, l’épinglage est plus facile à relire.

Quel que soit votre choix, la valeur de confiance doit arriver par un canal qui était de confiance avant que le changement n’ait lieu. Un administrateur, une session console sur la passerelle ou une copie prise à l’avance conviennent tous. Copier l’empreinte qu’affiche l’invite est commode et correspond exactement à ce qu’un intercepteur espère.

Placez la valeur dans la commande que vous lancez réellement

L’épinglage voyage dans une option de certificat de serveur, et son préfixe décide de l’encodage : des empreintes hexadécimales de clé publique sous sha1 ou sha256, et l’épinglage de clé en base64 sous pin-sha256. Fournir cette option désactive aussi la confiance système pour cette exécution, si bien que la clé épinglée devient toute la décision.

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

Le client fait correspondre une empreinte tronquée, en acceptant aussi peu que quatre caractères après le préfixe, ce qui est un piège plutôt qu’une commodité. Une valeur raccourcie passe localement et n’identifie toujours pas la passerelle que vous visiez. Copiez la chaîne complète imprimée par le client à la première tentative au lieu de la retaper depuis un message. Ensuite, déplacez l’option terminée dans le script d’enveloppe, le fichier d’unité ou le profil qui lance la connexion, afin que la décision de confiance soit relisible et que les modifications ultérieures soient délibérées.

Les lanceurs de bureau et le greffon NetworkManager stockent leur propre copie des arguments de connexion. Un script modifié sur disque n’atteint pas un profil importé auparavant, donc la valeur stockée continue de l’emporter.

Gérer une rotation sans s’enfermer dehors

L’option peut être donnée plus d’une fois, si bien qu’un changement planifié peut accepter ensemble la clé sortante et la clé entrante. Ajoutez le nouvel épinglage avant que la passerelle ne bascule, gardez les deux listés pendant que les sessions migrent, et retirez celui qui est abandonné une fois l’ancienne clé partie. Cette fenêtre a besoin d’un responsable, car un double épinglage oublié laisse une clé de confiance sans personne pour la surveiller. Une reconstruction qui produit une nouvelle paire de clés casse un épinglage pur, et la reprise est la même procédure dans l’autre sens.

Écrivez la date du changement à côté de l’épinglage. Un épinglage sans date de revue est une panne future portant un message d’erreur déroutant.

Écarter la version du client avant de modifier la confiance

Un client daté peut échouer en analysant une réponse d’authentification que la passerelle a modifiée depuis, et le message de surface parle toujours de la connexion plutôt que de l’analyseur. Comparez la version installée à ce que la passerelle documente, et testez un paquet actuel dans un profil jetable avant de changer le moindre réglage de confiance.

openconnect --version

Après la réparation, vérifiez deux choses plutôt qu’une : le portail se charge à travers le tunnel, et une adresse interne ordinaire répond. Une poignée de main achevée prouve seulement que la décision de confiance a été acceptée.