AWS Client VPN : quel CA doit émettre les certificats clients ?

La question des certificats sur AWS Client VPN est posée comme une question produit, alors qu’il s’agit en réalité d’une question d’exploitation. Chacune des trois configurations habituelles maintiendra un tunnel fonctionnel : un CA d’organisation existant, un émetteur autonome dédié ou AWS Private CA. Elles diffèrent par qui approuve un appareil, qui détient la clé de signature et qui répond lorsqu’un ordinateur portable disparaît à une heure peu commode. Choisissez l’option dont vous pouvez nommer le responsable.

AWS n’exige pas Private CA pour l’authentification par certificat. Placer un certificat serveur dans ACM est une étape de déploiement, pas un processus d’enrôlement.

Les trois conditions qui tranchent

Trois conditions séparent clairement les options : l’existence d’un processus d’enrôlement des appareils déjà approuvé, votre capacité à exploiter une clé de signature avec des sauvegardes et un responsable nommé, et la manière dont une révocation atteint le point de terminaison. Chacune est proche d’un oui ou d’un non, et le premier non tranche généralement l’architecture.

Traitez-les dans l’ordre. Sauter directement à une comparaison de coûts, c’est ainsi que les équipes finissent avec un CA administré et personne qui sache qui émettra le prochain certificat d’ordinateur portable.

Première condition : l’enrôlement existe-t-il déjà ?

Si votre organisation exploite déjà un CA doté d’un parcours d’enrôlement des appareils approuvé, émettre depuis lui les certificats clients de Client VPN est la voie la plus courte. Les approbations, le processus et les registres d’actifs sont déjà là. Un émetteur subordonné dédié au sein de cette hiérarchie est généralement meilleur que le CA émetteur polyvalent, car il donne au VPN sa propre frontière de confiance et sa propre liste de révocation. Gardez cette liste séparée du reste de la hiérarchie afin qu’un incident VPN n’impose pas un changement à l’échelle du PKI.

Si un tel processus n’existe pas, la vraie question est de savoir si vous voulez en construire un. Un CA est facile à démarrer et coûteux à mal posséder.

Deuxième condition : pouvez-vous exploiter une clé de signature ?

Un émetteur autonome fonctionne avec le modèle d’importation documenté, et EasyRSA ou un petit outil interne peut produire le matériel. Exécuter la commande n’est pas la partie difficile. La partie difficile, ce sont les sauvegardes hors ligne de la clé de signature, un chemin de restauration que quelqu’un a réellement testé, un responsable qui n’est pas en congés, et une règle selon laquelle la clé ne finit jamais dans un paquet client ni dans un export de configuration. Écrivez cela comme une procédure avant l’émission du premier certificat, pas après le premier incident.

AWS Private CA transfère cette garde vers un service administré. Il ne transfère pas la politique d’enrôlement, l’étape d’approbation ni la livraison du certificat à l’appareil.

Troisième condition : comment la révocation arrive-t-elle ?

Client VPN consomme une liste de révocation de certificats clients que vous importez dans le point de terminaison, comme décrit dans le guide du cycle de vie des certificats. Publier une CRL ailleurs dans votre PKI ne la pousse pas dans le service. L’importation est une opération distincte et planifiée, et une liste expirée arrête les connexions au lieu de se dégrader silencieusement. Placez le renouvellement sur le même calendrier que les certificats eux-mêmes.

Cela fait du renouvellement un élément de supervision avec un responsable, et non une tâche terminée au lancement. Révoquez un certificat de test de bout en bout avant d’avoir réellement besoin du mécanisme.

Ce qu’aucune option n’élimine

Chaque option exige encore un certificat client et une clé distincts par appareil géré indépendamment. Un tutoriel qui distribue une seule identité à tout le monde est un raccourci de tutoriel, et il rend aussi la révocation sélective impossible.

Les certificats serveur importés dans ACM n’ont pas de renouvellement administré, le responsable doit donc obtenir le remplaçant, le réimporter, puis confirmer que le point de terminaison l’a adopté. Renouveler le certificat serveur ne renouvelle pas les identifiants clients déjà présents sur les ordinateurs portables. Ce sont des cycles de vie distincts avec des calendriers distincts.

Vérifiez les types de clés et les extensions que le service accepte avant d’émettre quoi que ce soit. Qu’un CA prenne en charge un algorithme ne signifie pas que le point de terminaison l’acceptera.

Avant le lancement, faites passer un renouvellement et un retrait de client par le flux de travail choisi, et notez quel identifiant a changé, quel réglage du point de terminaison a changé et ce qu’il est advenu de la session active. Si cet exercice se termine sans responsable clair, le choix de l’émetteur n’est pas terminé.