Certificats SSL de 47 jours : ce qui change et comment s'y préparer

Depuis le 15 mars 2026, un certificat TLS public ne peut plus dépasser 200 jours de validité. Ce n'est que la première marche : en 2029, la durée maximale tombera à 47 jours. Pour un webmaster qui renouvelait « son SSL » une fois par an en se connectant au panneau de son hébergeur, le changement est profond. Voici le calendrier exact, ce qui va casser en pratique, et un plan d'action concret pour passer à un renouvellement entièrement automatisé.

Le calendrier officiel du ballot SC-081

Les règles applicables aux certificats publics sont fixées par le CA/Browser Forum, qui réunit les autorités de certification (AC) et les éditeurs de navigateurs. En avril 2025, le forum a adopté le ballot SC-081v3, qui réduit par étapes deux durées : la validité maximale des certificats et la durée pendant laquelle une AC peut réutiliser une validation de domaine déjà effectuée.

Le ballot réduit aussi la réutilisation des informations d'identité de l'organisation (utilisées pour les certificats OV et EV) à 398 jours à partir de mars 2026. Les certificats DV, les plus courants, ne sont pas concernés par ce dernier point.

La ligne qui fera le plus mal n'est pas forcément celle des 47 jours, mais celle des 10 jours de réutilisation : en 2029, il faudra en pratique prouver le contrôle du domaine à chaque renouvellement ou presque. Une validation par e-mail cliquée à la main par un humain devient intenable.

Pourquoi raccourcir autant la durée de vie des certificats ?

Les arguments avancés sont techniques, pas commerciaux :

• La révocation fonctionne mal. Quand une clé privée fuit ou qu'un certificat a été émis par erreur, le révoquer ne garantit pas que tous les clients le rejetteront. Let's Encrypt a d'ailleurs arrêté son service OCSP en août 2025 au profit des seules listes de révocation (CRL). Un certificat court limite mécaniquement la fenêtre d'exposition.
• Les informations validées vieillissent. Un domaine peut changer de propriétaire, un hébergement peut être résilié. Plus la validation est ancienne, moins elle reflète la réalité.
• L'agilité cryptographique. Le jour où il faudra remplacer massivement des algorithmes (migration post-quantique notamment), un écosystème qui renouvelle déjà tout automatiquement en quelques semaines sera prêt ; un écosystème qui renouvelle à la main une fois par an ne le sera pas.

Qui est concerné, et qui ne l'est pas

Les règles du CA/Browser Forum s'appliquent aux certificats publiquement reconnus par les navigateurs : ceux de Let's Encrypt, Sectigo, DigiCert, GlobalSign, ZeroSSL, etc. Elles ne s'appliquent pas aux certificats émis par une PKI privée (AC interne d'entreprise, certificats auto-signés d'un environnement de développement).

Si vous utilisez déjà Let's Encrypt avec un client ACME, vous êtes à 90 jours et largement dans les clous. Let's Encrypt a toutefois annoncé son propre calendrier :

• depuis le 13 mai 2026, un profil ACME optionnel (tlsserver) délivre des certificats de 45 jours ;
• le 10 février 2027, le profil par défaut passera à 64 jours, avec une réutilisation d'autorisation de 10 jours ;
• le 16 février 2028, le profil par défaut passera à 45 jours, avec une réutilisation d'autorisation de 7 heures.

Conséquence directe : tout script qui renouvelle « tous les 60 jours » à heure fixe cessera de fonctionner correctement.

Ce qui va casser en pratique

1. Les renouvellements manuels

Un certificat payant acheté chez un revendeur, puis installé à la main dans cPanel, Plesk ou sur un serveur : c'était une opération annuelle. À 200 jours, c'est déjà deux fois par an. À 100 jours, quatre fois. À 47 jours, avec une marge de sécurité, c'est à peu près tous les mois. Multipliez par le nombre de domaines d'une agence et l'oubli devient une certitude statistique.

2. La validation de domaine par e-mail

Beaucoup de certificats DV payants sont encore validés par un e-mail envoyé à admin@ ou webmaster@. Avec une réutilisation limitée à 10 jours en 2029, cette validation devra être refaite quasiment à chaque émission. Les méthodes automatisables (enregistrement DNS ou fichier HTTP via ACME) deviennent la seule option réaliste.

3. Les enregistrements CAA oubliés

L'enregistrement DNS CAA indique quelles AC ont le droit d'émettre un certificat pour votre domaine. C'est une bonne protection, mais c'est aussi un piège : si votre zone contient 0 issue "sectigo.com" et que vous migrez vers Let's Encrypt, ou que vous activez un CDN qui émet ses propres certificats, l'émission sera refusée. Aujourd'hui, l'erreur apparaît une fois par an ; demain, elle bloquera un renouvellement automatique en pleine nuit.

dig CAA exemple.fr +short
0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:securite@exemple.fr"

Vérifiez aussi les sous-domaines : un enregistrement CAA posé sur boutique.exemple.fr prime sur celui du domaine parent.

4. Les certificats copiés sur plusieurs équipements

Le même certificat est souvent déployé à plusieurs endroits : répartiteur de charge, serveur de messagerie (Postfix, Dovecot), serveur FTP, NAS, équipement réseau, CDN avec certificat personnalisé. Le renouvellement automatique sur le serveur web ne met pas à jour ces copies. Chaque copie manuelle est une future expiration.

5. Les alertes calibrées sur « 30 jours avant »

Une alerte fixe à 30 jours de l'expiration avait du sens pour un certificat d'un an. Sur un certificat de 47 jours, elle se déclencherait 17 jours après l'émission, bien avant la date normale de renouvellement : du bruit permanent, que l'équipe finira par ignorer. Les seuils d'alerte doivent désormais dépendre de la durée de vie réelle du certificat.

Plan d'action : passer au renouvellement 100 % automatisé

1. Inventorier tous les certificats publics. Ne vous fiez pas à votre mémoire : les journaux Certificate Transparency listent tous les certificats émis pour vos domaines. Une recherche sur https://crt.sh/?q=%25.exemple.fr révèle souvent des sous-domaines et des émetteurs oubliés.
2. Classer chaque certificat selon son mode de renouvellement : ACME automatique, automatique chez l'hébergeur ou le CDN, ou manuel. Tout ce qui est manuel est prioritaire.
3. Remplacer le manuel par ACME. La plupart des AC commerciales proposent désormais ACME. Si vous tenez à un certificat OV ou EV, vérifiez que votre fournisseur le permet.
4. Choisir la bonne méthode de validation. HTTP-01 suffit pour un serveur web exposé. Pour les certificats wildcard ou les serveurs non exposés, utilisez DNS-01 avec l'API de votre hébergeur DNS. Si vous ne voulez pas confier une clé d'API qui donne accès à toute la zone, déléguez uniquement _acme-challenge.exemple.fr via un CNAME vers une zone dédiée.
5. Relire vos enregistrements CAA et les aligner avec les AC réellement utilisées, y compris par vos CDN. Let's Encrypt prend en charge les paramètres accounturi et validationmethods, qui restreignent l'émission à un compte ACME ou à une méthode de validation précis.
6. Automatiser le déploiement, pas seulement l'émission. Un certificat renouvelé mais jamais rechargé par Nginx ne sert à rien. Utilisez les hooks de déploiement de votre client ACME pour recharger les services et pousser les copies vers les autres équipements.
7. Surveiller le certificat réellement servi, depuis l'extérieur, sur chaque domaine et sous-domaine. C'est la seule façon de détecter un renouvellement qui échoue silencieusement.

ACME en pratique : quelques repères

Si vous partez de zéro, le choix du client dépend de votre environnement :

• Serveur Linux avec Nginx ou Apache : Certbot ou acme.sh. Testez toujours le renouvellement à blanc : certbot renew --dry-run.
• Serveur web moderne : Caddy gère ACME nativement, Traefik aussi pour les environnements conteneurisés.
• Hébergement mutualisé : la plupart des hébergeurs proposent Let's Encrypt en un clic ; vérifiez qu'il est bien actif sur tous les domaines et alias, pas seulement sur le domaine principal.
• Kubernetes : cert-manager.

Ne codez pas en dur une périodicité. Let's Encrypt recommande de s'appuyer sur ARI (ACME Renewal Information), qui permet à l'AC d'indiquer au client quand renouveler, ou à défaut de renouveler vers les deux tiers de la durée de vie du certificat.

Contrôler un certificat en ligne de commande

Pour vérifier les dates, l'émetteur et donc la durée de vie d'un certificat servi :

echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
  | openssl x509 -noout -issuer -startdate -enddate

Pour savoir si le certificat expire dans les 15 prochains jours (code de retour non nul le cas échéant, pratique dans un script) :

echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
  | openssl x509 -noout -checkend 1296000

Si votre site répond sur plusieurs adresses IP, testez-les une par une : un nœud oublié derrière le répartiteur peut servir un ancien certificat.

Checklist récapitulative

• Inventaire des certificats publics fait, sous-domaines compris (journaux CT).
• Aucun certificat renouvelé à la main, ou liste explicite des exceptions avec un responsable.
• Validation de domaine automatisée (HTTP-01 ou DNS-01), plus de validation par e-mail.
• Enregistrements CAA cohérents avec les AC utilisées, CDN compris.
• Hooks de déploiement en place pour recharger les services et mettre à jour les copies.
• Pas de périodicité fixe codée en dur dans les scripts.
• Surveillance externe du certificat servi, avec des seuils adaptés à sa durée de vie.

Le passage aux certificats courts est aussi l'occasion de faire le ménage dans la configuration DNS qui les conditionne ; notre article sur la surveillance de la configuration DNS détaille les enregistrements à garder à l'œil.

Vérifiez où vous en êtes

Pour savoir immédiatement si un domaine est prêt, passez-le dans notre vérificateur SSL gratuit : il affiche la validité, l'émetteur, les dates d'émission et d'expiration, donc la durée de vie, ainsi que les noms couverts par le certificat. Pour une surveillance continue, Domains Defender contrôle l'expiration, la durée de vie et la compatibilité CAA de vos certificats, avec des seuils d'alerte qui s'adaptent à la durée de vie de chacun ; le plan gratuit couvre un domaine, avec la surveillance DNS, SSL et de l'expiration du nom de domaine.

Mars 2027 et ses 100 jours arrivent vite. Les équipes qui auront automatisé en 2026 n'auront rien à faire ; les autres renouvelleront à la main tous les trimestres, puis tous les mois.