Expiration des certificats SSL/TLS : pourquoi elle met encore des sites hors ligne
Lorsqu'un certificat TLS expire, les navigateurs cessent de faire confiance à la connexion et affichent un avertissement plein écran à la place de votre site. Les API, applications mobiles et intégrations qui se connectent au même hôte échouent généralement purement et simplement, car leurs clients refusent un certificat expiré sans demander l'avis de personne. Le site lui-même peut fonctionner parfaitement, mais pour les visiteurs, il est hors ligne.
Le renouvellement est automatisé depuis des années, alors pourquoi cela arrive-t-il encore ? Parce que l'automatisation couvre les certificats que quelqu'un a pensé à automatiser. Les pannes liées à l'expiration viennent généralement des certificats oubliés : un sous-domaine créé pour une campagne, un répartiteur de charge avec un certificat téléversé à la main, un serveur de messagerie, ou une tâche de renouvellement qui échoue en silence depuis des semaines.
Les durées de validité des certificats raccourcissent aussi, ce qui signifie que chaque processus de renouvellement est sollicité plus souvent.
Les durées de validité se réduisent
Le CA/Browser Forum fixe les règles que suivent les autorités de certification reconnues par les navigateurs. En avril 2025, il a adopté le ballot SC-081v3, et les TLS Baseline Requirements actuelles (section 6.3.2) fixent ce calendrier pour la validité maximale d'un certificat :
- émis avant le 15 mars 2026 : 398 jours au maximum,
- émis à partir du 15 mars 2026 : 200 jours au maximum,
- émis à partir du 15 mars 2027 : 100 jours au maximum,
- émis à partir du 15 mars 2029 : 47 jours au maximum.
Concrètement, d'ici 2029, un certificat renouvelé manuellement devrait être remplacé environ toutes les 6 à 7 semaines. Tout certificat encore renouvelé à la main, à partir d'un rappel dans un agenda, devient un risque de panne récurrent.
Il ne faut pas non plus compter sur les rappels de l'autorité de certification. Let's Encrypt, par exemple, a mis fin à ses e-mails d'avertissement d'expiration le 4 juin 2025.
Pourquoi les renouvellements échouent
Les causes courantes sont banales :
- La validation échoue. La validation HTTP casse après une modification de redirection ou de pare-feu ; la validation DNS casse après un changement de fournisseur DNS ou l'expiration d'un jeton d'API.
- Le renouvellement réussit mais le service n'est pas rechargé, si bien que le serveur web continue de présenter l'ancien certificat.
- Les certificats ont été copiés à la main sur un répartiteur de charge, un CDN, un équipement ou un serveur de messagerie que l'automatisation n'atteint pas.
- Personne n'est responsable de l'hôte. Les serveurs de préproduction et les anciens sous-domaines marketing ont souvent des certificats mais aucun responsable. Voir serveurs de préproduction et de test oubliés.
- Le compte ou le paiement d'un certificat commercial n'a pas été renouvelé.
- La chaîne intermédiaire est incomplète, ce que certains clients refusent même avant l'expiration.
Comment vérifier vous-même l'expiration d'un certificat
Pour un hôte donné, openssl affiche les dates du certificat que le serveur présente réellement :
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer
Regardez notAfter. Vérifiez chaque nom séparément, y compris www, les hôtes d'API et de messagerie. Pour un serveur de messagerie utilisant STARTTLS :
echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate
Pour retrouver les hôtes que vous avez peut-être oubliés, recherchez %.example.com dans les journaux Certificate Transparency sur crt.sh. Chaque certificat émis pour votre domaine y figure, y compris ceux des sous-domaines dont plus personne ne se souvient. Notre article sur les journaux Certificate Transparency explique comment lire les résultats.
Comment éviter l'expiration des certificats
- Automatisez l'émission et le renouvellement avec ACME partout où c'est possible, et faites en sorte que la tâche de renouvellement recharge ensuite le service.
- Renouvelez bien avant l'expiration, suffisamment tôt pour avoir le temps de corriger une validation en échec.
- Alertez sur les échecs de renouvellement, pas seulement sur les réussites. Une tâche cron qui se termine en erreur sans prévenir personne est la cause classique.
- Tenez un inventaire de chaque hôte doté d'un certificat, construit à partir des résultats Certificate Transparency et non de mémoire.
- Surveillez depuis l'extérieur. Vérifiez le certificat que le serveur présente réellement, car c'est ce que voient les clients. Une note interne indiquant « renouvelé » n'est pas la même chose.
- Supprimez ce que vous n'utilisez plus. Un sous-domaine qui ne sert plus rien doit perdre son enregistrement DNS et son certificat.
Si un certificat a déjà expiré
- Renouvelez-le ou faites-le réémettre, déployez-le et rechargez le service.
- Confirmez avec
openssl s_clientdepuis l'extérieur de votre réseau que la nouvelle datenotAfterest bien présentée. - Vérifiez que la chaîne complète est servie, et pas seulement le certificat final.
- Vérifiez les clients dépendants : applications mobiles, intégrations de partenaires et webhooks peuvent nécessiter une nouvelle tentative.
- Cherchez pourquoi l'alerte ne s'est pas déclenchée et corrigez-le.
Liste de contrôle
- Inventaire de tous les hôtes dotés de certificats, y compris messagerie et API.
- Automatisation ACME avec rechargement du service.
- Alertes en cas d'échec de renouvellement.
- Vérification externe de l'expiration sur chaque hôte.
- Préparation aux durées de validité de 100 et 47 jours.
Les domaines expirent aussi, avec des conséquences très différentes. Voir ce qui se passe quand votre domaine expire.
Comment Datahorses vous aide
Datahorses surveille votre entreprise depuis l'extérieur et vérifie les certificats que vos serveurs présentent réellement, y compris l'expiration, les chaînes cassées et les certificats autosignés, avec des rappels 30, 14 et 3 jours avant l'expiration d'un certificat ou d'un domaine. Nous n'entrons pas dans vos systèmes et n'avons besoin d'aucun accès. Découvrez ce que nous surveillons et le tableau de bord d'exemple pour voir à quoi cela ressemble.
Plus d’articles
Les en-têtes de sécurité HTTP que tout site d'entreprise devrait envoyer
Quelques lignes dans la réponse de votre serveur imposent HTTPS, bloquent l'intégration dans des frames et limitent les scripts. Voici les en-têtes utiles et comment les vérifier.
Serveurs de préproduction et de test oubliés : la partie que personne ne surveille
Les serveurs de préproduction et de test sont conçus pour être temporaires, puis survivent discrètement au projet. Voici comment trouver les vôtres et décider quoi garder, protéger ou éteindre.
PHP2Shell : quelles versions de PHP sont corrigées et comment contrôler la vôtre
Le projet PHP a corrigé 2 failles critiques le 21 octobre 2026. Voici les versions qui contiennent le correctif, comment voir ce qu'annonce votre serveur et quoi demander à votre hébergeur.