Let's Encrypt a arrêté ses emails d'expiration : que faire ?

Ce qui change exactement

Pendant près de dix ans, Let's Encrypt envoyait un email d'alerte à 20 jours, 10 jours et 1 jour avant l'expiration d'un certificat — à condition que vous ayez fourni une adresse email lors de l'émission. Cette pratique servait de filet de sécurité pour des millions d'administrateurs qui découvraient ainsi un renouvellement automatique cassé, une rotation de clé ratée ou simplement un oubli humain.

Depuis le 4 juin 2025, ces emails ont définitivement cessé. Aucune notification, aucune relance — le certificat expire en silence, et c'est votre serveur qui paie la note quelques heures plus tard, quand le premier navigateur affiche un avertissement de sécurité plein écran.

Pourquoi Let's Encrypt a-t-elle fait ce choix ?

Dans son annonce officielle de janvier 2025, l'ISRG — l'organisation qui opère Let's Encrypt — a avancé trois raisons cohérentes :

• Le coût de l'infrastructure email. Avec plus de 500 millions de certificats émis chaque année, envoyer 3 alertes par certificat représente un volume mensuel considérable, et un budget non négligeable pour un organisme à but non lucratif.
• La protection de la vie privée. Conserver une base de millions d'adresses email constitue un risque de fuite. En supprimant cette donnée, Let's Encrypt réduit sa surface d'exposition et son périmètre RGPD.
• La maturité de l'écosystème. ACME, certbot, acme.sh et les services de monitoring tiers sont aujourd'hui largement déployés. L'ISRG considère que le rôle de notification n'est plus le sien.

Le raisonnement est défendable. Le problème, c'est qu'il repose sur une hypothèse optimiste : que tout le monde a mis en place une supervision robuste de son côté. La réalité du terrain en agence est… nettement plus contrastée.

Le vrai risque : l'automatisation silencieuse qui casse

« J'ai certbot installé, je ne risque rien. » C'est ce qu'on entend le plus souvent. Sauf que la cron de renouvellement peut échouer pour une bonne dizaine de raisons qui n'ont rien d'exceptionnel :

• Un fichier de challenge HTTP-01 dont le chemin a changé après une mise à jour du CMS.
• Un enregistrement DNS modifié qui casse la validation DNS-01.
• Un pare-feu trop strict qui bloque l'accès depuis les validators de Let's Encrypt.
• Un disque plein qui empêche d'écrire le nouveau certificat.
• Un service nginx ou Apache qui ne recharge pas après le renouvellement.
• Une rotation de clés serveur qui invalide la configuration ACME.
• Un changement de propriétaire de domaine sans transfert du compte ACME.

Avant juin 2025, l'email de Let's Encrypt vous rattrapait à coup sûr 20 jours avant la catastrophe. Aujourd'hui, il n'y a plus de garde-fou. Si rien n'est en place côté monitoring, vous découvrirez le problème en même temps que les visiteurs de votre site.

Les deux remparts à mettre en place

La parade n'est pas une mais deux. L'automatisation et le monitoring sont complémentaires, pas alternatifs. L'un renouvelle, l'autre vérifie que le renouvellement a bien eu lieu.

1. Automatiser le renouvellement avec ACME

Certbot, acme.sh, lego, Caddy : tous ces clients ACME renouvellent automatiquement vos certificats Let's Encrypt tous les 60 jours environ. C'est la base, et la plupart des hébergeurs modernes l'ont activé par défaut. Si ce n'est pas encore le cas chez vous, c'est la première chose à faire.

2. Surveiller l'état réel des certificats

C'est ici que se joue la vraie différence depuis 2025. Une automatisation n'est utile que si quelqu'un — humain ou système — vérifie qu'elle fonctionne. Le monitoring SSL consiste à interroger chaque jour vos domaines en TLS et à alerter si la date d'expiration s'approche ou si la chaîne casse.

Vous pouvez monter ça en interne avec un script cron, un endpoint Nagios ou une vérification Prometheus. Mais pour gérer plusieurs sites clients, un service dédié vous fait gagner énormément de temps — c'est précisément le rôle de CertWatch.

Aller plus loin : checklist de mise en sécurité

Si vous voulez vérifier votre exposition en 10 minutes :

1. Listez tous les domaines dont vous êtes responsable, y compris les sous-domaines. Le simple inventaire révèle souvent des oublis.
2. Vérifiez la date d'expiration de chacun avec notre outil gratuit de date d'expiration SSL. Vous identifierez en quelques minutes les certificats qui expirent dans moins de 30 jours.
3. Confirmez le renouvellement automatique sur chaque serveur. Cherchez le cron certbot, le service systemd ou la configuration de votre hébergeur.
4. Mettez en place un monitoring quotidien — manuellement, via un outil interne, ou via CertWatch. L'essentiel est de vérifier l'état réel, pas seulement de faire confiance à l'automatisation.
5. Documentez la procédure de réémission manuelle pour chaque hébergement. Le jour où ça casse, ce n'est pas le moment de chercher la commande.

Questions fréquentes