HTTPS avec Nginx et Let’s Encrypt grâce à Certbot

📍 Article principal du parcours : Nginx : reverse proxy, HTTPS et configuration de A à Z
Cet article fait partie du parcours Nginx. Pour la vue d’ensemble, lisez d’abord le guide principal.

Votre site Colis Express répond en HTTP — mais les navigateurs affichent « Non sécurisé » dans la barre d’adresse, le référencement en pâtit, et chaque requête, mots de passe compris, circule en clair. Le HTTPS n’est plus optionnel. La bonne nouvelle : grâce à Let’s Encrypt, une autorité de certification gratuite et reconnue partout, et à l’outil Certbot, vous allez chiffrer tout le site en quelques commandes, avec un renouvellement qui se fait tout seul. À la fin, https://colis-express.net affichera le cadenas, et le HTTP redirigera automatiquement vers le HTTPS.

🎯 Ce que vous allez apprendre

• Comprendre ce qu’est Let’s Encrypt et le protocole ACME de validation automatique.
• Installer Certbot proprement et obtenir un certificat pour votre domaine.
• Laisser Certbot configurer Nginx, ou écrire soi-même un bloc HTTPS robuste.
• Activer HTTP/2 avec la syntaxe à jour (et non l’ancienne, dépréciée).
• Vérifier et tester le renouvellement automatique du certificat.

🛠️ Ce que vous allez construire

Votre domaine basculera en HTTPS avec un certificat valide, le trafic HTTP sera redirigé en 301 vers HTTPS, HTTP/2 sera actif, et un minuteur système renouvellera le certificat sans intervention de votre part avant son expiration. Bref, un chiffrement de production, posé et oublié.

Prérequis

• Nginx servant déjà votre domaine en HTTP (voir Installer Nginx et configurer ses premiers vhosts).
• Un enregistrement DNS A pointant vers l’IP du serveur, et le port 80 ouvert (la validation en dépend).
• Niveau intermédiaire. Test express : si http://votre-domaine répond déjà, vous êtes prêt.
• ⏱️ Temps estimé : ~25 minutes.

Étape 1 — Comprendre Let’s Encrypt et ACME

Avant de lancer des commandes, un modèle mental clair évite bien des erreurs. Let’s Encrypt est une autorité de certification à but non lucratif : elle émet gratuitement des certificats TLS reconnus par tous les navigateurs. Pour prouver que vous contrôlez bien le domaine, elle utilise le protocole ACME : Certbot, installé sur votre serveur, demande un certificat, et Let’s Encrypt lui pose un défi — typiquement, déposer un fichier secret à une URL précise de votre site. Si l’autorité retrouve ce fichier en visitant votre domaine, elle a la preuve que vous le contrôlez, et délivre le certificat.

Deux conséquences pratiques. D’une part, votre domaine doit être joignable depuis Internet sur le port 80 au moment de la validation : c’est par là que passe le défi HTTP. D’autre part, les certificats sont valables 90 jours seulement — une durée courte voulue pour limiter les dégâts en cas de compromission. C’est précisément pourquoi le renouvellement automatique n’est pas un confort mais une nécessité, et Certbot s’en charge.

Étape 2 — Installer Certbot

La méthode recommandée par le projet Certbot est l’installation via snap, car elle fournit toujours la version la plus récente, plugin Nginx compris, indépendamment de l’âge de votre distribution. Installons-la.

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

La première ligne installe Certbot ; la seconde crée un lien pour pouvoir l’appeler simplement par certbot. Si vous préférez ne pas utiliser snap, l’alternative par les paquets de la distribution fonctionne aussi : sudo apt install certbot python3-certbot-nginx. Elle est parfaitement valable, simplement parfois un peu en retard sur les fonctionnalités. Dans les deux cas, vérifiez l’installation avec certbot --version.

✅ Point d’étape — certbot --version affiche un numéro de version. Le plugin Nginx est disponible (il l’est par défaut avec snap et avec python3-certbot-nginx).

Étape 3 — Obtenir et installer le certificat

C’est l’étape magique. Le plugin Nginx de Certbot va obtenir le certificat et modifier votre configuration pour l’utiliser, en une seule commande. Il lit votre server_name pour savoir quels domaines couvrir.

sudo certbot --nginx -d colis-express.net -d www.colis-express.net

Certbot pose deux ou trois questions au premier passage : une adresse e-mail (pour les alertes d’expiration), l’acceptation des conditions, et le choix de rediriger ou non le HTTP vers le HTTPS. Choisissez la redirection. En quelques secondes, Certbot obtient le certificat via ACME, l’installe, ajoute un bloc d’écoute sur le 443 avec les chemins du certificat, et met en place la redirection 301 depuis le port 80. Rechargez si besoin, puis ouvrez https://colis-express.net : le cadenas est là.

✅ Point d’étape — https://colis-express.net affiche le cadenas et curl -I http://colis-express.net renvoie 301 Moved Permanently vers la version HTTPS. Le chiffrement est actif.

Étape 4 — Activer HTTP/2 avec la bonne syntaxe

Maintenant que le 443 écoute, autant profiter de HTTP/2, qui multiplexe les requêtes sur une seule connexion et accélère sensiblement le chargement, surtout sur les liaisons à forte latence. Attention : la façon de l’activer a changé. L’ancienne syntaxe listen 443 ssl http2; est dépréciée depuis Nginx 1.25.1 et provoque un avertissement. La forme correcte aujourd’hui sépare l’écoute et l’activation de HTTP/2.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name colis-express.net www.colis-express.net;

    ssl_certificate     /etc/letsencrypt/live/colis-express.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/colis-express.net/privkey.pem;

    # ... vos location (front statique + /api/) ...
}

On garde listen 443 ssl; pour l’écoute chiffrée, et on ajoute la directive autonome http2 on;. Les chemins fullchain.pem et privkey.pem sous /etc/letsencrypt/live/ sont gérés par Certbot — n’y touchez pas à la main. Après modification, le réflexe habituel : sudo nginx -t && sudo systemctl reload nginx. Vous pouvez confirmer la négociation HTTP/2 dans l’onglet « Réseau » des outils de développement du navigateur, colonne « Protocole ».

Étape 5 — Vérifier le renouvellement automatique

Un certificat de 90 jours qu’on oublie de renouveler, c’est un site qui tombe du jour au lendemain. Heureusement, l’installation de Certbot met en place un minuteur système qui tente le renouvellement deux fois par jour, et ne renouvelle réellement que les certificats proches de l’expiration. Vérifions qu’il est bien armé.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

La première commande montre le minuteur certbot.timer et sa prochaine échéance — preuve que le renouvellement automatique est planifié. La seconde simule un renouvellement complet sans rien émettre pour de vrai : si elle se termine par « The dry run was successful », vous avez la certitude que le jour venu, le renouvellement réel passera sans accroc. C’est le test à ne pas négliger : il révèle tout de suite un blocage de port ou une configuration cassée, des mois avant l’expiration.

✅ Point d’étape — Le minuteur certbot.timer est listé et actif, et certbot renew --dry-run se conclut par un succès. Le renouvellement tournera tout seul.

Étape 6 — Comprendre ce que Certbot a modifié

Le plugin Nginx fait gagner du temps, mais il ne faut pas qu’il reste une boîte noire : savoir ce qu’il a touché, c’est pouvoir reprendre la main le jour où il faut ajuster la configuration. Regardons votre bloc server après son passage.

sudo cat /etc/nginx/sites-available/colis-express

Vous verrez que Certbot a ajouté plusieurs choses : un bloc d’écoute listen 443 ssl; avec les directives ssl_certificate et ssl_certificate_key pointant vers /etc/letsencrypt/live/colis-express.net/, une ligne include /etc/letsencrypt/options-ssl-nginx.conf; qui apporte une base de réglages TLS sains, et un second bloc server sur le port 80 dont le seul rôle est de rediriger en 301 vers le HTTPS. Les certificats eux-mêmes vivent sous /etc/letsencrypt/ : fullchain.pem (le certificat et sa chaîne) et privkey.pem (la clé privée, à ne jamais exposer). Ces fichiers sont des liens vers le dossier archive/, que Certbot fait pivoter à chaque renouvellement — c’est pourquoi on ne les copie ni ne les modifie à la main.

Une fois tout en place, il vaut la peine de vérifier la qualité réelle de votre configuration TLS avec un analyseur externe : un service d’audit SSL public note votre domaine et signale tout protocole faible ou toute erreur de chaîne. Viser une note « A » est un objectif atteignable, et le tutoriel sur le durcissement vous y mènera. Pour l’instant, l’essentiel est acquis : le trafic est chiffré, valide et reconduit automatiquement.

✅ Point d’étape — Vous identifiez dans la configuration les lignes ajoutées par Certbot et savez où vivent les certificats. Le HTTPS n’est plus une boîte noire.

🐞 Pièges fréquents

🌍 Adaptation au contexte ouest-africain

La validation ACME est le point qui surprend le plus quand on débute ici : Let’s Encrypt doit pouvoir joindre votre domaine depuis l’extérieur. Si vous testez sur une machine locale derrière une box, derrière le NAT d’un opérateur, ou avec un domaine dont le DNS n’a pas fini de se propager, la validation échoue — non pas à cause de Certbot, mais parce que le défi HTTP n’arrive pas. Le réflexe gagnant est de toujours obtenir le certificat sur le VPS public, dont l’IP est directement accessible et le port 80 ouvert. Pensez aussi à choisir une vraie adresse e-mail pour les alertes d’expiration : c’est votre dernier filet si le renouvellement automatique venait à casser.

✅ Récapitulatif

Votre site est maintenant en HTTPS avec un certificat Let’s Encrypt gratuit, le HTTP redirige proprement vers le HTTPS, HTTP/2 est actif avec la syntaxe à jour, et le renouvellement est automatique et testé. Vous avez compris au passage le rôle d’ACME et la raison des certificats courts. Le chiffrement étant posé, l’étape suivante s’attaque à la vitesse perçue : compression et cache.

🧾 Aide-mémoire

💪 À vous de jouer

Sans utiliser le plugin Nginx automatique, obtenez un certificat avec le mode webroot (utile quand vous voulez garder la main sur la configuration). Indice : la commande utilise --webroot -w suivi du répertoire racine du site.

sudo certbot certonly --webroot -w /var/www/colis-express/html \
  -d colis-express.net -d www.colis-express.net

Tutoriels frères

• Cache et compression Nginx pour accélérer un site — la vitesse, une fois le chiffrement en place.
• Durcir Nginx : sécurité TLS, en-têtes et rate limiting — renforcer la configuration TLS au-delà du minimum.

Pour aller plus loin

• 🔝 Retour au guide principal : Nginx : reverse proxy, HTTPS et configuration de A à Z
• Documentation officielle : Documentation Certbot et Let’s Encrypt.
• Étape suivante du parcours : accélérer le site avec le cache et la compression.

FAQ

Let’s Encrypt est-il vraiment gratuit, sans piège ?
Oui. C’est un service d’une organisation à but non lucratif (l’ISRG), financé par des dons et des sponsors. Aucun paiement, aucune carte. Les certificats sont des certificats de validation de domaine (DV), suffisants pour la quasi-totalité des sites.

Dois-je encore activer l’agrafage OCSP (ssl_stapling) ?
Non, plus pour un certificat Let’s Encrypt. Le service OCSP de Let’s Encrypt a été arrêté en 2025, et les certificats émis depuis ne contiennent plus d’URL OCSP. La directive ssl_stapling on; n’a donc plus aucun effet sur ces certificats — c’est un conseil que beaucoup de vieux tutoriels répètent encore à tort.

Que se passe-t-il si le renouvellement échoue ?
Tant que le certificat n’est pas expiré, le site reste en ligne. Certbot retentera deux fois par jour, et vous recevrez un e-mail d’alerte de Let’s Encrypt à l’approche de l’expiration. Le --dry-run régulier reste la meilleure assurance.

Puis-je obtenir un certificat pour un sous-domaine joker (*.colis-express.net) ?
Oui, mais le certificat joker exige une validation par DNS (--manual ou un plugin DNS), pas par HTTP. C’est un cran au-dessus en complexité ; pour la plupart des besoins, lister explicitement les sous-domaines suffit.