Votre certificat VPN expire aujourd’hui : ce qui s’arrête réellement

L’alerte d’expiration se déclenche, le tunnel transporte encore du trafic et personne ne s’accorde sur l’importance de la date. Elle compte, mais pas toujours à l’instant imprimé sur le certificat. Un certificat expiré arrête les nouvelles authentifications et il arrête les revalidations que certaines implémentations effectuent à l’intérieur d’une session longue. La mort de votre tunnel existant à minuit dépend du protocole, du client et des réglages de renégociation du serveur. Planifiez le renouvellement avant la date et vérifiez-le avec une nouvelle connexion plutôt qu’avec la session déjà ouverte.

Déterminez quel certificat expire réellement

Un déploiement contient un certificat feuille serveur, des identifiants client, un ou plusieurs intermédiaires et une ancre de confiance, et ils n’expirent pas ensemble. Lisez le certificat nommé dans l’erreur et la chaîne avec laquelle il a été présenté, pas le premier fichier du répertoire de profil. Une feuille serveur qui se renouvelle proprement peut encore échouer si l’intermédiaire au-dessus a expiré. Notez le sujet, l’émetteur, le not-after et l’emplacement de déploiement de chaque fichier avant de changer quoi que ce soit.

L’ancre de confiance est généralement l’objet le plus durable et la cause la moins probable.

Pourquoi une session active peut survivre à la date

L’authentification a lieu à l’établissement de la connexion, et certains protocoles revérifient l’identité plus tard. OpenVPN renégocie le canal de données selon un minuteur, donc une renégociation présentant un certificat expiré échoue même si le tunnel est actif depuis des heures. Les implémentations qui ne revalident jamais peuvent porter une session établie au-delà de la date d’expiration, et c’est pourquoi « ça marche encore » n’est pas une preuve. Aucun des deux comportements n’est quelque chose sur quoi planifier.

Traitez la date comme l’échéance des nouvelles connexions et la durée de vie de la session comme du temps emprunté.

Vérifiez l’horloge avant de blâmer le certificat

La validité est évaluée par rapport à l’horloge locale, donc un appareil dont l’heure est fausse signale un échec de validité pour un certificat parfaitement à jour. Vérifiez le client, le serveur et tout équipement sur le chemin.

Une horloge qui se réinitialise au démarrage explique les échecs qui n’apparaissent qu’après une coupure de courant.

Renouvelez par l’autorité qui l’a émis

Conservez l’identité, l’usage prévu et une configuration de clé compatible. Si le renouvellement introduit un nouvel émetteur ou un certificat épinglé, les clients ont besoin d’une mise à jour de confiance coordonnée plutôt que d’un remplacement de fichier sur le serveur. Protégez les clés privées pendant l’émission et la distribution, car un certificat renouvelé ne révoque pas une ancienne clé compromise. Une réinitialisation de mot de passe n’est pas un renouvellement, quoi qu’en dise le ticket.

Publiez la nouvelle chaîne entièrement, car une feuille sans son intermédiaire est un demi-renouvellement qui ne fonctionne que sur les machines qui l’ont déjà en cache.

Prouvez-le par une nouvelle connexion, gardez un retour arrière

Après le déploiement, établissez une nouvelle connexion autorisée depuis un client représentatif et exercez l’application réelle. Vérifiez que la chaîne est livrée comme les clients l’attendent et que toute information de révocation est joignable. Gardez un retour arrière qui ne dépend pas de faire confiance à du matériel expiré, afin de revenir à l’état précédent sans affaiblir la vérification. Ne supprimez les fichiers obsolètes qu’après vérification du remplacement.

Les sessions existantes peuvent encore refléter un état antérieur, elles ne prouvent donc rien dans un sens ni dans l’autre.

L’ordre que j’utilise le jour même

Confirmez l’objet qui expire et sa chaîne, puis confirmez les horloges :

• Quel certificat expire, et à quelle chaîne il appartient.
• Si chaque intermédiaire est déployé et publié.
• Les horloges du client et du serveur concordent dans une marge raisonnable.
• Une nouvelle connexion réussit depuis un client représentatif.
• L’information de révocation est joignable.
• Il existe un retour arrière qui n’affaiblit pas la vérification.

Renouvelez ensuite, déployez la chaîne complète, testez avec une nouvelle connexion et ne nettoyez qu’après. Les périodes de validité et les règles pour les évaluer sont définies dans RFC 5280, et la date n’est pas une surprise si votre supervision surveillait l’objet qui expire réellement.