SaaSFort Le scrutin SC-081v3 a été adopté par le CA/Browser Forum en avril 2025 avec vingt-neuf voix pour et aucune contre. Apple l’a proposé. Google, Mozilla et Microsoft ont tous voté pour.
Il réduit la durée de vie maximale d’un certificat TLS publiquement reconnu de 398 jours à 47, en trois étapes.
| À partir du | Durée de vie maximale | Renouvellements par an |
|---|---|---|
| 15/03/2026 | 200 jours | ~2 |
| 15/03/2027 | 100 jours | ~4 |
| 15/03/2029 | 47 jours | ~8 |
La première étape est déjà en vigueur. Tout certificat émis aujourd’hui est plafonné à 200 jours.
L’étape qui casse vraiment les choses, c’est 2027
La plupart des équipes traversent les 200 jours sans rien changer, parce qu’un renouvellement semestriel reste quelque chose qu’un humain peut tenir dans un agenda.
À 100 jours, cela s’arrête. Quatre renouvellements par an, sur chaque domaine et chaque sous-domaine, avec un mode de défaillance brutal qui met le produit hors ligne et affiche un avertissement navigateur à chaque visiteur. Les équipes qui renouvellent à la main découvriront le problème comme on découvre toujours ces choses-là : un week-end.
Un second changement, moins commenté, court en parallèle. La réutilisation de la validation de domaine (DCV) tombe à 10 jours d’ici 2029. Aujourd’hui, vous validez un domaine une fois et réutilisez cette validation plus d’un an. Demain, vous re-prouverez le contrôle de chaque domaine environ trois fois par mois. Aucun processus manuel n’y survit.
Pourquoi ce plafond existe
Deux arguments, tous deux recevables.
Le premier est le confinement de la compromission. Une clé privée fuitée reste exploitable tant que le certificat est valide. La révocation est censée traiter cela et ne le fait pas vraiment, parce que la vérification de révocation est peu fiable en pratique. Un certificat de 398 jours offre à un attaquant jusqu’à treize mois. Un certificat de 47 jours lui en offre au plus sept semaines.
Le second est l’agilité cryptographique. Des durées courtes font que l’ensemble du parc de certificats du web se renouvelle vite, donc qu’une future migration d’algorithme, par exemple vers des signatures post-quantiques, prend des semaines et non des années. Le chiffre de 47 jours a été choisi délibérément : assez court pour rendre le renouvellement manuel impossible à l’échelle, assez long pour qu’une automatisation absorbe un échec et réessaie.
Que faire
Automatiser l’émission avec ACME. L’outillage est mature et gratuit.
- certbot, le client de référence, convient pour une poignée d’hôtes.
- lego, un binaire Go unique, pratique pour la CI et les fournisseurs DNS atypiques.
- cert-manager, la bonne réponse sur Kubernetes, où il renouvelle et recharge sans intervention humaine.
Le principe compte davantage que l’outil : la fréquence de renouvellement doit être découplée de la durée de vie du certificat. Déclenchez le renouvellement à une fraction fixe de la durée restante, typiquement un tiers, pour qu’un nouvel abaissement du plafond ne demande aucune modification. Les équipes qui codent en dur « renouveler 30 jours avant l’expiration » devront y revenir deux fois encore.
Puis surveillez depuis l’extérieur. Une automatisation qui s’arrête silencieusement est pire qu’aucune automatisation, car elle supprime l’humain qui remarquait le problème.
Le contrôle que la plupart des scanners ratent
Il existe deux questions distinctes à propos d’un certificat, et on les confond régulièrement.
Quand expire-t-il ? C’est la question opérationnelle. Elle vous dit si le site casse mardi prochain.
Pour combien de temps a-t-il été émis ? C’est la question de processus. Un certificat frappé pour 300 jours vous dit que le processus d’émission est antérieur aux règles actuelles, ou que l’équipe achète le certificat le plus long disponible et renouvelle à la main.
Seule la seconde prédit la panne que vous aurez en 2027. C’est aussi celle qui doit être jugée contre le plafond en vigueur à la date d’émission du certificat, et non à la date du jour, car un certificat de 398 jours émis en 2025 était parfaitement conforme au moment de sa frappe et reste valide aujourd’hui.
Se tromper là-dessus produit un scanner qui fait échouer tout certificat hérité pourtant émis dans les règles, ce qui est précisément la façon dont un outil apprend aux équipes à l’ignorer.
Où cela se mappe en conformité
- NIS2 article 21(2)(h), cryptographie et chiffrement.
- ISO/IEC 27001:2022 A.8.24, usage de la cryptographie.
- DORA article 9, pour les entités financières.
Les auditeurs commencent à demander non seulement si les certificats sont valides, mais comment le renouvellement est effectué. « Manuellement, par l’équipe plateforme » est une réponse qui appelle désormais une question sur ce qui se passe quand cette personne est en congé.
Comment le vérifier vous-même
echo | openssl s_client -connect votredomaine.fr:443 2>/dev/null \
| openssl x509 -noout -dates
Soustrayez notBefore de notAfter. Si le résultat dépasse 100 jours, votre cadence de renouvellement doit changer avant mars 2027. S’il dépasse 200 jours pour un certificat émis après le 15/03/2026, quelque chose cloche dans votre chaîne d’émission.
En résumé
L’échéance n’est pas 2029. L’échéance est le 15/03/2027, car c’est l’étape qui casse un processus qu’un humain peut encore tenir aujourd’hui.
Automatisez maintenant, tant que c’est un projet planifié et non un incident.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.