Les nouvelles connexions VPN échouent alors que les certificats sont valides : vérifiez la CRL

Des certificats qui ont encore des mois devant eux et des connexions qui échouent immédiatement désignent deux objets différents avec deux horloges différentes. Le serveur rejette les connexions parce que la liste des certificats révoqués qu’il consulte a dépassé sa propre date d’expiration, et non parce que les certificats des utilisateurs sont devenus obsolètes. Renouveler un certificat utilisateur ne change rien pour cette liste.

Séparer les deux calendriers, c’est tout le diagnostic, et cela change la forme que doit prendre la correction.

Deux horloges, et une seule d’entre elles est le certificat

Un certificat porte une fenêtre de validité. Une liste de révocation de certificats porte sa propre fenêtre, ainsi qu’un émetteur et une signature, et les vérificateurs refusent de faire confiance à une liste dont l’heure de mise à jour suivante est passée. Quand cela se produit, le client présente un certificat parfaitement valide et le serveur coupe tout de même la connexion avec un message au sujet de la liste. Les utilisateurs lisent ce message comme « le certificat a expiré », ce qui envoie la demande de renouvellement au mauvais endroit.

Les deux objets ont aussi des propriétaires différents : le certificat vient de l’autorité qui l’a émis, tandis que la liste est générée selon un calendrier par celui qui exploite cette autorité. Un utilisateur ne peut pas la rafraîchir, et la réémission de certificats ne peut pas la prolonger.

Lisez la liste que le service charge réellement

Partez de la configuration en cours plutôt que du fichier que vous attendez. Le chemin de crl-verify peut être absolu, relatif au profil ou une copie intégrée à une image, et le vérificateur lit cette copie. Inspectez-la sur place avec openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate et comparez les dates à l’horloge du serveur.

Confirmez ensuite que le fichier est bien celui qui est utilisé : vérifiez sa signature avec openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, qui rapporte un résultat de vérification au lieu d’imprimer silencieusement des champs. Une liste signée par une autre autorité, ou une copie périmée laissée dans un second répertoire, échoue exactement comme une liste expirée.

Régénérez à partir de la base de révocation, pas à partir de zéro

La nouvelle liste doit venir de la base de révocation actuelle de l’autorité, via le processus de signature approuvé. Générer une liste vide, ou régénérer à partir d’une ancienne sauvegarde de l’index, annule silencieusement la révocation de chaque identité ajoutée depuis cette sauvegarde. Cela transforme une panne de connexion en régression de sécurité, et personne ne le remarque parce que le symptôme disparaît.

Gardez l’étape de génération sous contrôle de version avec le reste de l’outillage de l’autorité, afin que l’intervalle et la clé de signature soient documentés plutôt que mémorisés. Une entrée de runbook qui nomme la commande, le signataire et la cible de publication suffit. N’importe qui d’astreinte peut alors régénérer sans deviner quel fichier d’index fait autorité. Stockez le numéro de série et l’heure de mise à jour suivante de la liste avec l’enregistrement de déploiement.

Déployez là où le vérificateur regarde

Copiez la nouvelle liste vers le chemin que le service lit, définissez le propriétaire et le mode pour que le compte de service puisse la lire mais pas les autres, puis rechargez ou redémarrez selon le comportement documenté. Si le démon met la liste en cache au démarrage, remplacer le fichier sans recharger ne change rien que le processus en cours remarquera. Confirmez l’horodatage que le processus signale après le rechargement.

Si plusieurs services vérifient des clients, déployez sur chacun d’eux. Mettre à jour un point de terminaison et en laisser un autre avec l’ancienne copie produit une panne qui n’apparaît que pour les utilisateurs qui atterrissent sur le second. Gardez une courte liste de ces points de terminaison dans le même runbook. Après le déploiement, vérifiez la date de liste signalée par chacun plutôt que de supposer que la copie est arrivée.

Rendez la prochaine échéance visible avant qu’elle ne passe

Un intervalle de publication plus long réduit la fréquence de cet incident sans créer de processus. Choisissez l’intervalle selon la politique de l’exploitant, puis alertez sur le champ de mise à jour suivante de la liste déployée avec suffisamment de délai pour régénérer et déployer. Alertez sur la copie déployée, pas sur l’hôte de l’autorité, car c’est la copie déployée qui échoue.

Après le déploiement, vérifiez les deux sens : un utilisateur autorisé se connecte, et une identité révoquée connue échoue toujours. La seconde vérification est celle qui attrape une régénération incomplète, et elle ne demande qu’une commande contre un profil de test que vous gardez précisément pour cela.