Certificats TLS : de 398 à 47 jours, le renouvellement manuel a vécu

Les règles qui encadrent les certificats TLS publics sont fixées par le CA/Browser Forum, qui réunit les autorités de certification et les éditeurs de navigateurs. Le 11 avril 2025, il a adopté le ballot SC-081v3 : 25 autorités pour, aucune contre, 5 abstentions, et le vote unanime des quatre éditeurs de navigateurs (Apple, Google, Microsoft et Mozilla). Le texte réduit progressivement la durée de vie maximale d'un certificat, qui était de 398 jours, jusqu'à 47 jours.

La durée de réutilisation de la validation du domaine suit la même pente. Aujourd'hui, une autorité peut s'appuyer sur une preuve de contrôle du domaine vieille de plusieurs mois pour émettre un nouveau certificat. En 2029, cette preuve ne vaudra plus que 10 jours : concrètement, chaque renouvellement ou presque exigera une nouvelle validation, via un enregistrement DNS ou un fichier HTTP.

Pourquoi raccourcir

Un certificat atteste qu'une clé appartient à un domaine à un instant donné. Plus il vit longtemps, plus cette attestation risque d'être fausse : clé volée, domaine revendu, certificat émis par erreur. En théorie, la révocation règle ces cas. En pratique, elle fonctionne mal, car les navigateurs ne vérifient pas tous l'état de révocation à chaque connexion, ou ignorent l'échec de cette vérification. La seule garantie fiable est donc l'expiration. Let's Encrypt résume l'argument : des durées courtes limitent l'exposition en cas d'émission erronée ou de clé compromise, et poussent à automatiser, ce qui les rend aussi simples que les longues.

Le calendrier de Let's Encrypt

Let's Encrypt, l'autorité qui émet le plus de certificats sur le web, va plus vite que le calendrier imposé. Ses certificats durent 90 jours depuis toujours. Depuis janvier 2026, des certificats de 160 heures (un peu plus de six jours) sont disponibles pour tous, sur demande, via le profil ACME « shortlived ». Depuis le 13 mai 2026, le profil « tlsserver » émet des certificats de 45 jours pour ceux qui veulent s'y préparer. Puis le profil par défaut passera à 64 jours le 10 février 2027, avec une réutilisation de la validation de 10 jours, et à 45 jours le 16 février 2028, avec une réutilisation limitée à 7 heures.

Avec 45 jours de validité et un renouvellement aux deux tiers de la durée, un domaine change de certificat une douzaine de fois par an, contre une fois avec un certificat de 398 jours. Ce qui se faisait à la main une fois l'an, avec un rappel dans un agenda, ne tient plus.

Ce qui va casser

• Les certificats achetés et installés à la main, sur un serveur, un équilibreur de charge ou un CDN : chaque copie manuelle devient une panne programmée.
• Les applications mobiles ou clients d'API qui épinglent le certificat du serveur plutôt que la clé ou l'autorité : ils cassent à chaque rotation.
• Les validations DNS faites à la main : avec une réutilisation de 10 jours, il faut un accès programmatique à la zone DNS, ou la validation HTTP.
• Les sous-domaines oubliés (préproduction, ancien back-office) que personne ne surveille : ils expirent sans que personne ne s'en aperçoive avant un client.

# When does the certificate actually served expire?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

# certbot: renew whatever is due, then reload the web server
certbot renew --quiet --deploy-hook "systemctl reload nginx"

# Prefer ACME clients that support ARI (RFC 9773): the CA tells the
# client when to renew, including early renewal after a revocation.

Si votre hébergeur ou votre CDN gère déjà le certificat (Vercel, Netlify, Cloudflare, la plupart des PaaS), le changement est invisible. Le risque se concentre sur ce qui ne passe pas par eux : serveurs gérés soi-même, domaines personnalisés configurés à la main, services internes exposés. Et il faut surveiller le certificat réellement servi, pas celui qu'on croit avoir déployé.