Renouveler un certificat VPN sans changer son identité

Un renouvellement de certificat qui change l’identité n’est pas un renouvellement, c’est une migration déguisée en ticket de maintenance. Le client vérifie un nom, une chaîne et parfois une clé précise, et ces trois éléments peuvent changer sans que la date d’expiration change. Avant de demander un remplacement, notez ce que le client vérifie réellement : le nom d’hôte ou l’identité du pair, l’usage du certificat, la politique de clés et la chaîne émettrice. Le renouvellement est de routine ou coordonné selon ce que le remplacement modifie parmi ces éléments.

Trois conditions décident de la forme du renouvellement

Les trois conditions sont : quelque chose épingle-t-il le certificat feuille, la chaîne change-t-elle, et qui d’autre valide le nom. Répondez du point de vue du client plutôt que de la commodité de l’AC, car c’est le client qui tombe en panne à trois heures du matin.

Commencez par inspecter le certificat que vous avez. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName affiche le sujet, l’émetteur, la fenêtre de validité et les noms pour lesquels le certificat est réellement valide. Ce dernier champ est le plus important et le plus souvent supposé : une demande de renouvellement qui omet un SAN sur lequel le client s’appuie produit un certificat techniquement valide et fonctionnellement faux. Copiez la liste des SAN de l’ancien certificat dans la demande au lieu de la retaper de mémoire.

Condition un : quelque chose épingle-t-il le certificat feuille

Si les clients font confiance à une AC maintenue et valident le nom, un renouvellement du certificat feuille avec une nouvelle clé leur est invisible. Si un client épingle le certificat feuille, son empreinte ou sa clé publique, le remplacement est un changement coordonné avec une bascule ferme, car l’épinglage ancien ne peut pas valider le nouveau certificat.

Déterminez dans quel cas vous êtes avant de commander quoi que ce soit. Un épinglage que personne n’a documenté reste un épinglage lorsqu’il casse.

Condition deux : comparez les épinglages et la chaîne

Les empreintes rendent l’épinglage vérifiable : openssl x509 -noout -fingerprint -sha256 -in server.crt sur l’ancien et le nouveau certificat, et openssl x509 -noout -pubkey pour comparer les clés publiques. Si la configuration du client, un profil mobile ou un magasin de confiance d’appliance contient l’une de ces deux valeurs, vous avez un épinglage. Les profils VPN mobiles sont une cachette courante, car le profil est distribué une fois et n’est plus jamais inspecté.

Si le remplacement provient de la même autorité intermédiaire et que le client la possède déjà ou peut la récupérer, rien ne change côté confiance. Une nouvelle autorité intermédiaire, un émetteur différent ou une chaîne livrée dans le mauvais ordre transforment tous un renouvellement en changement de confiance, et la panne ressemble à un émetteur inconnu plutôt qu’à un certificat expiré.

Vérifiez la chaîne que le serveur envoie réellement avec openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, et validez-la localement avec openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Le faire avant le changement vous donne une référence pour comparer ensuite.

Condition trois : qui d’autre valide le nom

Un concentrateur VPN, un répartiteur de charge, une sonde de supervision, une intégration RADIUS ou SAML et un profil mobile peuvent chacun détenir leur propre copie du nom attendu ou de l’ancre de confiance. Le renouvellement est le moment où ces copies divergent, car le certificat change et les copies non.

Listez chaque consommateur avant le changement et décidez, pour chacun, s’il a besoin d’une mise à jour. Celui que vous oubliez est celui qui vous appelle.

Il y a aussi un piège temporel. Inspectez le début de validité autant que l’expiration, car un certificat préparé pour une activation ultérieure est rejeté s’il est installé trop tôt, et l’erreur ressemble à un problème d’horloge plutôt qu’à un problème de préparation. openssl x509 -noout -dates sur le nouveau fichier avant de le déployer est une vérification de deux secondes. Conservez aussi un chemin de récupération pris en charge et la configuration réputée bonne, afin qu’un renouvellement qui tourne mal soit réversible en restaurant le certificat et la clé précédents.

Déployez, vérifiez avec une authentification fraîche, puis retirez

Un tunnel établi reflète la validation effectuée lors de sa construction, il peut donc paraître sain alors que chaque nouvelle connexion échoue. Testez avec une authentification fraîche en utilisant le nom de service réel que les clients utilisent.

Effectuez le contrôle au niveau applicatif qui compte pour l’utilisateur, et confirmez la livraison de la chaîne du point de vue du client plutôt que du serveur. Ne supprimez pas les contrôles de nom ou de certificat pour garder la transition silencieuse ; cela transforme un problème de compatibilité temporaire en problème permanent.

Retirez le matériel obsolète seulement après vérification du déploiement, et traitez une clé compromise comme un cas entièrement différent : un renouvellement seul ne révoque rien, l’identité concernée a donc besoin du processus de révocation et de gestion de session du déploiement. RFC 5280 définit les règles de certificat et de validation de chemin qui sous-tendent tout cela. Gardez un renouvellement de routine du certificat feuille séparé d’un remplacement d’AC, afin qu’on ne demande pas aux clients de faire confiance à un nouvel émetteur sans raison.