Certificats Let's Encrypt à 6 jours : faut-il sauter le pas ?

Guide DevOps / WebOps pour comprendre les certificats à durée de vie courte (shortlived) et décider si vous devez migrer.

TL;DR

Let's Encrypt propose désormais au grand public des certificats valides 6 jours (profil shortlived), en plus du classique 90 jours. Pour les certificats sur adresse IP, c'est même obligatoire. La question n'est pas "est-ce que c'est bien ?" — techniquement oui — mais "est-ce que mon infra est prête ?". Si votre renouvellement automatique fonctionne sans accroc depuis 6 mois, foncez. Sinon, fiabilisez d'abord, migrez ensuite.

1. De quoi on parle

Depuis janvier 2026, Let's Encrypt émet en disponibilité générale deux nouveautés couplées : les certificats pour adresses IP, et les certificats à durée de vie de 6 jours via un nouveau profil ACME nommé shortlived. Certbot 4.0 a introduit le flag --preferred-profile pour les sélectionner, et Certbot 5.3 a ajouté --ip-address pour demander un cert sur IP.

Concrètement, un certificat shortlived a une validité de ~6 jours au lieu de 90. Tout le reste — chaîne de confiance, algorithmes, format — est identique. Pour le navigateur, c'est un certificat Let's Encrypt standard.

Les profils disponibles

2. Pourquoi Let's Encrypt pousse vers le court

Quatre raisons techniques, par ordre d'importance.

2.1 La révocation TLS est cassée — autant l'éviter

C'est le vrai sujet. Le mécanisme de révocation des certificats (CRL, OCSP) n'a jamais fonctionné correctement à grande échelle :

• OCSP soft-fail : si le serveur OCSP est injoignable, la plupart des navigateurs acceptent quand même le certificat. Un attaquant qui contrôle le réseau bloque l'OCSP et le cert révoqué passe.
• OCSP stapling mal configuré sur beaucoup de serveurs.
• CRLite, OneCRL : couvertures partielles, déploiement client incohérent.
• OCSP retiré : Let's Encrypt a arrêté OCSP en 2025, justement parce que ça ne servait quasiment à rien tout en posant des problèmes de vie privée.

Avec un cert à 6 jours, la révocation devient cosmétique : on attend l'expiration. La fenêtre d'exploitation d'une clé compromise passe de plusieurs semaines (cert 90 jours, OCSP douteux) à quelques jours maximum.

2.2 Réduire la fenêtre de compromission

Si votre clé privée fuite (backup mal protégé, faille serveur, employé qui part avec une copie, vulnérabilité type Heartbleed), l'attaquant peut usurper votre site tant que le cert est valide. À 90 jours, c'est trois mois d'exposition dans le pire cas. À 6 jours, c'est une semaine.

C'est encore plus critique pour les certs sur IP : une IP peut changer de propriétaire (cloud, VPS recyclé, réattribution FAI). Un cert long pour une IP qui ne vous appartient plus, c'est un risque que LE refuse de prendre — d'où l'obligation du profil court pour cet usage.

2.3 Forcer une automatisation propre

Personne ne renouvelle un cert à la main tous les 6 jours. C'est mécaniquement infaisable. Le profil shortlived est donc un filtre qualité : si votre renouvellement n'est pas blindé, vous le saurez vite.

L'effet de bord positif : ça élimine les pannes classiques type "le cert a expiré parce que le cron était cassé depuis trois mois et personne ne s'en est rendu compte". À 6 jours, un cron cassé devient visible immédiatement.

2.4 Agilité cryptographique

Si une vulnérabilité majeure impose de déprécier un algorithme en urgence (RSA, transition post-quantique, faille découverte sur SHA-256), un parc avec des certs à 6 jours bascule en une semaine. Un parc 90 jours met trois mois. C'est la raison qui motive aussi le CA/Browser Forum à pousser globalement vers des durées plus courtes (45 jours d'ici 2029 dans la baseline).

3. Pourquoi vous pourriez ne pas migrer

Soyons honnêtes : pour la plupart des infras web classiques, le 90 jours suffit largement. Le 6 jours a des coûts réels.

3.1 Pression sur le rate limiting

Let's Encrypt limite à 300 nouveaux certificats par compte par 3 heures et 5 duplicatas de cert par semaine. Avec des certs 90 jours, vous renouvelez ~4 fois par an. Avec des 6 jours, c'est ~60 fois par an et par cert. Si vous avez 50 services derrière 50 certs distincts, vous explosez votre budget de requêtes ACME.

Mitigation : regrouper les domaines dans des certs SAN (un seul cert pour app.a5l.fr, api.a5l.fr, admin.a5l.fr plutôt que trois certs).

3.2 Dépendance critique au CA et au réseau

À 90 jours, si Let's Encrypt est down 48h, vous ne le remarquez même pas. À 6 jours, une panne de 48h sur LE et votre fenêtre de renouvellement (typiquement à 1/3 de la durée restante, soit ~2 jours), et votre cert expire. Vos services tombent.

Conséquences concrètes :

• Il faut un monitoring sérieux de l'expiration des certs (Prometheus blackbox exporter, check_ssl_cert, etc.).
• Il faut un fallback : second client ACME, second account, ou cert de secours d'une autre CA.
• Il faut absolument que la résolution DNS et le port 80/443 sortants depuis votre serveur soient fiables.

3.3 Charge sur les systèmes de déploiement

Chaque renouvellement déclenche : appel ACME, validation HTTP-01 ou DNS-01, écriture des fichiers, rechargement du serveur web (Nginx, Apache, HAProxy, etc.). À ~60 fois par an au lieu de 4, ça multiplie par 15 le nombre de reloads.

Sur un serveur web basique, un nginx -s reload est gratuit. Sur des architectures plus complexes (load balancers stateful, terminations TLS distribuées, certs poussés vers un CDN, configs multi-nœuds avec Ansible/Salt), chaque renouvellement déclenche une cascade. À évaluer.

3.4 Logs, audit, conformité

Certains contextes réglementaires demandent une traçabilité des certificats (PCI-DSS, ISO 27001, HDS). Multiplier par 15 le volume d'événements de renouvellement à archiver et auditer, ça représente du stockage et du tooling à adapter.

3.5 Le cas "monitoring TLS externe"

Si vous avez des outils tiers (uptime monitors, scanners de conformité) qui vérifient l'expiration de vos certs, ils risquent de hurler en permanence : un cert qui montre toujours "expire dans 6 jours" déclenche les alertes "cert expirant bientôt" sur la plupart des outils mal configurés. Il faut soit ajuster les seuils, soit changer d'outil.

4. Décision : grille de lecture

5. Comment migrer concrètement (Certbot)

5.1 Pré-requis

Avant tout :

1. Certbot 4.0+ pour --preferred-profile, 5.3+ pour --ip-address, 5.4+ pour webroot avec IP.
2. Un renouvellement automatique opérationnel et vérifié (timer systemd ou cron actif, testé avec certbot renew --dry-run).
3. Un monitoring d'expiration des certs en place. Si vous n'en avez pas, installez-le avant de migrer.
4. Un hook de reload du serveur web qui fonctionne (--deploy-hook).

5.2 Test sur le staging Let's Encrypt

sudo certbot certonly --staging \
  --preferred-profile shortlived \
  --webroot \
  --webroot-path /var/www/html \
  -d test.example.com

Vérifier que le cert obtenu a bien une durée de 6 jours :

openssl x509 -in /etc/letsencrypt/live/test.example.com/cert.pem -noout -dates

5.3 Renouvellement plus fréquent

Par défaut, Certbot renouvelle quand il reste 1/3 de la durée. Pour un cert 6 jours, ça veut dire renouveler à 2 jours restants. Ça laisse peu de marge en cas de panne. Vous pouvez forcer un renouvellement plus tôt :

# Renouvelle si moins de 4 jours restants (au lieu de 2 par défaut)
certbot renew --deploy-hook "systemctl reload nginx"

Le timer Certbot tourne deux fois par jour par défaut, ce qui est suffisant. Pas besoin de l'accélérer.

5.4 Cas d'un certificat sur IP

sudo certbot certonly \
  --preferred-profile shortlived \
  --webroot \
  --webroot-path /var/www/html \
  --ip-address 203.0.113.42

Note importante : Certbot ne sait pas encore installer automatiquement les certs IP dans Nginx ou Apache. Il faut éditer la config manuellement pour pointer vers /etc/letsencrypt/live/<ip>/fullchain.pem et privkey.pem, et configurer un --deploy-hook pour le reload.

5.5 Plan de bascule recommandé

1. Semaine 1-2 : un domaine non critique (un sous-domaine de test, un service interne) en shortlived. Surveillez les renouvellements.
2. Semaine 3-4 : étendez à la moitié de votre dev/staging.
3. Semaine 5-6 : migration progressive en prod, en commençant par les services les moins critiques.
4. À tout moment : possibilité de retour arrière en supprimant --preferred-profile shortlived du fichier de config Certbot dans /etc/letsencrypt/renewal/<domain>.conf.

6. Pièges à éviter

• Ne migrez pas tout en même temps. Si votre hook de reload a un bug, vous le découvrez sur un seul service, pas sur 50.
• Ne désactivez pas le monitoring d'expiration sous prétexte que c'est automatisé. L'automatisation peut casser silencieusement. Un check externe qui hurle à J-2 reste indispensable.
• Attention aux secrets stockés dans des configs autres que Certbot. Si vous avez des certs poussés manuellement vers un CDN, un load balancer cloud ou un firewall TLS-inspectant, le passage à 6 jours impose d'automatiser cette propagation aussi.
• Pas de cert IP pour un service exposé publiquement à long terme. Si l'IP change, le cert devient inutilisable instantanément. Préférez le DNS quand c'est possible.
• Vérifiez votre client ACME. Tous les clients ACME ne supportent pas encore les profils. acme.sh, Caddy, lego, Traefik : checkez la version. Certbot 4.0 minimum.

7. Verdict

Le profil shortlived est techniquement supérieur au 90 jours sur le plan sécuritaire. Mais il déplace le coût : moins de risques liés aux clés compromises et à la révocation cassée, plus de risques liés à la chaîne de renouvellement.

La règle simple : si votre renouvellement automatique est fiable, migrez. Sinon, fiabilisez-le d'abord — la migration n'en sera que la conséquence naturelle.

Pour la majorité des infras web auto-hébergées (typiquement, un Proxmox + reverse proxy + une dizaine de services derrière), le 90 jours reste un excellent compromis. Le shortlived devient pertinent quand :

• Vous avez besoin de certs sur IP (obligatoire).
• Vous exploitez des services à forte exigence de sécurité (clés très sensibles).
• Vous voulez tester votre résilience opérationnelle (le 6 jours est un excellent test de fiabilité de votre stack).

Le reste du temps, gardez le 90 jours, dormez tranquille, et ressortez ce document quand le CA/Browser Forum imposera 45 jours par défaut (vers 2027-2028).

Sources

• Let's Encrypt — Six-Day and IP Address Certificates Available in Certbot (mars 2026)
• Let's Encrypt — 6-day and IP address certs in general availability (janvier 2026)
• Documentation Certbot — Hooks
• CA/Browser Forum Baseline Requirements