Pourquoi réimporter un certificat Client VPN exige un nouveau point de terminaison

Une connexion Client VPN se coupe, le certificat dans ACM est remplacé, et rien ne change. L’objet certificat n’a jamais été ce que le point de terminaison utilisait. À sa création, un point de terminaison enregistre une association à un certificat, avec l’AC client par rapport à laquelle il validera, le type d’authentification, les sous-réseaux et les règles d’autorisation, et aucune de ces associations ne dispose d’un appel de modification qui accepte un certificat de remplacement. Remplacer les octets derrière un ARN est un changement du certificat, pas du point de terminaison qui l’a capturé.

Le point de terminaison stocke des références, pas des certificats

Le mécanisme mérite d’être énoncé précisément, car il explique toute la panne. create-client-vpn-endpoint prend un ARN de certificat serveur et un ARN de chaîne de certificats racine client, et le point de terminaison obtenu conserve ces références ainsi que les options d’authentification comme propriétés fixes. La surface de l’API n’offre aucune opération qui remplace le certificat serveur sur un point de terminaison existant.

Vous pouvez confirmer l’association sans deviner. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 affiche l’ARN du certificat, l’ARN de la chaîne racine client, le type d’authentification, le CIDR client et les sous-réseaux associés, soit l’ensemble complet des propriétés qu’il vous faudrait reproduire. Lancez-le avant et après une réimportation, et la sortie ne bouge pas. C’est la preuve que la réimportation n’allait jamais aider.

Pourquoi une réimportation ne peut pas atteindre le point de terminaison

Une réimportation écrit un nouveau corps de certificat sous un ARN existant. C’est une opération légitime lorsqu’un certificat approche de l’expiration, et ACM l’acceptera tant que la clé privée correspond et que la chaîne valide. Ce qu’elle ne fait pas, c’est relancer la validation du moment de création du point de terminaison, si bien que l’association et le matériel derrière restent tels qu’ils étaient lors de la construction du point de terminaison.

C’est aussi pour cela que le symptôme ressemble à une panne réseau. La poignée de main TLS échoue ou se réinitialise avant même que l’autorisation soit évaluée, donc les groupes de sécurité, les routes et les règles d’autorisation semblent tous innocents, et ils le sont.

La chaîne fait partie du certificat client

La seconde moitié de la panne est dans le certificat client, et elle est plus facile à écarter. Un certificat client doit être importé avec la chaîne qui l’a émis, même si le formulaire d’importation présente ce champ comme facultatif. Sans la chaîne, le point de terminaison ne peut pas construire de chemin du certificat client vers l’AC racine client avec laquelle il a été configuré, et la connexion se termine par une réinitialisation douce qui ressemble à un pare-feu qui jette des paquets. openssl verify -CAfile root-ca.pem client.crt répond à cette question localement en une seconde, et ce devrait être la première commande que vous lancez.

Réimporter avec la chaîne est une vraie correction pour cette moitié, et elle ne suffit toujours pas à elle seule. Une fois l’objet ACM modifié, le point de terminaison qui conserve l’ancienne association est la mauvaise chose sur laquelle continuer à tester. Les deux étapes relèvent de la même réparation, c’est pourquoi la correction en deux parties n’est pas une contradiction.

Recréer un point de terminaison est une migration

Créer un point de terminaison de remplacement est une migration, pas une nouvelle tentative, et la traiter comme une nouvelle tentative est la façon dont les équipes finissent avec deux points de terminaison à moitié configurés. Le nouveau point de terminaison obtient un nouvel ID et, sauf si vous l’avez planifié, un nouveau nom DNS pour chaque utilisateur. Gardez le profil client pointé vers un nom plutôt que vers une adresse, pour que le basculement devienne une modification d’enregistrement et non une redistribution.

L’ordre qui sécurise cela est court : créez le nouveau point de terminaison avec le même CIDR, les mêmes sous-réseaux et les mêmes règles d’autorisation, exportez un profil frais avec aws ec2 export-client-vpn-client-configuration, et vérifiez avec un utilisateur. C’est seulement ensuite que l’ancien point de terminaison est retiré.

La mise hors service de l’ancien point de terminaison a son propre ordre. Révoquez les certificats client que vous vouliez retirer avant de le supprimer, car un nouveau point de terminaison qui fait encore confiance à l’ancienne AC continue d’accepter des certificats que vous croyiez disparus. Supprimez ensuite l’ancien point de terminaison et retirez ses règles d’autorisation, pour qu’un profil périmé ne puisse pas se reconnecter à un réseau cible que vous croyiez fermé. Inscrivez l’ID de l’ancien point de terminaison et les identifiants d’association dans le registre des changements, car une migration comparée à la mémoire est la façon dont un point de terminaison qui fonctionne est reconstruit deux fois.

Ordonnez le diagnostic

Séparez trois pannes avant de changer toute configuration. Le client ne peut pas terminer TLS, le client termine TLS et n’est pas autorisé, ou le client se connecte et n’atteint pas une destination. L’association de certificat relève de la première, une règle d’autorisation qui ne couvre pas l’adresse du client relève de la seconde, et une route ou un groupe de sécurité relève de la troisième, où recréer un point de terminaison est presque toujours le mauvais geste.

Un point de terminaison qui a fonctionné pendant des mois puis s’est arrêté, sans changement de certificat ni de politique, est un cas à part. Le reconstruire avec des réglages identiques peut rétablir le service, mais c’est une raison de garder la configuration reproductible, pas une raison de reconstruire à chaque incident.

Gardez quatre choses sous contrôle de version pour que la prochaine reconstruction soit un diff et non une improvisation : les paramètres du point de terminaison, les ARN du certificat et de la chaîne, les règles d’autorisation et le CIDR client. La documentation d’authentification Client VPN indique quel certificat joue quel rôle, ce qu’il vaut la peine de vérifier avant même de supposer qu’un certificat est le problème. Si une réimportation ne change rien et que le point de terminaison se réinitialise encore, l’association est la suspecte et la réponse est un nouveau point de terminaison construit à partir des paramètres enregistrés. Si le point de terminaison reprend bien le nouvel objet, l’association était déjà correcte et la panne se situe dans la chaîne client ou la couche d’autorisation.