Chapitre 8.3 — Renouvellement automatique

⏱️ TL;DR — Un certificat Let’s Encrypt expire en 90 jours. Si tu le renouvelles à la main, tu oublieras — et le jour où il expire, tout le site tombe en erreur de sécurité pour tous les visiteurs. La solution n’est pas la discipline, c’est l’automatisation. Bonne nouvelle : Certbot l’installe tout seul à l’installation, via un timer systemd (certbot.timer) qui tourne deux fois par jour et renouvelle les certificats qui approchent de l’expiration. Ton seul travail : vérifier que le mécanisme est là (systemctl list-timers) et le tester avec sudo certbot renew --dry-run — le geste qui te garantit que tu ne te réveilleras pas un matin avec un site cassé. Un dernier réflexe : s’assurer que Nginx est rechargé après renouvellement (--deploy-hook) pour qu’il serve le nouveau certificat. Le piège mortel : un renew qui échoue en silence (port 80 fermé, DNS cassé) → cert expiré → site en carafe. D’où le monitoring de l’expiration (Partie 14).

🎯 Objectifs

• Comprendre pourquoi le renouvellement automatique est non négociable.
• Vérifier que Certbot a bien installé son mécanisme de renouvellement (timer systemd).
• Tester le renouvellement à blanc avec certbot renew --dry-run.
• Garantir que Nginx recharge le nouveau certificat après renouvellement.
• Reconnaître un renew qui échoue en silence et savoir s’en prémunir (monitoring).

Pourquoi c’est vital

Répétons-le, parce que c’est le cœur du chapitre : un certificat Let’s Encrypt vit 90 jours. Passé ce délai, s’il n’est pas renouvelé, chaque visiteur de formacampus.fr tombe sur un écran d’avertissement rouge « Votre connexion n’est pas privée / certificat expiré ». Le site devient inutilisable — pas lent, pas dégradé : bloqué, pour tout le monde, jusqu’à ce que tu réagisses.

Compter sur ta mémoire pour renouveler tous les 90 jours est une stratégie perdante. Tu seras en vacances, en plein sprint, ou tu auras simplement oublié. La seule réponse fiable est l’automatisation : une machine qui renouvelle à ta place, régulièrement, sans jamais oublier.

⚠️ Piège — « Je le renouvellerai à la main, je mettrai un rappel. » Non. Le certificat expiré est l’une des pannes les plus fréquentes et les plus embarrassantes en production — un site entier par terre pour un fichier périmé qu’on aurait pu renouveler tout seul. C’est exactement le genre de tâche qu’une machine fait mieux qu’un humain : automatise-la et n’y pense plus.

Certbot l’a déjà fait pour toi

Voici la bonne surprise : sur un système moderne (Ubuntu/Debian avec systemd), le paquet Certbot installe automatiquement un mécanisme de renouvellement dès son installation. Tu n’as, en théorie, rien à mettre en place — juste à vérifier que c’est bien là.

Ce mécanisme prend la forme d’un timer systemd : certbot.timer. Un timer systemd, c’est l’équivalent moderne d’un cron — il déclenche un service (certbot.service) à intervalle régulier, en général deux fois par jour. À chaque déclenchement, Certbot regarde tous tes certificats et ne renouvelle que ceux qui approchent de l’expiration (typiquement à moins de 30 jours). Les autres, il les laisse tranquilles. Faire tourner ça deux fois par jour n’a rien d’excessif : c’est ce qui garantit qu’un certificat sera renouvelé bien avant son échéance, même si une tentative échoue.

🐚 Au terminal — Vérifie que le timer de renouvellement est bien actif :

# liste les timers systemd et cherche certbot
systemctl list-timers
 
# ou, ciblé sur le timer Certbot
systemctl status certbot.timer

Tu dois voir certbot.timer actif (active), avec une prochaine échéance planifiée. S’il est là, ton renouvellement est déjà en place.

📚 La doc — Selon les distributions, le renouvellement peut passer par un timer systemd (le cas courant aujourd’hui sur Ubuntu/Debian) ou par une entrée cron dans /etc/cron.d/certbot. Les deux font la même chose : appeler certbot renew régulièrement. La doc Certbot (certbot.eff.org) décrit le mécanisme exact selon ton installation. Ne cherche pas à en installer un deuxième par-dessus : tu créerais des doublons.

Le geste qui rassure : renew --dry-run

Savoir que le timer existe, c’est bien. Savoir qu’il fonctionnera vraiment le jour J, c’est mieux. Le test décisif : simuler un renouvellement maintenant, sans rien émettre pour de vrai.

🐚 Au terminal — Teste le renouvellement à blanc :

# simule le renouvellement de tous les certificats, contre le staging Let's Encrypt
sudo certbot renew --dry-run

certbot renew est la commande que le timer lance automatiquement : elle passe en revue tous tes certificats et renouvelle ceux qui en ont besoin. L’ajout de --dry-run fait tourner toute la procédure contre l’environnement de test de Let’s Encrypt — donc sans délivrer de vrai certificat, sans consommer de quota, mais en exerçant exactement le même chemin (challenge inclus). Si le dry-run se termine par un succès pour chaque domaine, tu as la preuve que le renouvellement réel fonctionnera. C’est le geste à faire juste après la première émission, pour dormir tranquille.

💡 Réflexe — Fais certbot renew --dry-run une fois juste après avoir obtenu ton premier certificat, puis de nouveau chaque fois que tu touches à la config Nginx ou au pare-feu. Une modif anodine (renommer un server block, fermer un port « inutile ») peut casser le renouvellement silencieusement — le dry-run le révèle avant que le vrai renew échoue trois semaines plus tard.

Recharger Nginx après renouvellement

Subtilité importante : quand Certbot renouvelle un certificat, il écrit de nouveaux fichiers dans /etc/letsencrypt/live/. Mais Nginx a chargé l’ancien certificat en mémoire au démarrage. Tant que Nginx n’est pas rechargé, il continue de servir l’ancien certificat — celui qui va expirer. Il faut donc recharger Nginx après chaque renouvellement.

Dans la grande majorité des cas, Certbot s’en occupe déjà : le greffon --nginx installe un hook de rechargement qui recharge Nginx automatiquement après un renouvellement réussi. Tu n’as souvent rien à faire. Mais il faut connaître ce mécanisme pour vérifier qu’il est en place, ou l’ajouter si besoin.

Le mécanisme s’appelle un hook de déploiement (--deploy-hook) : une commande que Certbot exécute seulement après un renouvellement réussi. Pour recharger Nginx, la commande est systemctl reload nginx (un reload, pas un restart : Nginx recharge sa config sans couper les connexions en cours).

🐚 Au terminal — Si tu dois définir explicitement le hook de rechargement lors d’une émission :

# recharge Nginx apres chaque renouvellement reussi
sudo certbot --nginx -d formacampus.fr -d www.formacampus.fr \
  --deploy-hook "systemctl reload nginx"

L’option --deploy-hook "systemctl reload nginx" dit à Certbot : « après un renew réussi, exécute systemctl reload nginx ». Ainsi, Nginx sert immédiatement le nouveau certificat. Le hook est enregistré avec le certificat, donc il se rejouera à chaque renouvellement automatique — pas besoin de le redonner.

🔒 Sécurité — Utilise reload et non restart. Un restart coupe brièvement Nginx (les requêtes en cours tombent) ; un reload recharge la config en douceur, sans interruption de service. Pour un simple changement de certificat, reload suffit toujours — inutile d’infliger une micro-coupure à tes visiteurs.

Quand le renew échoue en silence

Voici le scénario cauchemar, et il est plus fréquent qu’on ne croit. Le timer tourne, Certbot tente de renouveler… mais échoue. Pas de crash bruyant, pas d’alerte à l’écran : juste une erreur dans un log que personne ne regarde. Le certificat continue de vieillir, atteint 0 jour, expire — et là seulement tu découvres le problème, quand le site tombe et que les utilisateurs se plaignent.

Les causes classiques d’un renew qui échoue :

• Le port 80 a été fermé. Quelqu’un a « durci » le pare-feu en fermant le port 80 (« on est en HTTPS maintenant, plus besoin du 80 »). Mais le challenge HTTP-01 du renouvellement passe par le port 80 → le renew échoue. Garde le port 80 ouvert.
• Le DNS a changé ou cassé. Le domaine ne pointe plus vers le bon serveur (migration, erreur de zone) → Let’s Encrypt ne peut plus valider → échec.
• Un changement de config Nginx a cassé le chemin de validation ou renommé un server block.
• L’espace disque plein, un blocage réseau, etc.

Le point commun : l’échec est silencieux. D’où deux protections.

D’abord, l’e-mail que tu as donné à Certbot : Let’s Encrypt prévient par mail quand un certificat approche de l’expiration sans avoir été renouvelé. C’est un filet de sécurité — mais un mail peut se perdre dans les spams.

Ensuite, et surtout, le monitoring de l’expiration : un outil qui surveille activement la date d’expiration de ton certificat et t’alerte bien avant l’échéance (par exemple à J-14). C’est le seul vrai garde-fou : il ne dépend pas de la réussite silencieuse d’un cron. On met ça en place en Partie 14.

⚠️ Piège — Le grand classique : fermer le port 80 « puisqu’on est passé en HTTPS ». Trois semaines plus tard, le renouvellement automatique tente son challenge HTTP-01 sur le port 80… fermé → échec silencieux → dans quelques semaines, cert expiré → site par terre. La redirection HTTP→HTTPS a besoin que le port 80 réponde (pour rediriger) et le renew en a besoin (pour valider). Ne ferme jamais le port 80.

💡 Réflexe — Ne considère pas le renouvellement comme « réglé » juste parce que tu l’as configuré. Considère-le réglé quand tu es alerté s’il échoue. Configuration plus surveillance : c’est la combinaison qui te protège vraiment. La config seule peut échouer en silence ; c’est le monitoring qui transforme un échec muet en alerte visible.

🧭 Sur FormaCampus — Après avoir émis ses trois certificats (front www, apex, api), l’équipe fait le tour du propriétaire : systemctl list-timers confirme que certbot.timer est actif, puis sudo certbot renew --dry-run passe au vert pour les trois domaines. Elle ajoute une sonde dans son Uptime Kuma (Partie 14) qui surveille l’expiration du certificat de formacampus.fr et alerte l’équipe 14 jours avant. Résultat : le renouvellement se fait tout seul, et si un jour il échoue (un dev zélé ferme le port 80…), l’alerte tombe deux semaines avant la panne, pas le jour où le site s’écroule. Le renew auto testé est coché sur leur checklist de mise en prod.

✏️ Exercices

Exercice 1 — Prouve que ça marchera. Tu viens d’obtenir un certificat pour formacampus.fr. Quelles deux commandes lances-tu pour t’assurer que le renouvellement automatique est (a) en place et (b) fonctionnel ?

Exercice 2 — Le site tombe un matin. Un lundi, formacampus.fr renvoie une erreur de certificat expiré pour tous les visiteurs. Le certificat avait pourtant été « configuré pour se renouveler tout seul » il y a deux mois. Quelle est la cause la plus probable, et comment aurait-on pu l’éviter ?

Exercice 3 — Le nouveau cert n’est pas servi. Le renouvellement a réussi (nouveaux fichiers dans /etc/letsencrypt/live/), mais le navigateur montre toujours l’ancien certificat, proche de l’expiration. Que s’est-il passé et quelle est la correction ?

🧠 Quiz de révision

Chapitre suivant : TLS moderne & HSTS — maintenant que le certificat est là et se renouvelle, durcissons la configuration pour viser un A+.