Ajouter un renouvellement automatique aux certificats cerbot

Afin d’avoir un site securisé en HTTPS, a savoir HTTP avec une couche TLS, il y’a un peu de configuration à faire.
Cependant, le renouvellement des certificats n’étant pas automatique, nous allons nous pencher sur une crontab qui permettra leur renouvellement journalier.

La durée des certificats let’s encrypt est variable. Lorsque je suis passé en HTTPS, il s’agissait de 3 mois.
Par chance, 19 jours avant la date de renouvellement, j’ai reçu un petit mail m’informant qu’il fallait renouveler mes certificats.

Je vais détailler ici la marche à suivre, mais également aller plus loin en utilisant une cron tab, ce planificateur de tache intégré à Linux.

D’abord, éteindre le feu

Avant toute chose, on va déjà renouveler le certificat. Je ne sais pas pour vous, mais moi j’ai tendance à oublier et ensuite me retrouver devant le fait accompli.

Dirigez vous vers l’emplacement de votre docker-compose.yml

cd /chemin/vers/docker-compose.yml

Puis ensuite lancer la commande

docker-compose run certbot renew

cela devrait renouveler vos certificats.

Une automatisation pour les têtes en l’air.

Ce que je martèle à mes usagers, c’est que je fais de l’informatique parce que je n’ai pas envie d’avoir à retenir des choses. Et retenir des dates d’expirations de certificats sont loin dans la liste de mes préoccupations journalières.

Une tâche Cron va nous permettre de faire la demande de renouvellement de certificat tout les jours à 2heures du matin

Tout d’abord, éditer la crontab

crontab -e //avec e pour edit

Pour voir les taches existantes

crontab -l //avec l pour list pour verifier les cron existantes

Puis vous arrivez sur cet écran, et vous ajouter votre crontab à la fin du fichier

0 2 * * * docker-compose -f /chemin/vers/ton/docker-compose.yml run certbot renew && docker-compose -f /chemin/vers/ton/docker-compose.yml exec nginx-proxy nginx -s reload

et c’est tout bon.

Mais… ca marche comment les crontab?

En gros, ca va nous permettre d’organiser les moment ou l’on va vouloir déclencher un script.

Minute (0 – 59)
Heure (0 – 23)
Jour du mois (1 – 31)
Mois (1 – 12)
Jour de la semaine (0 – 7) (où 0 et 7 représentent le dimanche)

En gros, ce n’est pas forcement pertinent de lancer une sauvegarde en pleine journée quand tout le monde bosse, parce que ça va prendre pas mal de ressources et ralentir l’infrastructure en place.

C’est également plus simple par la suite avec des horaires précis de savoir quelle tache à pu échouer c’est une simplicité pour debugger.

Exemple pratique

Exemple Pratique

Imaginons que tu aies trois tâches :

1. Sauvegarde de la base de données (qui peut être intensive en E/S)
2. Mise à jour du système (qui nécessite souvent un redémarrage et peut monopoliser les ressources)
3. Envoi d’emails aux utilisateurs (qui nécessite une connexion réseau)

Si toutes ces tâches s’exécutent en même temps, tu risques de rencontrer des problèmes comme une lenteur excessive, des échecs de connexion pour l’envoi d’emails, ou même des erreurs de sauvegarde.