Certificats SSL/TLS : les nouvelles durées à anticiper dès 2026

Des certificats plus courts pour le Web

Depuis le 15 mars 2026, un certificat SSL/TLS public ne peut plus être émis avec une durée de validité supérieure à 200 jours. Cette règle s'applique à l'ensemble du Web public : sites institutionnels, API, boutiques en ligne et services accessibles via HTTPS. Cette limite concerne tous les types de pages accessibles en HTTPS, y compris celles consacrées à Aviator 1xBet, puisque la durée de validité du certificat ne dépend pas du contenu affiché. Pour les administrateurs, l'enjeu est surtout opérationnel : un processus autrefois compatible avec un renouvellement annuel doit désormais gérer des cycles beaucoup plus courts.

Un calendrier qui mène à 47 jours

La réduction découle du Ballot SC-081v3 du CA/Browser Forum, proposé par Apple et soutenu notamment par Google Chrome, Mozilla et Sectigo. Le texte a été adopté le 11 avril 2025. Parmi les autorités de certification, 25 ont voté pour, aucune contre et cinq se sont abstenues. Apple, Google, Microsoft et Mozilla ont également soutenu le changement.

Le calendrier est désormais fixé :

- jusqu'au 14 mars 2026 : 398 jours maximum ;

- du 15 mars 2026 au 14 mars 2027 : 200 jours ;

- du 15 mars 2027 au 14 mars 2029 : 100 jours ;

- à partir du 15 mars 2029 : 47 jours.

Ces limites concernent les nouveaux certificats émis à partir de chaque date. Un certificat déjà créé conserve donc son expiration initiale.

Certaines autorités ont anticipé le changement. DigiCert a limité ses certificats publics à 199 jours le 24 février 2026, puis Sectigo a fait de même le 12 mars. Cette marge d'un jour évite de dépasser accidentellement le plafond réglementaire de 200 jours.

Pourquoi réduire autant leur durée

L'objectif principal est de diminuer la période pendant laquelle un certificat ou une clé privée compromis restent exploitables.

Avec un certificat valable plus d'un an, une clé copiée, une erreur d'émission ou une infrastructure compromise peuvent rester problématiques longtemps si la révocation n'est pas correctement prise en compte. Réduire la validité ne remplace pas les CRL ou l'OCSP, mais limite mécaniquement le temps d'exposition.

Le CA/Browser Forum réduit aussi la durée de réutilisation des validations de domaine ou d'adresse IP. Elle est passée de 398 à 200 jours le 15 mars 2026, tombera à 100 jours en mars 2027, puis à seulement 10 jours en mars 2029. Pour les certificats OV et EV, certaines données liées à l'identité de l'organisation suivent des règles distinctes. Plusieurs éléments de validation EV, comme l'existence juridique, l'adresse ou l'existence opérationnelle, restent réutilisables pendant un maximum de 398 jours.

Le renouvellement manuel devient difficile à maintenir

Pour un site isolé, passer de 398 à 200 jours peut sembler limité. À grande échelle, la différence est beaucoup plus visible.

Prenons une infrastructure de 1 000 certificats. Avec un renouvellement déclenché après environ deux tiers de leur durée de vie, un certificat de 398 jours est renouvelé tous les 265 jours environ, soit autour de 1 376 renouvellements par an.

Avec une validité de 47 jours, le renouvellement intervient environ tous les 31 jours. Le même parc approche alors 11 650 opérations par an.

Ce calcul reste illustratif, mais il montre pourquoi les tickets, rappels de calendrier et remplacements manuels de fichiers deviennent difficiles à maintenir. Le problème concerne particulièrement les load balancers, appliances réseau, systèmes embarqués ou anciennes applications qui ne savent pas récupérer et installer automatiquement un nouveau certificat.

ACME et ARI deviennent essentiels

Les sites utilisant déjà ACME avec Certbot, acme.sh ou une solution intégrée à leur hébergeur sont mieux préparés. Le protocole permet d'obtenir et de déployer automatiquement de nouveaux certificats sans répéter une procédure manuelle à chaque échéance.

L'extension ACME Renewal Information, ou ARI, va plus loin. Standardisée dans la RFC 9773, elle permet à l'autorité de certification d'indiquer au client une fenêtre recommandée de renouvellement. Le client n'a donc plus besoin de supposer qu'il faut renouveler exactement 30 ou 60 jours avant expiration.

Cette logique devient importante lorsque les durées changent. Une tâche configurée autrefois pour renouveler « 60 jours avant expiration » peut devenir incohérente avec un certificat qui ne dure lui-même que 45 ou 47 jours.

Le principe reste le même pour tous les services accessibles en HTTPS. Lorsqu'un navigateur établit une connexion HTTPS, le serveur d'une page telle que https://1xbet.td/fr/slots/game/112402/chicken-road doit présenter un certificat valide, conformément au principe appliqué aux autres services Web.

Let's Encrypt accélère son propre calendrier

Let's Encrypt émettait déjà des certificats de 90 jours, bien avant la réduction décidée par le CA/Browser Forum. À partir du 10 février 2027, son profil ACME classique délivrera par défaut des certificats de 64 jours, avec une réutilisation des autorisations limitée à 10 jours. Puis, le 16 février 2028, la durée standard passera à 45 jours.

Depuis le 14 octobre 2026, l'environnement de staging de Let's Encrypt émet déjà des certificats de 64 jours avec son profil classique. Les administrateurs peuvent donc tester leurs scripts, outils de déploiement et systèmes de surveillance avant les prochaines échéances.

Let's Encrypt recommande l'utilisation d'ARI. Pour les clients qui ne le prennent pas encore en charge, l'alternative consiste à renouveler après environ deux tiers de la durée de vie du certificat, plutôt qu'à utiliser un nombre fixe de jours.

L'échéance de 2027 doit être préparée dès maintenant

Le plafond de 200 jours reste encore compatible avec certaines procédures semi-manuelles. Le prochain palier sera plus contraignant : à partir du 15 mars 2027, aucun nouveau certificat TLS public ne pourra dépasser 100 jours.

Les équipes doivent donc vérifier l'inventaire de leurs certificats, la compatibilité ACME des équipements, les règles intégrées aux scripts et les alertes déclenchées en cas d'échec.

Le plafond de 47 jours en mars 2029 marque surtout la fin du certificat public installé puis oublié pendant un an. À ce stade, le renouvellement devra fonctionner comme une opération automatisée et continue de l'infrastructure Web.