Skip to Content

Chapitre 8.2 — Certbot & Let’s Encrypt

⏱️ TL;DRLet’s Encrypt est une autorité de certification gratuite et entièrement automatisée : elle délivre des certificats reconnus par tous les navigateurs, sans paperasse, via un protocole nommé ACME. Ses certificats durent 90 jours — court exprès, pour forcer l’automatisation. Côté serveur, l’outil qui parle à Let’s Encrypt s’appelle Certbot. On l’installe (sudo apt install certbot python3-certbot-nginx), on vérifie deux prérequis (le DNS pointe déjà vers le VPS, le port 80 est ouvert), puis une seule commande fait tout : sudo certbot --nginx -d formacampus.fr -d www.formacampus.fr. Certbot prouve à Let’s Encrypt que tu contrôles bien le domaine (challenge HTTP-01), récupère le certificat, modifie ta config Nginx pour ajouter le bloc HTTPS sur le port 443, et propose de rediriger HTTP vers HTTPS. Les certificats vivent dans /etc/letsencrypt/live/. On teste toujours avec --dry-run avant, pour ne pas taper dans les rate limits.

🎯 Objectifs

  • Comprendre ce qu’apportent Let’s Encrypt et le protocole ACME, et pourquoi 90 jours.
  • Installer Certbot avec son greffon Nginx.
  • Vérifier les prérequis (DNS résolu, port 80 ouvert) avant de lancer quoi que ce soit.
  • Obtenir un certificat multi-domaines en une commande et comprendre ce que Certbot modifie.
  • Distinguer les challenges HTTP-01 et DNS-01.
  • Éviter les rate limits avec --dry-run.

Let’s Encrypt : la CA gratuite et automatisée

Avant Let’s Encrypt, obtenir un certificat voulait dire : payer une autorité, remplir des formulaires, prouver son identité par e-mail, télécharger des fichiers, les installer à la main, et recommencer chaque année. Let’s Encrypt a tout cassé : c’est une CA à but non lucratif qui délivre des certificats gratuits, reconnus partout, via une procédure 100 % automatisée.

Le secret, c’est un protocole standard nommé ACME (Automatic Certificate Management Environment) : un dialogue machine-à-machine entre ton serveur et Let’s Encrypt. Ton serveur demande un certificat, Let’s Encrypt lui pose un défi pour vérifier qu’il contrôle bien le domaine, ton serveur répond, et le certificat est émis — en quelques secondes, sans humain dans la boucle.

Point crucial : les certificats Let’s Encrypt sont valides 90 jours, pas un an. C’est volontaire :

  • Un cert à durée courte limite les dégâts si une clé fuit (fenêtre d’exposition réduite).
  • Surtout, 90 jours est trop court pour renouveler à la main sans oublier → ça force à automatiser. Et une fois l’automatisation en place, la durée n’a plus aucune importance : le renouvellement est un non-événement.

💡 Réflexe — Ne vois pas les 90 jours comme une contrainte, mais comme un garde-fou : ils t’obligent à faire les choses bien (automatiser) dès le départ, au lieu de repousser. On met le renouvellement auto en place au chapitre 8.3 — et ensuite, tu n’y penses plus jamais.

Certbot : l’outil qui parle à Let’s Encrypt

Certbot est le client ACME de référence, maintenu par l’EFF. C’est lui qui, sur ton serveur, dialogue avec Let’s Encrypt, obtient le certificat, et — avec son greffon Nginx — modifie ta config toute seule. Installons-le.

🐚 Au terminal — Installe Certbot et son greffon pour Nginx :

sudo apt update # python3-certbot-nginx est le greffon qui laisse Certbot editer la conf Nginx sudo apt install certbot python3-certbot-nginx

Le paquet certbot fournit l’outil de base ; python3-certbot-nginx ajoute le greffon Nginx, indispensable pour que Certbot lise ta config, y injecte le bloc HTTPS et recharge Nginx tout seul. Sans le greffon, tu devrais tout faire à la main.

📚 La doc — Certbot fournit un configurateur officiel très pratique : tu choisis « Nginx » et ton OS, et il te donne les commandes exactes pour ta version. La référence vit sur certbot.eff.org. En cas de doute sur une option, c’est là qu’il faut aller — les détails évoluent, les concepts restent.

Les prérequis : DNS et port 80

Certbot doit prouver à Let’s Encrypt que tu contrôles le domaine. La méthode par défaut (le challenge HTTP-01) consiste à déposer un fichier temporaire que Let’s Encrypt viendra lire via HTTP, sur le port 80, à l’adresse de ton domaine. Deux conditions doivent donc être remplies avant de lancer Certbot :

  1. Le DNS pointe déjà vers ton VPS. L’enregistrement A (et AAAA si tu as de l’IPv6) de formacampus.fr doit renvoyer l’IP publique de ton serveur. C’est le travail de la Partie 6. Si le DNS n’est pas encore propagé, Let’s Encrypt frappera à la mauvaise porte et le challenge échouera.
  2. Le port 80 est ouvert dans le pare-feu (UFW) et sert bien ton domaine dans Nginx. Let’s Encrypt vient lire son fichier de validation en HTTP — le port 80 doit être joignable de l’extérieur.

🐚 Au terminal — Vérifie les deux prérequis avant de lancer Certbot :

# 1. Le domaine resout-il vers l'IP de mon VPS dig +short formacampus.fr # doit afficher l'IP publique de ton serveur # 2. Le port 80 est-il ouvert dans UFW sudo ufw status # tu dois voir 80/tcp (ou Nginx Full) en ALLOW

⚠️ Piège — Lancer Certbot avant que le DNS soit propagé est la cause d’échec numéro un. Tu viens de créer l’enregistrement A il y a deux minutes ? Le monde entier ne le voit peut-être pas encore. Vérifie avec dig +short formacampus.fr depuis le serveur lui-même : tant que ça ne renvoie pas la bonne IP, ne lance pas Certbot — tu ne ferais que consommer tes tentatives (voir les rate limits plus bas).

Obtenir le certificat : une seule commande

Prérequis OK ? Une commande fait tout.

🐚 Au terminal — Obtiens et installe le certificat pour tes domaines :

sudo certbot --nginx -d formacampus.fr -d www.formacampus.fr

Décortiquons :

  • certbot : l’outil.
  • --nginx : utilise le greffon Nginx — Certbot va lire ta config, y ajouter le bloc HTTPS et recharger Nginx tout seul.
  • -d formacampus.fr -d www.formacampus.fr : les domaines à couvrir. L’option -d se répète pour chaque nom ; ils seront tous dans le même certificat. Ici on prend le domaine nu et son www.

Au premier lancement, Certbot te pose deux ou trois questions : ton e-mail (pour les alertes d’expiration et les avis importants), l’acceptation des conditions d’utilisation, et — le plus utile — s’il doit rediriger tout le HTTP vers HTTPS. Réponds oui à la redirection : c’est exactement ce qu’on veut (on y revient au chapitre 8.4).

Ce que Certbot fait pour toi, en coulisses :

  1. Génère une clé privée et une demande de certificat pour tes domaines.
  2. Prouve le contrôle du domaine via le challenge HTTP-01 (dépose un fichier que Let’s Encrypt vient lire sur le port 80).
  3. Récupère le certificat signé par Let’s Encrypt.
  4. Modifie ta config Nginx : ajoute un bloc server qui écoute en listen 443 ssl, avec les bons chemins de certificat, et (si tu as accepté) une redirection depuis le port 80.
  5. Teste et recharge Nginx. Si tout est bon, ton site répond désormais en HTTPS.

🔒 Sécurité — Certbot génère et stocke la clé privée de ton certificat dans /etc/letsencrypt/. Cette clé est le secret qui prouve ton identité : elle ne doit jamais être lisible par d’autres utilisateurs ni finir dans un dépôt git. Certbot pose les bonnes permissions (accessible à root uniquement). Ne déplace pas ces fichiers à la main et ne les rends jamais world-readable.

Où vivent les certificats

Après succès, tes certificats se trouvent sous /etc/letsencrypt/live/formacampus.fr/. Ce dossier contient des liens symboliques vers la version courante :

/etc/letsencrypt/live/formacampus.fr/ ├── fullchain.pem # ton certificat + la chaine intermediaire (a servir par Nginx) ├── privkey.pem # la cle privee (secrete, ne jamais exposer) ├── cert.pem # ton certificat seul └── chain.pem # la chaine intermediaire seule

Dans la config Nginx écrite par Certbot, tu retrouveras deux directives clés qui pointent vers ces fichiers :

server { listen 443 ssl; server_name formacampus.fr www.formacampus.fr; ssl_certificate /etc/letsencrypt/live/formacampus.fr/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/formacampus.fr/privkey.pem; # ... ton bloc location / { proxy_pass ... } de la Partie 7 ... }

ssl_certificate pointe vers fullchain.pem (le certificat avec sa chaîne intermédiaire — c’est ce qui évite le piège de la chaîne incomplète vu au chapitre 8.1), et ssl_certificate_key vers la clé privée. Certbot écrit ces lignes tout seul ; tu n’as rien à taper ici, mais tu dois savoir les lire pour déboguer.

💡 Réflexe — Ne modifie jamais les fichiers dans /etc/letsencrypt/live/ ni ne les copie ailleurs. Ce sont des liens symboliques que Certbot fait pointer vers la version à jour à chaque renouvellement. Si tu copies fullchain.pem ailleurs « pour être tranquille », ta copie ne sera pas renouvelée et expirera dans 90 jours. Réfère-toi toujours au chemin /etc/letsencrypt/live/....

Vérifier dans le navigateur

Une fois Certbot terminé, ouvre https://formacampus.fr : le cadenas doit être fermé. Clique dessus → « Certificat valide », émis par Let’s Encrypt, pour ton domaine. En ligne de commande, tu peux aussi vérifier :

# affiche l'en-tete et confirme la connexion TLS curl -I https://formacampus.fr

HTTP-01 vs DNS-01 : les deux façons de prouver

Let’s Encrypt doit vérifier que tu contrôles le domaine. Il existe deux challenges principaux :

ChallengeComment ça marcheQuand l’utiliser
HTTP-01Certbot dépose un fichier que Let’s Encrypt lit via HTTP sur le port 80Le cas par défaut : un domaine précis, port 80 joignable
DNS-01Certbot (ou toi) crée un enregistrement TXT dans le DNS que Let’s Encrypt vérifieCertificats wildcard, ou quand le port 80 n’est pas exposé

HTTP-01 est le plus simple et celui qu’utilise --nginx par défaut : rien à faire, Certbot gère le dépôt du fichier. Sa contrainte : le port 80 doit être joignable depuis Internet.

DNS-01 prouve le contrôle du domaine en créant un enregistrement TXT spécifique dans ta zone DNS. Il est indispensable pour obtenir un certificat wildcard (du type *.formacampus.fr, qui couvre tous les sous-domaines d’un coup) — on y reviendra au chapitre 8.4. Son inconvénient : il faut pouvoir automatiser la création de l’enregistrement TXT (via l’API de ton hébergeur DNS), sinon le renouvellement redevient manuel.

🧭 Sur FormaCampus — L’équipe couvre trois noms. Pour le front, une commande : sudo certbot --nginx -d formacampus.fr -d www.formacampus.fr. Pour l’API, une seconde : sudo certbot --nginx -d api.formacampus.fr (chaque server block Nginx a son certificat). Trois sous-domaines connus d’avance → HTTP-01 suffit largement, pas besoin de wildcard ni de DNS-01. Le tout en HTTPS, gratuit, en deux minutes. Le jour où FormaCampus ouvrira un sous-domaine par client (clientX.formacampus.fr), là on passera au wildcard via DNS-01.

Ne pas se faire bannir : les rate limits

Let’s Encrypt est gratuit, mais pas illimité : il impose des rate limits pour éviter les abus (par exemple, un nombre maximum de certificats par domaine sur une fenêtre glissante). En usage normal, tu ne les atteindras jamais. Mais si tu débogues en relançant Certbot dix fois de suite sur le vrai service, tu peux te faire temporairement bloquer — et te retrouver coincé sans pouvoir émettre de certificat.

La parade : l’option --dry-run, qui exécute toute la procédure contre l’environnement de test de Let’s Encrypt (le staging), sans émettre de vrai certificat ni consommer de quota.

🐚 Au terminal — Teste la procédure sans consommer de quota :

# simule l'emission sans delivrer de vrai certificat sudo certbot --nginx -d formacampus.fr -d www.formacampus.fr --dry-run

⚠️ Piège — Déboguer une config récalcitrante en relançant certbot encore et encore sur la vraie CA est le meilleur moyen de taper dans les rate limits et de se bloquer pour plusieurs heures. Dès que tu tâtonnes, passe en --dry-run : autant d’essais que tu veux, zéro quota consommé. Tu ne repasses en réel qu’une fois que le dry-run passe.

✏️ Exercices

Exercice 1 — Prépare le terrain. Tu viens de louer un VPS et d’y installer Nginx qui sert formacampus.fr en HTTP. Avant de lancer Certbot, quels deux prérequis dois-tu vérifier, et avec quelles commandes ?

✅ Solution

(1) Le DNS doit pointer vers l’IP du VPS : dig +short formacampus.fr doit renvoyer l’IP publique du serveur. (2) Le port 80 doit être ouvert et joignable (challenge HTTP-01) : sudo ufw status doit montrer 80/tcp (ou Nginx Full) en ALLOW. Sans ces deux conditions, Let’s Encrypt ne pourra pas valider le domaine et Certbot échouera.

Exercice 2 — Lis la commande. Explique ce que fait chaque partie de : sudo certbot --nginx -d formacampus.fr -d www.formacampus.fr. Et où atterriront les fichiers du certificat ?

✅ Solution

certbot est l’outil ; --nginx active le greffon qui modifie la config Nginx et la recharge ; -d formacampus.fr -d www.formacampus.fr liste les deux domaines à couvrir dans le même certificat (l’option -d se répète). Les fichiers atterrissent dans /etc/letsencrypt/live/formacampus.fr/ — notamment fullchain.pem (certificat + chaîne) et privkey.pem (clé privée). On ne modifie ni ne copie jamais ces fichiers à la main.

Exercice 3 — Wildcard ou pas ? FormaCampus veut un certificat qui couvre formacampus.fr, www. et api.. Un développeur propose un certificat wildcard *.formacampus.fr. Est-ce nécessaire ? Quel challenge imposerait-il ?

✅ Solution

Pas nécessaire : trois noms connus d’avance se couvrent très bien avec des -d explicites (ou un -d par server block) via le challenge HTTP-01, plus simple. Un wildcard *.formacampus.fr n’a de sens que pour couvrir un nombre inconnu/variable de sous-domaines (ex. un par client). Et il impose le challenge DNS-01 (création d’un enregistrement TXT), que Let’s Encrypt exige pour tout wildcard — donc plus de mise en place. On garde le simple tant qu’on n’a pas besoin du wildcard.

🧠 Quiz de révision

1. Qu’est-ce que Let’s Encrypt, et qu’est-ce qu’ACME ?

Let’s Encrypt est une autorité de certification gratuite et automatisée, reconnue par tous les navigateurs. ACME est le protocole standard par lequel ton serveur dialogue avec elle pour prouver le contrôle du domaine et obtenir un certificat, sans intervention humaine.

2. Pourquoi les certificats Let’s Encrypt ne durent-ils que 90 jours ?

C’est volontaire : une durée courte limite l’exposition en cas de fuite de clé, et surtout force l’automatisation du renouvellement (trop court pour le faire à la main sans oublier). Une fois le renouvellement auto en place, la durée n’a plus d’importance.

3. À quoi sert le greffon python3-certbot-nginx ?

Il permet à Certbot de lire et modifier la configuration Nginx tout seul : ajouter le bloc listen 443 ssl, pointer vers les bons certificats, poser la redirection HTTP→HTTPS, puis tester et recharger Nginx. Sans lui, il faudrait éditer la config à la main.

4. Quelle est la différence entre les challenges HTTP-01 et DNS-01 ?

HTTP-01 prouve le contrôle du domaine en déposant un fichier que Let’s Encrypt lit via HTTP sur le port 80 (le défaut, simple). DNS-01 le prouve via un enregistrement TXT dans la zone DNS ; il est obligatoire pour les certificats wildcard et utile quand le port 80 n’est pas exposé.

5. À quoi sert --dry-run et quand l’utiliser ?

Il exécute toute la procédure contre l’environnement de test de Let’s Encrypt, sans émettre de vrai certificat ni consommer de quota. On l’utilise pour déboguer une config sans risquer les rate limits, et pour tester le renouvellement. On ne repasse en réel qu’une fois le dry-run réussi.


Chapitre suivant : Renouvellement auto — pour que ce certificat de 90 jours ne t’oblige plus jamais à intervenir.

Last updated on