Certificat VPN renouvelé : certains clients le rejettent encore

La moitié du parc se reconnecte après le renouvellement et trois appareils refusent, chacun avec un avertissement sur l’identité de la passerelle. Le renouvellement lui-même est une routine. Ce que ces trois appareils détiennent est un épinglage à l’ancien objet, et un épinglage n’est pas une liste de CA, une vérification de nom ni une entrée dans un magasin de confiance. Comparez les trois mécanismes avant de toucher le moindre client.

Un renouvellement, deux comportements

Les clients qui se reconnectent ont une décision de confiance qui passe encore, et ceux qui refusent ont une exigence que le nouveau certificat ne satisfait pas. Cette différence est une information, pas du bruit. Lisez le message du client défaillant avec précision. Une divergence de nom, un émetteur inconnu et une empreinte modifiée sont trois verdicts différents, et seul le dernier désigne un épinglage.

Vérifiez aussi quel profil le client défaillant a sélectionné. Une copie importée qui vit dans son propre magasin ne change pas lorsque l’administrateur modifie le fichier d’origine ailleurs.

Le renouvellement remplace l’objet, pas seulement la date

Une empreinte identifie le contenu encodé du certificat. Le renouvellement produit un nouveau certificat, donc l’empreinte change même lorsque le nom du sujet et la clé publique restent identiques. C’est attendu et inoffensif pour les clients qui font confiance à une CA et vérifient le nom. C’est fatal pour un client configuré pour accepter exactement un certificat, et c’est aussi fatal pour un client dont le magasin de confiance n’a jamais reçu le nouvel émetteur.

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

La deuxième ligne répond à une autre question : si la paire de clés a survécu. Un renouvellement qui a réutilisé la clé conserve cette valeur et ne change que le certificat, ce qui est exactement le cas où un administrateur est tenté de supposer que rien n’a changé. Inspectez le certificat qui est déployé, pas celui de l’hôte de compilation. Comparer un fichier dans un dépôt prouve ce qui a été généré, pas ce qu’un écouteur présente en ce moment.

Lisez ce que le client épingle

Certains clients conservent une empreinte dans leur profil et la comparent à chaque connexion. D’autres la stockent dans un magasin de confiance de la plateforme, et d’autres encore ne se fient qu’à une CA. La réparation diffère dans chaque cas, alors identifiez d’abord le mécanisme.

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

La première commande montre un épinglage dans un profil conventionnel ; la seconde montre l’empreinte que le point de terminaison sert réellement maintenant. Lorsque les deux diffèrent, vous avez localisé la panne sans deviner. Ne collez pas la nouvelle valeur dans chaque client qui se plaint. Un client qui refuse pour des raisons d’émetteur continuera de refuser, et vous vous serez appris que l’empreinte était le problème alors qu’elle ne l’était pas.

Comparez le certificat que sert chaque backend

Des résultats intermittents signifient généralement plus d’un point de terminaison, et un renouvellement appliqué à un nœud laisse les autres présenter l’ancien objet. Comparez chaque backend par adresse plutôt que par le nom partagé.

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

Un pool où un nœud est en retard explique un client qui se connecte à la deuxième tentative et échoue à la première. Il explique aussi un contrôle de supervision qui passe alors que les utilisateurs se plaignent. Corrigez d’abord le retard. Déployer la configuration de confiance avant que chaque nœud ne serve le nouveau certificat crée une fenêtre où rien ne fonctionne, et la déployer ensuite laisse les clients échouer de façon imprévisible.

Changez la confiance par la voie gérée

Confirmez le remplacement par un canal administratif déjà fiable avant de l’accepter n’importe où. Une date d’expiration plausible ne prouve pas la propriété. Mettez à jour la configuration gérée par le processus qui la possède, avec tout chevauchement planifié d’identités acceptables, et conservez la vérification de nom exigée par le déploiement. Un épinglage sans vérification de nom est une conception plus faible que la confiance CA qu’il a remplacée.

Vérifiez ensuite client par client : connectez-vous, confirmez l’identité qu’il a acceptée et notez la version de certificat à laquelle il fait désormais confiance. Un avertissement écarté une fois a tendance à revenir au prochain renouvellement.