Un certificat TLS expiré ou révoqué coupe l’accès à votre site, à votre messagerie ou à votre VPN, souvent sans alerte préalable. La parade tient en deux chantiers : savoir où se trouvent tous vos certificats, puis automatiser leur renouvellement avant que la durée de vie maximale ne tombe à 47 jours.
L’actualité le rappelle : le 21 octobre, GoDaddy a révoqué 404 607 certificats après une erreur de conformité dans ses documents de politique de certification. Quelques jours plus tôt, l’autorité indienne eMudhra annonçait quitter le marché des certificats TLS après un incident de sécurité. Dans les deux cas, les entreprises clientes n’avaient rien fait de mal, mais celles qui renouvelaient leurs certificats à la main ont dû agir dans l’urgence.
Pourquoi la gestion des certificats TLS devient un sujet de direction
Pendant des années, un certificat se renouvelait une fois par an, souvent par la personne qui l’avait commandé. Ce modèle est en train de disparaître. Le CA/Browser Forum, qui fixe les règles suivies par les navigateurs, a adopté le ballot SC-081 : la durée de validité maximale passe de 398 jours à 200 jours depuis mars 2026, puis à 100 jours en mars 2027 et à 47 jours en mars 2029.
Concrètement, un certificat qui demandait une intervention par an en demandera huit à partir de 2029. Ajoutez le risque de révocation imposée par l’autorité, que les règles du CA/Browser Forum fixent à cinq jours maximum, et le renouvellement manuel devient une source de pannes plutôt qu’une simple tâche administrative. Pour une PME, la conséquence est très concrète : un site e-commerce inaccessible, un portail client affichant une alerte de sécurité, des collaborateurs bloqués à la connexion VPN.
Étape 1 : inventorier vos certificats exposés sur Internet
Commencez par ce que vos clients et vos partenaires voient. Les journaux de transparence des certificats (Certificate Transparency) enregistrent publiquement chaque certificat émis par une autorité reconnue. Une recherche sur crt.sh avec votre nom de domaine liste tous les certificats émis pour vos sous-domaines, y compris ceux dont vous aviez oublié l’existence.
Notez pour chaque entrée le sous-domaine, l’autorité émettrice et la date d’expiration. Vous découvrirez presque toujours des surprises : un ancien extranet, un environnement de test, un outil SaaS configuré sur votre domaine par un prestataire. Ce travail rejoint celui d’un scan de votre surface d’attaque externe, que vous pouvez mener en parallèle.
Étape 2 : recenser les certificats internes et embarqués
Les certificats publics ne sont qu’une partie du parc. Listez aussi ceux qui protègent vos équipements et applications internes : pare-feu et passerelle VPN, serveur Exchange ou de messagerie, interfaces d’administration (hyperviseur, NAS, imprimantes), répartiteurs de charge, applications métier. Interrogez votre infogérant : il gère souvent une partie de ces certificats sans que l’information remonte.
Consignez le tout dans un tableau simple : équipement, usage, autorité, date d’expiration, responsable, mode de renouvellement (manuel ou automatique). Ce tableau devient votre référentiel. Sans lui, aucune des étapes suivantes n’est possible.
Étape 3 : identifier les certificats à risque immédiat
Triez votre inventaire selon trois critères. D’abord, les certificats qui expirent dans les 60 prochains jours. Ensuite, ceux émis par une autorité qui a récemment révoqué en masse ou quitté le marché : si vous êtes client GoDaddy, vérifiez dans votre tableau de bord que le certificat de remplacement est bien installé sur le serveur, car le télécharger ne suffit pas. Enfin, les certificats d’une durée supérieure à 200 jours encore en service : ils ne pourront pas être renouvelés à l’identique.
Pour vérifier ce qu’un serveur présente réellement, utilisez la commande openssl s_client -connect votre-domaine.fr:443 ou un service en ligne de test TLS. C’est le certificat servi qui compte, pas celui stocké dans votre espace client.
Étape 4 : automatiser le renouvellement avec ACME
Le protocole ACME permet à un serveur de demander, valider et installer seul un nouveau certificat. Let’s Encrypt l’a popularisé avec des certificats gratuits, et la plupart des autorités commerciales le proposent désormais. Sur un serveur web Linux, un client comme Certbot s’installe en quelques minutes et programme le renouvellement automatique.
Priorisez dans cet ordre : sites web publics, puis passerelles d’accès distant, puis interfaces internes. Pour les équipements qui ne gèrent pas ACME (certains pare-feu ou appliances anciennes), vérifiez si l’éditeur propose une mise à jour qui l’ajoute, ou placez un reverse proxy capable de renouveler automatiquement devant l’équipement.
Étape 5 : mettre en place une surveillance des expirations
L’automatisation peut échouer silencieusement : enregistrement DNS modifié, pare-feu qui bloque la validation, compte expiré chez l’autorité. Mettez en place une alerte indépendante qui vérifie chaque jour la date d’expiration des certificats servis et prévient au moins 21 jours avant l’échéance.
Des outils open source de supervision (Uptime Kuma, Zabbix, Prometheus avec un exporteur dédié) le font très bien. Adressez les alertes à une boîte partagée, jamais à une seule personne qui peut partir en congés ou quitter l’entreprise.
Étape 6 : préparer la procédure de révocation d’urgence
Une révocation imposée laisse quelques jours, parfois moins. Rédigez une fiche d’une page qui répond à quatre questions : qui reçoit les notifications de l’autorité, qui peut commander un nouveau certificat, où sont stockées les clés privées, et comment déployer en moins de 24 heures sur chaque équipement critique.
Profitez-en pour vérifier que les adresses de contact déclarées chez votre autorité de certification sont toujours actives. Dans l’incident GoDaddy, les clients ont été prévenus par courriel une semaine avant la révocation : un message envoyé à un ancien collaborateur, c’est une panne garantie. Les recommandations de l’ANSSI sur la sécurité de TLS détaillent également les bonnes pratiques de configuration à appliquer lors du remplacement.
Étape 7 : intégrer les certificats à votre surveillance de sécurité
Un certificat émis pour votre domaine sans que vous l’ayez demandé peut signaler une tentative d’hameçonnage ou un compte compromis chez votre registraire. Abonnez-vous aux alertes Certificate Transparency pour vos domaines principaux et faites remonter ces événements au même endroit que vos autres alertes de sécurité.
Ajoutez aussi un enregistrement DNS CAA qui indique quelles autorités ont le droit d’émettre des certificats pour votre domaine. C’est gratuit, cela prend cinq minutes et cela réduit le risque d’émission frauduleuse.
Un certificat émis à votre insu ou une panne d’accès distant sont des signaux qu’une surveillance continue repère avant vos clients : c’est le rôle de notre SOC managé 24/7 pour PME et ETI.
Si l’inventaire de l’étape 2 a révélé des équipements gérés par des tiers, la démarche rejoint celle de l’inventaire des SaaS et du shadow IT.
Ce qu’il faut retenir
- La durée de vie maximale des certificats TLS passe à 100 jours en mars 2027, puis à 47 jours en 2029.
- Une autorité peut révoquer vos certificats en cinq jours, même sans faute de votre part.
- L’inventaire, public et interne, est le préalable à toute automatisation.
- ACME et une alerte d’expiration indépendante éliminent l’essentiel des pannes.
- Un enregistrement CAA et les alertes Certificate Transparency limitent les émissions frauduleuses.