Aller au contenu

Paramètres des cookies

Choisissez, par catégorie, les cookies que vous autorisez. Vous pouvez modifier votre choix à tout moment via Paramètres des cookies, en bas de chaque page. Politique de confidentialité

Nécessaires

Toujours activés

Indispensables pour vous connecter, conserver votre panier et mémoriser vos choix. Ils sont toujours activés.

Quels cookies ?
  • weboke_sessie, weboke_klant, weboke_remember: votre session et le maintien de la connexion
  • weboke_basket: votre panier
  • wkBtwIncl: l'affichage des prix TTC ou HT
  • wok_cookies: votre choix concernant les cookies, 12 mois

Mesure quelle publicité mène à une visite ou à une commande, pour que nous ne payions pas des publicités inefficaces.

Quels cookies ?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), jusqu'à 90 jours
  • OpenAI Ads, publicités dans ChatGPT
  • wok_aff: le partenaire qui vous a orienté vers nous (programme d'affiliation), 60 jours

4,6

Pays et langue

Chaque pays a son propre site, avec les prix et la TVA de ce pays.

Afficher

Module 7 · 7.3

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éfiCommentPortWildcard (*.example.com)
HTTP-01déposer un fichier sous http://<naam>/.well-known/acme-challenge/80non
DNS-01créer un enregistrement TXT _acme-challenge.<naam>aucunoui
TLS-ALPN-01présenter un certificat spécial pendant la négociation TLS443non

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-nginx

La 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 (-d par 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é)CauseSolution
Timeout during connect (likely firewall problem)port 80 fermé, ou le nom pointe vers une autre adressepare-feu (leçon 5.2), A/AAAA (leçon 7.1)
Invalid response from http://.../.well-known/acme-challenge/...: 404un autre serveur ou un autre server block répond, souvent via IPv6listen [::]:80, vérifier l'enregistrement AAAA
CAA record for example.com prevents issuanceun enregistrement CAA n'autorise qu'une autre autoritéadapter le CAA (leçon 7.1)
too many certificates already issuedune rate limitattendre ; 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.com

Si 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 --staging pour éviter les rate limits ; faites attention au CAA.

Quiz

1. Votre site doit être accessible uniquement en https. Pouvez-vous fermer le port 80 dans le pare-feu si vous utilisez HTTP-01 ?



2. Vous voulez un certificat pour *.example.com. Quel défi vous faut-il ?



3. La demande échoue avec une erreur 404 sur le fichier de défi, alors que curl http://example.com/ affiche votre site en IPv4. Quelle est la cause la plus probable ?



4. Pourquoi le renouvellement automatique est-il plus important que jamais ?



5. Vous faites des essais et avez déjà demandé quatre fois le même certificat aujourd'hui. Que faites-vous pour l'essai suivant ?



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.

Exercice Z7.3: https avec un certificat valide

Réservé aux participants inscrits. Nous ouvrons https://<naam>/ et http://<naam>/ comme un navigateur, depuis notre serveur web.




Nous ne conservons pas ce que vous saisissez ni ce que nous trouvons. Votre navigateur mémorise vos réponses et si l'exercice est réussi. Si vous êtes connecté, nous enregistrons uniquement dans Mes formations que l'exercice était (presque) correct ; vous pouvez aussi le supprimer à cet endroit.

Pour aller plus loin

Un instant…

Configurez vos domaines

Pour chaque domaine, réglez les serveurs de noms, l'association à votre hébergement et le futur titulaire.

Chargement de vos domaines…