Module 7 · 7.3
Français
https avec Let's Encrypt
Module 7: Domaine, serveur web et https · Temps de lecture : 12 minutes
Objectif pédagogique : À l'issue de cette leçon, vous saurez obtenir avec certbot un certificat gratuit de Let's Encrypt pour nginx, rediriger http vers https, contrôler le renouvellement automatique et résoudre les erreurs les plus fréquentes lors d'une demande.
Notions clés : certificat, autorité de certification (CA), ACME, Let's Encrypt, validation de domaine, HTTP-01, DNS-01, TLS-ALPN-01, certbot, renouvellement, certbot renew --dry-run, durée de validité, ARI, rate limits, staging, CAA, redirection vers https
Pourquoi https, et ce que prouve un certificat
Sans https, tout ce qui circule entre le navigateur et le serveur passe en clair sur le réseau : mots de passe, formulaires, cookies. N'importe qui sur le trajet (un wifi public, un routeur piraté) peut lire ou modifier ces données. C'est pourquoi les navigateurs signalent les sites http comme « non sécurisés », et certaines fonctions ne marchent qu'en https. Pour un coffre-fort comme Vaultwarden (leçon 9.4), https est même obligatoire.
https utilise TLS, et pour cela votre serveur a besoin d'un certificat : une preuve, signée par une autorité de certification (CA) à laquelle les navigateurs font confiance, que cette clé appartient à ce nom. Un certificat ordinaire prouve uniquement que le demandeur contrôle le nom de domaine (validation de domaine). Il ne dit rien de votre identité ni de votre fiabilité.
Let's Encrypt est une CA gratuite qui délivre uniquement des certificats à validation de domaine, de façon entièrement automatique via le protocole ACME. Un programme sur votre serveur (le client ACME) demande le certificat, prouve qu'il contrôle le nom, l'installe et le renouvelle à temps. Cette leçon utilise certbot, le client de l'EFF. Caddy (leçon 7.4) intègre son propre client ACME.
Comment prouver que vous contrôlez le nom ?
Let's Encrypt connaît trois types de défis (challenges) :
| Défi | Comment | Port | Wildcard (*.example.com) |
|---|---|---|---|
| HTTP-01 | déposer un fichier sous http://<naam>/.well-known/acme-challenge/ | 80 | non |
| DNS-01 | créer un enregistrement TXT _acme-challenge.<naam> | aucun | oui |
| TLS-ALPN-01 | présenter un certificat spécial pendant la négociation TLS | 443 | non |
Pour un VPS ordinaire avec un site web, HTTP-01 est le plus simple. Il faut pour cela que :
- le nom pointe vers votre serveur avec un enregistrement A (et AAAA) (leçon 7.1) ;
- le port 80 soit ouvert au monde entier, même si votre site n'utilise par ailleurs que https. Let's Encrypt valide uniquement via le port 80 et depuis plusieurs emplacements sur Internet ; vous ne pouvez pas inscrire ces adresses dans votre pare-feu ;
- votre serveur réponde de la même façon en IPv4 et en IPv6. Si le nom possède un enregistrement AAAA, Let's Encrypt essaie d'abord IPv6. Ce n'est que si IPv6 ne donne aucune connexion qu'il se rabat sur IPv4.
Vous avez besoin de DNS-01 pour un certificat wildcard, ou si le serveur n'est pas joignable depuis l'extérieur. Le client ACME doit alors pouvoir modifier votre DNS, généralement via une clé d'API de votre fournisseur DNS. Cette clé permet de modifier tout votre DNS : conservez-la avec autant de soin qu'un mot de passe.
Installer certbot
Les créateurs de certbot recommandent le snap, car il contient toujours la version la plus récente. Sur Debian et Ubuntu, vous pouvez aussi l'installer simplement depuis les dépôts :
anna@web1:~$ sudo apt install certbot python3-certbot-nginxLa version de la distribution est plus ancienne, mais reçoit les mises à jour de sécurité via apt (leçons 4.1 et 4.2), ce qui s'accorde avec le reste de cette formation. Choisissez l'une des deux, pas les deux : deux installations se gênent mutuellement lors du renouvellement.
Demander un certificat
Avec le site de la leçon 7.2 déjà fonctionnel sur le port 80 :
anna@web1:~$ sudo certbot --nginx -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address or hit Enter to skip.
(Enter 'c' to cancel):
...
Requesting a certificate for example.com and www.example.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2027-02-07.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for example.com to /etc/nginx/sites-enabled/example.com
Successfully deployed certificate for www.example.com to /etc/nginx/sites-enabled/example.com
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com(La date et les détails sont donnés à titre d'exemple.) Le plug-in --nginx fait trois choses : il prépare temporairement le défi, récupère le certificat et adapte votre server block avec un bloc listen 443 ssl et une redirection de http vers https. Si vous préférez le faire vous-même, utilisez certbot certonly --nginx et ajoutez les lignes vous-même à votre configuration.
Quelques points d'attention :
- Demandez en une seule fois tous les noms qui appartiennent au site (
-dpar nom). Chaque nom doit pointer vers le serveur, sinon toute la demande échoue. - La clé privée (
privkey.pem) se trouve dans/etc/letsencrypt/live/et n'est lisible que par root. Ne la copiez pas ailleurs et ne la placez jamais dans une sauvegarde lisible par d'autres. - L'adresse e-mail est facultative. Depuis juin 2025, Let's Encrypt n'envoie plus d'e-mails lorsqu'un certificat arrive à expiration. C'est donc à vous de surveiller que le renouvellement réussit (leçon 8.3).
Rediriger http vers https
Après certbot, votre configuration ressemble à peu près à ceci (version nettoyée ; certbot ajoute lui-même des commentaires # managed by Certbot et parfois des lignes if) :
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
root /var/www/example.com;
...
}Le premier bloc redirige tout ce qui arrive en http vers le même nom et le même chemin en https, avec une redirection permanente (301). Le fichier de défi pour le renouvellement fonctionne toujours : Let's Encrypt suit cette redirection. Le second bloc est le vrai site. Si vous souhaitez aussi rediriger www vers le nom nu (ou l'inverse), faites-le dans un bloc distinct, afin que les visiteurs voient un seul nom fixe.
Renouvellement : automatique, et à contrôler
Un certificat Let's Encrypt est actuellement valable 90 jours. Cette durée va diminuer : Let's Encrypt a annoncé que le profil par défaut délivrera des certificats de 64 jours à partir du 10 février 2027 et de 45 jours à partir du 16 février 2028. Le renouvellement manuel n'est donc pas une option ; il doit être automatique.
Lors de l'installation, certbot met en place un timer systemd (ou une ligne cron) qui vérifie deux fois par jour si un certificat doit être renouvelé. Vérifiez qu'il est bien là, et testez le renouvellement avec une demande d'essai :
anna@web1:~$ systemctl list-timers 'certbot*'
NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2026-11-09 22:41:00 CET 9h left - - certbot.timer certbot.service
anna@web1:~$ sudo certbot renew --dry-run
...
Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/example.com/fullchain.pem (success)Après le renouvellement, nginx doit aussi charger le nouveau certificat. Avec le plug-in nginx, certbot s'en charge lui-même ; si vous utilisez certonly, mettez en place un deploy hook qui recharge nginx, par exemple un script exécutable dans /etc/letsencrypt/renewal-hooks/deploy/ contenant systemctl reload nginx.
Les bons clients ACME utilisent ARI (ACME Renewal Information) : Let's Encrypt indique alors lui-même quand un certificat doit être renouvelé, par exemple plus tôt en cas de problème avec une série de certificats. Maintenez donc votre client à jour.
Quand une demande échoue
| Message (abrégé) | Cause | Solution |
|---|---|---|
Timeout during connect (likely firewall problem) | port 80 fermé, ou le nom pointe vers une autre adresse | pare-feu (leçon 5.2), A/AAAA (leçon 7.1) |
Invalid response from http://.../.well-known/acme-challenge/...: 404 | un autre serveur ou un autre server block répond, souvent via IPv6 | listen [::]:80, vérifier l'enregistrement AAAA |
CAA record for example.com prevents issuance | un enregistrement CAA n'autorise qu'une autre autorité | adapter le CAA (leçon 7.1) |
too many certificates already issued | une rate limit | attendre ; tester avec staging |
Let's Encrypt applique des rate limits (limites de fréquence) pour empêcher les abus. Les principales : au maximum 50 nouveaux certificats par domaine enregistré sur 7 jours, au maximum 5 certificats pour exactement le même ensemble de noms sur 7 jours, et au maximum 5 validations échouées par nom et par heure. Si vous faites des essais en redemandant sans cesse, vous les atteindrez vite. Testez donc avec l'environnement de staging, dont les limites sont beaucoup plus larges mais qui délivre des certificats auxquels les navigateurs ne font pas confiance :
anna@web1:~$ sudo certbot certonly --nginx --staging -d test.example.comSi cela fonctionne, demandez ensuite le vrai certificat.
Sur AlmaLinux et Rocky Linux
certbot y provient d'EPEL (dnf install certbot python3-certbot-nginx) ou du snap. Le plug-in et les commandes sont identiques. Pensez à firewalld (--add-service=http --add-service=https) et à SELinux si les certificats se trouvent à un emplacement inhabituel.
En pratique
Avec un hébergement mutualisé, le panneau de contrôle gère le certificat pour vous (chez WebOké et chez d'autres hébergeurs avec DirectAdmin, cPanel ou Plesk). Sur un VPS, vous le faites vous-même, avec certbot, Caddy ou le client ACME fourni avec votre logiciel. C'est le cas chez tous les fournisseurs.
Résumé
- Un certificat Let's Encrypt prouve que vous contrôlez le nom ; certbot le demande, l'installe et le renouvelle via ACME.
- HTTP-01 nécessite le port 80 ouvert, pour tout le monde, et la même réponse en IPv4 et en IPv6 ; DNS-01 sert aux wildcards.
certbot --nginx -d ... -d ...gère le certificat et la redirection vers https ; demandez tous les noms d'un site en une seule fois.- Les certificats sont actuellement valables 90 jours et cette durée va diminuer ; contrôlez le timer et
certbot renew --dry-run, et surveillez vous-même la date d'expiration. - Testez avec
--stagingpour éviter les rate limits ; faites attention au CAA.
Quiz
Exercice
Exercice Z7.3 : https avec un certificat valide. Demandez un certificat pour votre site (avec certbot ou Caddy), redirigez http vers https et testez le renouvellement avec certbot renew --dry-run (avec Caddy : vérifiez dans les journaux que le certificat a bien été obtenu). Saisissez le nom de votre site. Le programme établit une connexion TLS vers le port 443 et vérifie que le certificat est valide, signé par une autorité de confiance et qu'il couvre votre nom, puis il demande http://<naam>/ pour voir si vous redirigez vers https. Indiquez également la date d'expiration de votre certificat et la façon dont vous avez organisé le renouvellement.
Pour aller plus loin
- Activer, renouveler et résoudre les problèmes liés au certificat SSL
- Cours DNS gratuit 5.2: CAA : qui est autorisé à émettre des certificats ?
- Let's Encrypt, Challenge Types (en anglais) : https://letsencrypt.org/docs/challenge-types/
- Let's Encrypt, Rate Limits (en anglais) : https://letsencrypt.org/docs/rate-limits/
- Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days (en anglais) : https://letsencrypt.org/2025/12/02/from-90-to-45
- Instructions Certbot (nginx) : https://certbot.eff.org/instructions?ws=nginx&os=snap
