Durée de validité des certificats SSL 2026–2029 : de 398 à 47 jours

En bref : depuis le 15 mars 2026, la durée de validité d'un certificat TLS/SSL public est limitée à 200 jours. Le 15 mars 2027, la limite passe à 100 jours, puis à 47 jours le 15 mars 2029. Ce calendrier vient du ballot SC-081v3 du CA/Browser Forum, adopté le 11 avril 2025, et s'impose à toutes les autorités de certification (AC, ou CA en anglais) publiques — payantes ou gratuites, pour les certificats DV, OV comme EV. Si une étape de votre renouvellement dépend d'une personne, d'un rappel dans un agenda ou d'un e-mail de votre AC, elle finira par échouer quelque part sur ce parcours.

Faits vérifiés le 14 octobre 2026 à partir du ballot du CA/Browser Forum, de la synthèse publiée par DigiCert et des annonces de Let's Encrypt. Les sources sont listées en fin d'article.

Le calendrier en un coup d'œil

La dernière colonne est un minimum théorique : elle suppose un renouvellement le dernier jour. Personne de raisonnable ne fait ça. Avec une marge de sécurité normale, l'étape des 47 jours revient à renouveler à peu près tous les mois, soit environ 12 renouvellements par certificat et par an.

Un autre changement est entré en vigueur le 15 mars 2026 : les informations sur l'organisation derrière les certificats OV et EV (les « subject identity information ») peuvent désormais être réutilisées pendant 398 jours, au lieu de 825.

Deux chiffres changent, et le second compte davantage

La validité maximale détermine la fréquence à laquelle vous installez un nouveau certificat. La durée de réutilisation de la validation de domaine détermine la fréquence à laquelle l'AC doit prouver à nouveau que vous contrôlez le domaine — via un enregistrement DNS, un fichier de challenge HTTP ou un e-mail.

Aujourd'hui, une validation réussie peut être réutilisée pendant des mois : une chaîne de validation fragile peut donc rester invisible longtemps. À partir de 2029, la fenêtre de réutilisation est de 10 jours, ce qui signifie qu'en pratique chaque renouvellement déclenche une nouvelle validation. Une étape qui tournait une fois par an, sous les yeux de quelqu'un, tournera tous les mois, sans surveillance. Si le jeton d'API DNS a expiré ou si une règle de pare-feu bloque le challenge, vous l'apprendrez en même temps que l'expiration du certificat.

Et Let's Encrypt ?

Les certificats Let's Encrypt durent déjà 90 jours, bien en deçà des nouvelles limites. Mais Let's Encrypt raccourcit aussi leur durée :

• 13 mai 2026 — le profil optionnel tlsserver a commencé à émettre des certificats de 45 jours.
• 10 février 2027 — le profil par défaut classic passe à des certificats de 64 jours, avec une durée de réutilisation des autorisations de 10 jours.
• 16 février 2028 — le profil classic passe à des certificats de 45 jours, avec une durée de réutilisation des autorisations de 7 heures.

Let's Encrypt recommande de laisser le client décider grâce à ACME Renewal Information (ARI), ou de renouveler à environ deux tiers de la durée de vie du certificat. L'AC dit clairement qu'un renouvellement à intervalle fixe de 60 jours, codé en dur, ne suffira plus. Si votre installation renouvelle selon un calendrier fixe plutôt qu'en fonction du temps restant, elle a elle-même une date d'expiration.

Il y a un second changement, plus discret. Le 4 juin 2025, Let's Encrypt a cessé d'envoyer les e-mails d'avertissement d'expiration. Le filet de sécurité sur lequel comptaient beaucoup d'équipes — « si le renouvellement échoue, Let's Encrypt m'enverra un e-mail » — n'existe plus.

Où les renouvellements échouent réellement

Un certificat expiré vient rarement d'une absence de tentative de renouvellement. Il vient d'un renouvellement qui n'a fonctionné qu'à moitié :

1. Renouvelé mais jamais déployé. Le nouveau certificat est sur le disque, mais le serveur web n'a jamais été rechargé : il continue de servir l'ancien jusqu'à son expiration.
2. Des copies ailleurs. Le certificat a été renouvelé sur le serveur d'origine, alors que le CDN, le répartiteur de charge, le serveur de messagerie ou la passerelle d'API conservent encore une copie téléversée.
3. Une validation qui n'a marché qu'une fois. Le jeton d'API du fournisseur DNS a expiré, le DNS a été migré chez un autre fournisseur, un enregistrement CAA bloque l'AC, ou un pare-feu bloque le challenge HTTP.
4. Les certificats manuels. Un certificat OV ou EV payant installé à la main sur un équipement réseau ou dans un panneau d'hébergement (cPanel, Plesk ou la console de votre hébergeur). À 47 jours, cela représente jusqu'à une douzaine d'interventions manuelles par certificat et par an.
5. La tâche de renouvellement disparue. Une entrée cron ou un timer systemd perdu lors d'une migration de serveur, ou un conteneur reconstruit sans elle.

Le point commun : l'outil de renouvellement signale un succès, ou ne signale rien du tout, et personne ne vérifie ce que les visiteurs reçoivent réellement.

Surveillance du certificat SSL : vérifiez ce que voit Internet, pas ce qui est sur le disque

Une vérification externe du certificat se connecte à votre hôte comme le ferait un navigateur et lit le certificat effectivement servi. Peu lui importe la cause du problème : elle détecte donc les cinq défaillances ci-dessus. Une vérification utile contrôle :

• le nombre de jours restants du certificat servi ;
• s'il couvre bien le nom d'hôte vérifié ;
• si la chaîne remonte jusqu'à une racine de confiance ;
• s'il est auto-signé, pas encore valide ou signé avec un algorithme de hachage faible ;
• l'apparition d'un nouveau certificat — la confirmation qu'un renouvellement est bien arrivé en production.

Les seuils d'alerte doivent suivre la durée de vie du certificat. Un avertissement « 30 jours restants » est utile pour un certificat d'un an, mais sur un certificat de 47 jours il se déclencherait environ deux semaines après l'installation, alors que votre automatisation fonctionne parfaitement. Des seuils fixes apprennent aux équipes à ignorer l'alerte, et une alerte ignorée est pire que pas d'alerte du tout.

Comment AlertSleep gère les certificats plus courts

Dans AlertSleep, la surveillance des certificats fait partie de chaque moniteur HTTPS : ce n'est pas un produit séparé. Pour chacun d'eux :

• le certificat est vérifié toutes les 6 heures ;
• des avertissements partent 30, 14, 7, 3 et 1 jour avant l'expiration — mais un seuil est ignoré lorsqu'il représente un tiers ou plus de la durée de vie du certificat, si bien qu'un certificat court fraîchement renouvelé ne déclenche jamais d'alerte ;
• vous êtes alerté lorsque le certificat a expiré, n'est pas encore valide, ne couvre pas le domaine, est auto-signé, utilise un algorithme de hachage de signature faible, présente une chaîne cassée ou est tout simplement absent ;
• vous êtes prévenu lorsqu'un nouveau certificat est servi, ce qui vous permet de constater que le renouvellement est arrivé en production au lieu de le supposer.

Concrètement, les seuils se répartissent ainsi :

Les alertes arrivent par e-mail et dans le tableau de bord, ainsi que via Slack, Telegram, Microsoft Teams et les autres intégrations pour lesquelles vous activez les notifications de certificat.

Vérifiez un domaine dès maintenant : passez-le dans notre vérificateur de certificat SSL gratuit. Laissez votre e-mail à côté du résultat : nous continuerons à surveiller ce certificat pour vous et vous préviendrons avant son expiration. Tout le reste est décrit sur la page Surveillance SSL.

Checklist à terminer avant le 15 mars 2027

1. Recensez tous les noms d'hôte publics dotés d'un certificat — sites web, API, serveurs de messagerie, points de terminaison CDN, pages de statut. Les journaux Certificate Transparency (par exemple crt.sh) montrent tous les certificats jamais émis pour votre domaine, y compris ceux que vous avez oubliés.
2. Pour chacun, notez ce qui le renouvelle et si le processus est automatisé de bout en bout, y compris le rechargement du serveur ou le téléversement sur le CDN.
3. Remplacez le renouvellement à intervalle fixe par un renouvellement fondé sur la durée de vie restante, ou par ARI si votre client ACME le prend en charge.
4. Testez la chaîne de validation : les identifiants d'API DNS et leur date d'expiration, les enregistrements CAA et les règles de pare-feu pour les challenges HTTP.
5. Repérez les certificats manuels sur les équipements réseau, dans les panneaux d'hébergement et dans les configurations CDN où ils ont été téléversés, et prévoyez de les automatiser ou de passer à des certificats gérés.
6. Placez une vérification externe sur chaque nom d'hôte de l'étape 1, pour que la prochaine défaillance se manifeste par une alerte plutôt que par un avertissement du navigateur.

FAQ

Les certificats que j'ai déjà cesseront-ils de fonctionner le 15 mars 2027 ?

Non. Les limites s'appliquent aux certificats émis à partir de chaque date. Un certificat de 200 jours émis le 1er mars 2027 reste valide jusqu'à sa propre date d'expiration.

Est-ce que cela concerne les certificats internes ou privés ?

Non. Les règles couvrent les certificats TLS reconnus publiquement, émis selon les Baseline Requirements du CA/Browser Forum. Une AC privée utilisée au sein de votre entreprise suit votre propre politique.

Puis-je échapper à la limite en achetant un certificat OV ou EV ?

Non. La durée de validité maximale est la même pour les certificats DV, OV et EV. Les certificats payants sont plus souvent renouvelés à la main : ce sont donc généralement eux qui posent problème en premier.

Pourquoi la durée de validité des certificats SSL raccourcit-elle ?

Une durée de vie plus courte limite le temps pendant lequel un certificat compromis ou émis par erreur peut être exploité, et réduit la dépendance aux vérifications de révocation, que les navigateurs effectuent de façon peu fiable. Elle impose aussi l'automatisation, qui supprime l'étape humaine où la plupart des renouvellements échouent.

Combien de fois par an devrai-je renouveler un certificat SSL de 47 jours ?

Au moins huit fois par certificat, et environ douze avec une marge de sécurité raisonnable. Avec une automatisation complète, cela ne demande pas plus de travail qu'un seul renouvellement ; sans elle, c'est une corvée mensuelle par nom d'hôte.

Sources

• CA/Browser Forum — Ballot SC-081v3 : calendrier de réduction des durées de validité et de réutilisation des données
• DigiCert — La durée de vie des certificats TLS sera officiellement réduite à 47 jours
• Let's Encrypt — Réduction de la durée de vie des certificats à 45 jours
• Let's Encrypt — Fin des e-mails de notification d'expiration