Ce qui se passe quand vous remplacez une autorité de certification VPN

Remplacer une autorité de certification VPN n'est pas un échange de fichier. À l'instant où la nouvelle AC signe son premier certificat, chaque validateur qui ne fait encore confiance qu'à l'ancienne doit prendre une décision, et les hôtes qui ne reçoivent jamais la nouvelle ancre continuent de rejeter de bons pairs. Je l'ai vu échouer dans les deux sens : la passerelle a appris la nouvelle AC et pas les clients, si bien que les nouvelles connexions échouaient, tandis que les tunnels déjà montés restaient debout et faisaient passer la panne pour un problème de routage. Voici ce qui change, dans l'ordre où les défaillances apparaissent.

Un remplacement, deux changements distincts

Une autorité de certification est un nom, une clé publique et la clé privée qui signe. Les validateurs ne font jamais confiance à « l'AC » dans l'abstrait. Ils font confiance à un certificat précis qui se trouve déjà dans un magasin de confiance, et ils n'acceptent un émetteur que si une chaîne de signatures remonte jusqu'à cette copie stockée. Remplacer l'AC change donc deux choses qui échouent indépendamment : quelles ancres sont acceptées et quelles identités de pairs ont été émises sous elles.

La plupart des déploiements VPN valident dans les deux sens. Le client authentifie le certificat de la passerelle, et la passerelle celui du client. Une rotation qui ne rafraîchit que le paquet client laisse le serveur rejeter tout client qui présente encore une identité de l'ancienne AC, et l'inverse est tout aussi courant. Inventoriez d'abord les points d'application : magasins de confiance des clients, fichier ca de la passerelle, tout proxy terminant TLS devant elle et la sonde qui vérifie le point de terminaison depuis l'extérieur.

Ce qu'un validateur vérifie, dans l'ordre

La validation de chemin remonte du certificat du pair à travers les intermédiaires jusqu'à atteindre une ancre de confiance. À chaque étape elle vérifie la signature, s'assure que chaque certificat est dans sa fenêtre de validité et confirme que les contraintes de base et l'usage de la clé autorisent l'émetteur à signer. C'est seulement ensuite que l'application regarde le certificat feuille : les noms alternatifs du sujet doivent couvrir le nom composé, et l'usage étendu de la clé doit permettre l'authentification serveur ou client.

Pour rejouer ce parcours hors ligne, pointez -CAfile vers le paquet exact que vous allez déployer, pas vers le magasin du système. Sinon vous testez l'hôte, pas le changement :

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Cette commande ne fonctionne que contre un écouteur TLS simple, comme la page d'administration HTTPS de la passerelle ; le canal de contrôle d'OpenVPN précède TLS, donc s_client ne peut pas inspecter la poignée de main du tunnel.

Les règles de construction de chemin derrière ces erreurs se trouvent dans RFC 5280 section 6. Elles expliquent les défaillances qui semblent autrement arbitraires : un intermédiaire expiré dont personne ne se souvenait, un certificat dont l'usage de clé interdit la signature, ou une contrainte de nom qui exclut l'hôte que vous testez.

Pourquoi l'ancien tunnel continue de fonctionner

TLS et OpenVPN maintiennent tous deux une session établie en vie une fois la poignée de main terminée. Rien ne revalide le certificat du pair à chaque paquet, donc un client connecté avant le changement continue de faire passer du trafic jusqu'à ce qu'il renégocie, se reconnecte ou que le tunnel tombe. C'est ce décalage qui fait qu'un remplacement d'AC peut sembler correct pendant une heure puis échouer au pire moment : un portable sort de veille, une correspondance NAT expire, une passerelle redémarre.

La reprise de session étire encore l'illusion. Un ticket de session TLS permet au client de revenir sans renvoyer de certificats, et la reprise saute la validation de chemin parce que la première poignée de main l'a déjà faite. Le test honnête est donc une poignée de main complète dans un processus neuf. Redémarrez le client plutôt que de reconnecter le tunnel, et sur un profil de test, envisagez de désactiver les tickets pour que le chemin de reprise ne puisse pas masquer une chaîne cassée.

Gardez la couche de clé statique séparée de tout cela. tls-auth ajoute un HMAC au canal de contrôle, tls-crypt le chiffre et l'authentifie, et aucun des deux ne transporte de matériel de certificat, donc faire tourner l'un ou l'autre est un changement distinct avec son propre mode de défaillance. Les déploiements qui confondent les deux finissent avec un client dont la clé statique est bonne, dont le certificat est périmé et dont le message d'erreur ne mentionne ni l'un ni l'autre.

Le piège de la réutilisation du nom de sujet

Il est tentant de réutiliser le nom distinctif du prédécesseur pour que rien en aval n'ait à changer. Cela garde la ligne de l'émetteur stable dans l'interface et détruit le seul signal dont vous avez besoin. Deux certificats avec des sujets identiques et des clés différentes ne peuvent pas être distingués par le nom, donc un paquet contenant les deux ancres donne au validateur deux candidats et aucune règle de choix.

La construction de chemin peut alors choisir le mauvais, signaler « impossible d'obtenir le certificat de l'émetteur local » alors que la bonne ancre est présente, ou réussir sur un hôte et échouer sur un autre portant le même paquet, parce que l'ordre des candidats différait. Si le nom doit être réutilisé, gardez les deux ancres dans des fichiers séparés pendant la transition et chargez-les explicitement, puis fusionnez-les seulement quand chaque pair présente le nouvel émetteur. Sinon, donnez au remplacement un nom commun distinct — un suffixe de génération ou de date suffit — afin que les journaux et les messages d'erreur disent sous quelle autorité un pair défaillant a été émis.

Une rotation qui ne met pas le réseau à terre

Pour un remplacement planifié, acceptez les deux ancres pendant une fenêtre bornée au lieu de basculer en une seule étape. Émettez la nouvelle AC et ses intermédiaires, placez la nouvelle ancre dans le paquet de chaque validateur à côté de l'ancienne, et ne commencez qu'ensuite à émettre des certificats de pairs à partir d'elle. Les pairs dotés d'anciennes identités valident contre l'ancienne ancre ; les nouveaux fonctionnent contre la nouvelle.

Fait dans cet ordre, chaque étape est réversible. La défaillance que vous évitez est le basculement simultané, où un client qui a raté la mise à jour du paquet rencontre une passerelle qui a déjà retiré l'ancienne ancre, la poignée de main meurt et aucun journal ne dit quel côté est périmé.

Retirez dans la direction opposée. Réémettez chaque identité qui doit survivre, confirmez que chacune présente la nouvelle chaîne, puis retirez l'ancienne ancre des paquets. Retirez la clé privée de l'ancienne AC du service, car un émetteur qui peut encore signer signifie que la rotation n'est pas terminée. Conservez les certificats et les registres d'émission pour l'audit. Un émetteur perdu se restaure vers la même confiance ; une exposition exige de nouvelles identités et aucun retour à l'ancienne ancre.

Vérifiez le résultat, pas la liste des fichiers

Un fichier de confiance dans le répertoire attendu prouve peu. L'application peut lire un autre chemin, un autre format ou une copie dans un paquet qu'une mise à niveau remplace. Vérifiez le comportement aux deux extrémités, pas l'existence d'un fichier.

Confirmez qu'une connexion neuve avec une nouvelle identité réussit, puis confirmez qu'une identité émise par l'AC retirée est refusée. Ce second test est celui que les gens sautent, et le seul qui montre que l'ancienne autorité n'accorde plus l'accès. Là où le déploiement repose sur des CRL ou OCSP, vérifiez que les points de distribution des nouveaux certificats se résolvent et que les pairs qui l'interrogent atteignent le répondeur.

Terminez avec un client qui ne s'est jamais connecté : effacez l'état de son profil, connectez-le et lisez la chaîne négociée. Un pair qui reprend une session en cache rapportera allègrement que la migration a réussi alors qu'il n'a rien validé du tout.