Let’s Encrypt : certificats de 45 jours et automatisation du renouvellement des serveurs

Automatisez dès maintenant le renouvellement ACME, le déploiement du certificat et le rechargement des services qui l’utilisent. Les certificats Let’s Encrypt doivent atteindre une durée de 45 jours en 2027 : un rappel manuel ne suffit plus, et il faut surveiller le certificat réellement présenté aux clients.

Cette évolution s’inscrit dans la réduction générale des durées de vie TLS. Pour le contexte global, consultez notre guide sur les certificats TLS de 200 jours et la préparation des serveurs.

Préparer le renouvellement et la validation ACME

Let’s Encrypt émet historiquement des certificats valables 90 jours et prévoit une étape à 64 jours en 2026, avant 45 jours en 2027. Ces dates et paramètres peuvent évoluer : référez-vous à la documentation de transition de Let’s Encrypt plutôt qu’à un calendrier interne figé.

La réduction de durée limite l’exposition en cas de compromission d’une clé privée ou de changement non détecté dans le contrôle d’un nom de domaine. La réutilisation des validations de domaine doit aussi diminuer : votre serveur doit pouvoir refaire sa validation ACME sans intervention.

Choisissez la méthode de validation selon votre architecture. La validation HTTP-01 convient à un site accessible publiquement sur le port 80 ; le client place alors un fichier sous /.well-known/acme-challenge/, lisible depuis Internet.

La validation DNS-01 est nécessaire pour un certificat wildcard, tel que *.exemple.fr, ou lorsqu’aucun accès HTTP public n’est possible. Elle convient aux infrastructures dotées d’une API DNS, à condition de protéger le jeton API utilisé par le client.

Automatiser l’émission, le déploiement et le rechargement

Avec Nginx ou Apache, Certbot peut obtenir et installer un certificat ; les modes webroot et certonly séparent l’émission de la configuration du serveur web. Pour un site dont le répertoire web est /var/www/site, utilisez par exemple :

certbot certonly --webroot -w /var/www/site -d exemple.fr -d www.exemple.fr

Les certificats sont habituellement disponibles sous /etc/letsencrypt/live/nom-de-domaine/. Configurez le service avec fullchain.pem et privkey.pem, puis rechargez-le seulement après un renouvellement réussi.

certbot renew --dry-run
certbot renew --deploy-hook "systemctl reload nginx"

Le test --dry-run utilise l’environnement de préproduction de Let’s Encrypt et évite de consommer les limites de production. Vérifiez le déclencheur installé par votre distribution : un timer systemd ou une tâche planifiée est fréquent, mais ne doit pas être présumé.

Caddy gère nativement l’obtention et le renouvellement ACME lorsqu’un nom de domaine public est configuré. Dans Kubernetes, cert-manager peut renouveler les objets Certificate et mettre à jour les secrets des ingress compatibles ; vérifiez néanmoins que le proxy, l’ingress ou le service recharge bien la nouvelle clé.

Évitez les certificats copiés manuellement sur plusieurs machines. Un renouvellement peut réussir sur le serveur d’administration tandis qu’un répartiteur de charge, un nœud secondaire ou un serveur mail présente encore l’ancien fichier.

Surveiller le certificat exposé

Surveillez la date d’expiration exposée sur chaque port TLS public, et non la seule réussite d’un job Certbot ou d’un cron. Un job peut réussir parce qu’aucun certificat n’était encore à renouveler, alors que le certificat déployé reste ancien ou qu’un service ne l’a pas rechargé.

Inventoriez les noms de domaine, ports, serveurs et propriétaires de chaque certificat.
Définissez une alerte avant l’expiration avec un seuil compatible avec 45 jours, par exemple 15 jours ou davantage selon votre délai de correction.
Contrôlez les journaux du client ACME, les erreurs DNS et l’accessibilité HTTP-01 après toute modification de DNS, de pare-feu ou de proxy.
Documentez le renouvellement d’urgence et le rechargement des services concernés.

Uptime Kuma, Zabbix, Prometheus avec blackbox_exporter ou un service externe peuvent contrôler le certificat réellement présenté. La commande openssl s_client permet un contrôle ponctuel sur un serveur unique, mais ne remplace pas une alerte automatisée.