Gestion des certificats SSL/TLS
Les certificats SSL/TLS font partie de ces éléments qui fonctionnent parfaitement jusqu’à ce que, sans avertissement pour la plupart des entreprises, ils cessent de fonctionner. Un certificat expire discrètement un dimanche, tous les navigateurs affichent un avertissement flagrant lorsque les utilisateurs accèdent à votre site, et les clients qui ne savent même pas ce que signifie une erreur TLS en déduisent simplement que vous avez été piraté. Il s’agit d’une interruption de service dont vous êtes vous-même responsable, et qui est tout à fait évitable — ce qui explique précisément pourquoi elle continue de se produire. La gestion des certificats ne se limite pas à l’envoi de rappels de renouvellement ; elle consiste à connaître chaque certificat de tous les domaines, sous-domaines, API et services internes que vous exploitez, à les maintenir à jour et à vous assurer que la configuration sous-jacente — versions de protocole, suites de chiffrement, chaîne de confiance — est réellement solide, et pas seulement présente.
Où cela pose-t-il problème dans la pratique ?
Les certificats se multiplient en silence. Une entreprise qui pense n’avoir qu’une poignée de certificats à suivre découvre souvent qu’il en existe des dizaines dès que l’on dresse un inventaire des services internes, des sous-domaines hérités et des intégrations tierces. La responsabilité est fragmentée entre les différentes équipes, les rappels de renouvellement atterrissent dans une boîte de réception que plus personne ne consulte, et l’automatisation mise en place il y a des années cesse discrètement de fonctionner à la suite d’un changement d’infrastructure dont personne n’a tenu compte.
Comment j’aborderais la question
Je commencerais par dresser un inventaire complet — tous les certificats utilisés où que ce soit dans votre environnement, et pas seulement ceux des domaines accessibles au public dont les gens se souviennent. À partir de là, je mettrais en place une surveillance et un renouvellement automatisés partout où cela est possible, car l’objectif est qu’un être humain ne découvre plus jamais un certificat expiré à la suite d’un e-mail de client mécontent. Je passerais également en revue la configuration réelle derrière chaque certificat — protocoles faibles, chaînes mal configurées, certificats délivrés avec une portée plus large que nécessaire — car un certificat à jour mais mal configuré reste un risque réel, bien que plus discret. Pour tout ce qui ne peut pas être automatisé, je mettrais en place un processus avec une responsabilité clairement définie, afin que le renouvellement ne dépende pas de la mémoire d’une seule personne.
Si vous avez déjà découvert qu’un certificat avait expiré par le biais d’un client plutôt que via un tableau de bord, ou si vous n’êtes pas tout à fait sûr du nombre exact de certificats que vous utilisez actuellement, contactez-nous et nous vous aiderons à maîtriser la situation.