Sur un logiciel métier de santé, les échanges avec les téléservices nationaux reposent sur des certificats clients : la vérification d’identité des patients (INSi), la messagerie sécurisée (MSSanté) et la connexion des professionnels. L’autorité de certification de la santé les émet pour trois ans, une durée assez longue pour que la personne qui a fait le dernier renouvellement ait tout oublié, et assez courte pour que l’échéance tombe pendant la vie du produit.
Une procédure rare est toujours exécutée pour la première fois
Renouveler un de ces certificats demande une carte professionnelle dans un lecteur, un portail, une clé privée à générer, un format à respecter, un emplacement où ranger le résultat, puis un déploiement. Chaque étape est simple, mais leur enchaînement tous les trois ans, sous la pression d’une échéance, est le genre de travail où l’on se trompe.
Le téléservice d’identité en fournit un bon exemple. Il refuse tout certificat qui ne porte pas un nom précis, et rien ne le signale au moment de la demande : on l’apprend quand les appels échouent en production. Ce genre de règle vit dans la tête de la personne qui l’a subie, jusqu’au jour où elle l’a oubliée.
J’ai donc remplacé la procédure par une commande par certificat. Elle génère la clé, demande le renouvellement avec la carte du responsable technique, récupère le certificat et vérifie qu’il correspond à la clé, à la bonne structure et à la bonne autorité. Elle refuse un nom qui ne serait pas celui attendu, puis écrit le résultat dans les secrets chiffrés de l’application. Si elle échoue à mi-chemin, on la relance et elle reprend là où elle s’était arrêtée. L’ancien certificat reste valide et conservé, et une seconde commande le remet en place si le nouveau pose problème.
Un test qui ne peut pas échouer ne prouve rien
Écrire le certificat au bon endroit ne dit pas qu’il sera accepté. Avant de déployer, une commande de contrôle envoie au vrai téléservice d’identité une recherche sur un patient fictif. La réponse « aucune identité trouvée » est celle qu’on attend, parce qu’elle prouve que le serveur a accepté le certificat et traité la demande, alors qu’un certificat refusé est coupé dès la négociation TLS.
Pour la messagerie, le même test a réussi avec un certificat auto-signé. Une connexion réussie ne permettait donc pas de vérifier l’émetteur. La commande se limite à des vérifications locales (clé, chaîne de certification) et l’affiche clairement. Un contrôle qui passe dans tous les cas est pire que pas de contrôle, parce qu’il rassure.
Savoir que ça casse avant les utilisateurs
Une alerte quotidienne signalait déjà les certificats à trente puis à sept jours de leur expiration. Il manquait le cas du certificat encore valide mais refusé par le serveur : le background job qui relève les messages l’écrivait dans ses logs après ses tentatives, et personne ne lit les logs d’un job qui tourne en fond. L’échec remonte désormais comme une erreur, et l’alerte d’expiration donne la commande à lancer au lieu de renvoyer vers une documentation.
Reste un point de gouvernance. Une partie de ces certificats avait été émise au nom de l’entreprise qui développe le logiciel, et non de la structure qui l’exploite. Le renouvellement a servi à les rattacher à leur vrai propriétaire, pour que le logiciel continue de fonctionner le jour où quelqu’un d’autre le maintient.
Les deux questions à poser
Toute échéance pluriannuelle (certificats, noms de domaine, clés d’API, habilitations) est une panne dont on connaît la date à l’avance. Pour chacune, il suffit de savoir qui peut la renouveler sans chercher, et comment on vérifie que le renouvellement a marché avant qu’un utilisateur ne le découvre.