Cédrix
200 lines
12 KiB
Markdown
200 lines
12 KiB
Markdown
# 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
|
|
|
|
| Profil | Durée | Usage |
|
|
|---|---|---|
|
|
| `classic` (défaut) | 90 jours | Tout le monde, par défaut |
|
|
| `shortlived` | ~6 jours | Adopters précoces, certs sur IP (obligatoire) |
|
|
| `tlsserver` | 90 jours | Variante optimisée serveur web (sans clientAuth) |
|
|
|
|
---
|
|
|
|
## 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
|
|
|
|
| Situation | Recommandation |
|
|
|---|---|
|
|
| Serveurs web classiques, renouvellement Certbot qui marche, < 20 certs | Restez en 90 jours. Le bénéfice marginal ne justifie pas le risque. |
|
|
| Vous gérez des **certs sur IP** | Pas le choix : `shortlived` est obligatoire. |
|
|
| Architecture critique avec rotation de clés agressive (banque, santé, infra publique) | Migrez. Le 6 jours est aligné avec vos exigences de sécurité. |
|
|
| Infra dev/staging interne | Excellent terrain de test. Migrez d'abord ici pour valider votre pipeline. |
|
|
| Vous avez déjà eu une expiration cert non détectée en prod | **Ne migrez pas tout de suite.** Fiabilisez d'abord le monitoring et le renouvellement, puis migrez. Sinon vous transformez un incident annuel en incident hebdomadaire. |
|
|
| Vous publiez via reverse proxy unique (un seul cert SAN pour plusieurs services) | Bon candidat. Un seul renouvellement à fiabiliser. |
|
|
| Vous avez un parc hétérogène (Apache + Nginx + HAProxy + Traefik...) avec hooks custom | Auditez chaque hook avant de migrer. C'est là que ça casse. |
|
|
|
|
---
|
|
|
|
## 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
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
# 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
|
|
|
|
```bash
|
|
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](https://letsencrypt.org/2026/03/11/shorter-certs-certbot) (mars 2026)
|
|
- [Let's Encrypt — 6-day and IP address certs in general availability](https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability) (janvier 2026)
|
|
- [Documentation Certbot — Hooks](https://eff-certbot.readthedocs.io/en/stable/using.html#hooks)
|
|
- [CA/Browser Forum Baseline Requirements](https://cabforum.org/baseline-requirements-documents/) |