Depuis le 15 mars 2026, un certificat SSL/TLS de confiance publique ne peut être valide que 200 jours au maximum. La limite passe à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029. Si vous renouvelez aujourd’hui un certificat à la main, vous devrez le faire au moins huit fois par an d’ici 2029. La réponse : automatiser le renouvellement dès maintenant, et surveiller que cette automatisation continue de fonctionner.
Ce calendrier vient du CA/Browser Forum, le groupe d’autorités de certification et d’éditeurs de navigateurs qui rédige les règles que suit chaque certificat public. Ce guide explique le calendrier, le changement moins commenté concernant la validation de domaine, et ce qu’il faut faire avant chaque échéance.
Le calendrier
Le ballot SC-081v3, adopté en avril 2025, a modifié les Baseline Requirements du Forum en trois étapes. Deux limites baissent en même temps : la durée de validité d’un certificat, et la durée pendant laquelle une autorité de certification peut réutiliser une vérification antérieure prouvant que vous contrôlez le domaine.
Certificat émisValidité maximaleValidation de domaine réutilisable jusqu’àAvant le 15 mars 2026398 jours398 joursÀ partir du 15 mars 2026200 jours200 joursÀ partir du 15 mars 2027100 jours100 joursÀ partir du 15 mars 202947 jours10 jours
La page du ballot présente le vote et le texte intégral. Les limites s’appliquent au moment de l’émission. Un certificat émis avant une échéance reste valide jusqu’à sa propre date d’expiration : rien de ce que vous avez aujourd’hui ne cessera de fonctionner le 15 mars. Il ne pourra simplement pas être remplacé par un certificat d’aussi longue durée.
Ce que signifie la réutilisation de la validation de domaine
Avant d’émettre un certificat, une autorité de certification vérifie que vous contrôlez le domaine, par exemple en vous demandant de publier un enregistrement DNS ou de servir un fichier en HTTP. Jusqu’à présent, elle pouvait réutiliser cette vérification pendant plus d’un an. À partir de mars 2029, la période de réutilisation est de 10 jours : presque chaque renouvellement nécessitera donc une nouvelle vérification. Un renouvellement qui s’appuyait sur une validation mémorisée dépendra désormais de la bonne réponse de votre DNS et de votre serveur web, à chaque fois.
Pourquoi les durées de vie raccourcissent
Les informations d’un certificat vieillissent. Les domaines sont vendus, les entreprises changent d’hébergeur, les clés fuitent. Une durée de vie plus courte limite le temps pendant lequel un certificat obsolète ou compromis peut être utilisé.
La révocation n’est pas fiable. Les navigateurs ne peuvent pas toujours vérifier si un certificat a été révoqué. L’expiration est le filet de sécurité qui fonctionne toujours, et plus elle est courte, plus elle agit tôt.
Elle impose l’automatisation. Le renouvellement manuel annuel est précisément le processus qui échoue : la personne qui s’en chargeait est partie, le rappel est arrivé dans une ancienne boîte mail. Quand le renouvellement est fréquent, il doit être automatisé, et un processus automatisé peut changer rapidement d’algorithme ou d’autorité quand il le faut.
Let’s Encrypt va plus loin
Les certificats Let’s Encrypt durent déjà 90 jours, bien en deçà de toutes les limites ci-dessus. Dans Decreasing Certificate Lifetimes to 45 Days, Let’s Encrypt a annoncé son propre calendrier :
13 mai 2026 : le profil optionnel tlsserver émet des certificats de 45 jours.
10 février 2027 : le profil par défaut classic passe à des certificats de 64 jours, et les validations sont réutilisées pendant 10 jours au lieu de 30.
16 février 2028 : le profil par défaut passe à des certificats de 45 jours, avec des validations réutilisées pendant seulement 7 heures.
Let’s Encrypt a aussi cessé d’envoyer ses e-mails d’avertissement d’expiration en 2025. Si vous comptiez sur eux pour repérer un renouvellement raté, rien ne les remplace tant que vous ne mettez rien en place.
Une checklist pour vous préparer
1. Recensez tous vos certificats
Le site web est le plus simple. Listez aussi les endpoints d’API, les interfaces d’administration, les sites de staging, les serveurs de messagerie, les load balancers, les certificats en périphérie du CDN et les anciens sous-domaines de campagne. Les journaux Certificate Transparency enregistrent chaque certificat public : y rechercher votre domaine (par exemple sur crt.sh) fait apparaître des certificats que personne ne se souvient d’avoir commandés. Le vérificateur SSL affiche la date d’expiration, l’émetteur, les noms et la chaîne de n’importe quel hôte.
2. Automatisez le renouvellement avec ACME
ACME est le protocole standard pour demander et renouveler des certificats sans intervention humaine (RFC 8555). Certbot, acme.sh et Caddy le prennent en charge, tout comme la plupart des panneaux d’hébergement, load balancers et CDN. De nombreuses autorités commerciales le prennent aussi en charge : les certificats payants peuvent donc également être automatisés. Renouvelez bien avant l’expiration, quand il reste environ un tiers de la durée de vie, pour qu’une tentative ratée ait le temps d’être relancée.
3. Faites en sorte que la validation réussisse à chaque fois
Avec une période de réutilisation de 10 jours, chaque renouvellement exige une validation réussie. Vérifiez la méthode que vous utilisez :
La validation HTTP exige que le port 80 soit ouvert et que /.well-known/acme-challenge/ soit accessible, sans redirection vers une page de connexion ni règle de pare-feu qui bloque.
La validation DNS exige un accès API à votre fournisseur DNS, avec des identifiants qui n’expirent pas en silence.
Les enregistrements CAA, si vous en publiez, doivent mentionner l’autorité que vous utilisez. Un enregistrement CAA hérité d’un ancien fournisseur bloque l’émission. Consultez-les avec l’outil de recherche DNS.
Un enregistrement DNS modifié est l’une des raisons les plus fréquentes pour lesquelles un renouvellement qui fonctionnait depuis des années échoue soudain. La surveillance DNS vous prévient quand un enregistrement change.
4. Déployez ce que vous renouvelez
Un certificat renouvelé sur le disque ne sert à rien tant que le serveur ne l’a pas chargé. Assurez-vous que votre client recharge le serveur web après le renouvellement, et que chaque serveur derrière un load balancer reçoit le nouveau certificat, pas seulement celui où le renouvellement s’est exécuté. Les appliances et services qui exigent un téléversement manuel du certificat sont ceux où les durées plus courtes font le plus mal ; vérifiez dès maintenant s’ils peuvent en récupérer un automatiquement.
5. Repensez les certificats achetés manuellement
Un certificat vendu comme un produit d’un an ne peut plus être émis pour un an. Depuis mars 2026, il doit être réémis au moins une fois pendant la durée du contrat, et à partir de 2029 environ toutes les six semaines. Si un certificat à validation d’organisation (OV) est une exigence, demandez à votre autorité comment elle prend en charge ACME avant le passage à 100 jours en 2027.
6. Surveillez le certificat réellement servi
L’automatisation échoue en silence : un jeton d’API DNS expiré, un déménagement de serveur qui a oublié le timer de renouvellement, un rechargement qui n’a jamais eu lieu. Le seul test fiable consiste à examiner, depuis l’extérieur et à intervalles réguliers, le certificat que reçoivent les visiteurs. Notre guide sur la surveillance de l’expiration des certificats SSL entre dans le détail, et les erreurs de certificat SSL expliquées montre ce que voient les visiteurs quand ça tourne mal.
Ce que chaque échéance change en pratique
Aujourd’hui, à 200 jours : chaque certificat est remplacé au moins deux fois par an. Un processus manuel fonctionne encore, mais c’est le moment de faire l’inventaire et d’automatiser, tant qu’un renouvellement oublié reste rare.
À partir du 15 mars 2027, à 100 jours : au moins quatre remplacements par an. Un certificat téléversé à la main sur une appliance ou un panneau d’hébergement devient une corvée trimestrielle que quelqu’un finira par oublier.
À partir du 15 mars 2029, à 47 jours : au moins huit remplacements par an, chacun avec une nouvelle validation de domaine. Tout ce qui est manuel finira par échouer, tout comme l’automatisation dont personne n’a testé les identifiants DNS, les règles de pare-feu ou l’étape de rechargement.
Le travail est le même à chaque étape : moins de certificats manuels, un renouvellement qui valide et déploie tout seul, et une vérification externe qui vous prévient quand ce n’est pas le cas.
Comment Uptimecheck surveille vos certificats
Chaque moniteur HTTPS d’Uptimecheck lit le certificat à chaque vérification : il n’y a donc pas de moniteur SSL distinct à configurer.
Des rappels sont envoyés sur les canaux d’alerte du moniteur 30, 14, 7 et 1 jour avant l’expiration du certificat, ainsi que le jour même.
Les jours restants passent à l’orange sous 30 jours et au rouge sous 14, et les certificats qui expirent dans les 14 jours apparaissent sous Needs attention dans la vue d’ensemble.
Un certificat expiré, auto-signé ou ne correspondant pas au domaine fait échouer la vérification et ouvre donc un incident comme n’importe quelle panne. Un certificat intermédiaire manquant apparaît comme Incomplete chain.
Alignez les rappels sur le rythme de vos renouvellements. Si votre client renouvelle alors qu’il reste plus de 30 jours, tout rappel signifie qu’un renouvellement a échoué. S’il renouvelle plus tard, comme ce sera le cas avec des certificats de 47 jours, le rappel à 30 jours arrive avant chaque renouvellement, et c’est le premier rappel après le point de renouvellement de votre client qui demande une action. Voir comment surveiller l’expiration des certificats SSL.
L’enregistrement du nom de domaine a sa propre date d’expiration, et aucun certificat ne vous sauvera une fois qu’il a expiré. La surveillance des domaines vous le rappelle aux mêmes échéances ; vérifiez n’importe quel domaine avec le vérificateur d’expiration de domaine.
Des certificats plus courts ne doivent pas signifier plus de pannes. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.