TLS avec certbot : HTTPS nginx et Caddy

À la fin de ce tutoriel, vous saurez préparer un lab HTTPS avec certbot (Let’s Encrypt), obtenir un certificat en mode staging devant nginx et devant Caddy, vérifier la chaîne avec openssl s_client, comprendre HTTP-01 vs DNS-01, et renouveler / nettoyer sans coller de vraies clés privées — sur VM jetable, ports 80/443 ouverts (nft/ufw), console de secours.

Niveau : Intermédiaire+ · Temps estimé : 50–60 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11

Slug proposé : linux-tls-certbot · Série : Linux Réseau & Sécurité · Remplace / fusionne : N/A — création (chapitre 3)

Prérequis

• Hub Linux Réseau & Sécurité
• fail2ban avancé et nftables : ports 80/443 autorisés ; console de secours
• Basics réseau ip/ss/curl ; DNS A/AAAA du lab pointant vers la VM (placeholder lab.example.com)
• sudo ; pas de secrets ni certificats de prod dans le dépôt ; préférer --staging Let’s Encrypt en premier essai
• Paquets selon piste : nginx + certbot + plugin nginx ou binaire Caddy (les deux pistes sont couvertes)

Coût : 0 € hors VPS/domaine. Rate-limit LE : le staging évite de brûler le quota prod.

Ce que nous allons construire

TLS / Let’s Encrypt / HTTP-01 (aperçu DNS-01)
  → Piste A : nginx + certbot --nginx (staging)
  → Piste B : Caddy (tls automatique ou certbot externe)
  → Vérif : curl -vI https://… · openssl s_client
  → Renouvellement dry-run · nettoyage lab

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Certbot TLS : Let’s Encrypt staging devant nginx et Caddy, vérif openssl s_client ».)

Chapitre 3 : après le firewall et fail2ban, on chiffre le trafic web. Remplacez partout lab.example.com et l’e-mail par vos valeurs de lab.

Placeholders uniquement. Aucune clé privée réelle dans vos notes. Snapshot VM avant d’ouvrir 443 sur un hôte partagé.

Étape 1 — Concepts : certbot, Let’s Encrypt, défis

Terme	Rôle
TLS	Chiffrement HTTPS (certificat + clé privée)
Let’s Encrypt	AC gratuite ; certificats courts (~90 j)
certbot	Client LE : obtient / renouvelle / déploie
HTTP-01	Preuve : fichier servi sur :80
DNS-01	Preuve : TXT DNS (wildcard, pas d’HTTP ouvert)

# Ports web exposés ? (nft / ss)
ss -tuln | grep -E ':80|:443' || true
sudo nft list ruleset 2>/dev/null | grep -E '80|443' | head || true
# Résolution lab (doit coller à l’IP publique de la VM pour HTTP-01)
getent hosts lab.example.com || echo "Remplacez lab.example.com + créez l’enregistrement DNS A"

Sans DNS réel : suivez quand même les confs nginx/Caddy en HTTP local et la partie openssl avec un certificat auto-signé de secours (étape 5) — le flux certbot staging reste la cible dès que le DNS est prêt.

Étape 2 — Piste nginx + certbot (staging)

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx
# Site lab minimal — server_name = votre domaine
sudo tee /etc/nginx/sites-available/lab-tls >/dev/null << 'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name lab.example.com;

    location / {
        return 200 "lab tls nginxn";
        add_header Content-Type text/plain;
    }
}
EOF
sudo ln -sf /etc/nginx/sites-available/lab-tls /etc/nginx/sites-enabled/lab-tls
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
curl -sS -H 'Host: lab.example.com' http://127.0.0.1/ || true

Obtenir le certificat en staging (pas de confiance navigateur — normal) :

# Remplacez e-mail + domaine — --staging OBLIGATOIRE au 1er lab
sudo certbot --nginx certonly --staging 
  -d lab.example.com 
  --non-interactive --agree-tos 
  -m vous@example.com 
  --redirect || echo "Échec souvent = DNS/ports ; corriger avant --prod"

# Voir chemins (staging sous /etc/letsencrypt/…)
sudo ls /etc/letsencrypt/live/ 2>/dev/null || true
sudo nginx -t && sudo systemctl reload nginx

Flag	Effet
--staging	AC de test, rate-limit souple
--nginx	Plugin : ajuste server blocks
certonly	Certificat sans tout réécrire (selon besoin)
(prod plus tard)	Retirer --staging quand le lab est stable

Rocky/Alma : dnf install nginx certbot python3-certbot-nginx ; chemins conf sous /etc/nginx/conf.d/.

Étape 3 — Piste Caddy (TLS automatique ou certbot)

Caddy obtient souvent les certificats tout seul (ACME intégré). Deux modes lab :

3a — Caddy natif (recommandé pour découvrir Caddy)

# Install rapide Ubuntu (adaptez si binaire déjà présent)
if ! command -v caddy >/dev/null; then
  sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
  curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' 
    | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
  curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' 
    | sudo tee /etc/apt/sources.list.d/caddy-stable.list
  sudo apt update && sudo apt install -y caddy
fi

# Arrêter nginx si les deux se disputent :80/:443 sur la même VM lab
# sudo systemctl stop nginx

sudo tee /etc/caddy/Caddyfile >/dev/null << 'EOF'
{
    # Lab : AC staging Let’s Encrypt (évite quota prod)
    acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}
lab.example.com {
    respond "lab tls caddy" 200
}
EOF
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy
sudo systemctl reload caddy

3b — Certificats certbot montés dans Caddy (si vous centralisez sur certbot)

# Après un certbot certonly --webroot ou --standalone (staging)
# Exemple Caddyfile (chemins LIVE après succès certbot) :
# lab.example.com {
#     tls /etc/letsencrypt/live/lab.example.com/fullchain.pem 
#         /etc/letsencrypt/live/lab.example.com/privkey.pem
#     respond "lab tls caddy+certbot" 200
# }
echo "Mode 3b : décommentez tls fullchain/privkey une fois les fichiers LE présents"

Approche	Avantage lab
Caddy ACME intégré	Peu de pieces mobiles
certbot + nginx plugin	Contrôle fin, très documenté
certbot + Caddy tls fichiers	Un seul outil d’émission (certbot)

Sur une petite VM, faites nginx puis Caddy (ou l’inverse) en stoppant l’autre pour libérer 80/443 — ne courez pas les deux ACME en parallèle sur le même hostname.

Étape 4 — Vérifier avec curl et openssl s_client

DOM=lab.example.com
# HTTP → HTTPS (si redirect activé)
curl -sSI "http://$DOM/" | head -n 15 || true
# TLS (staging = warning navigateur / verify error attendu parfois)
curl -vkI "https://$DOM/" 2>&1 | head -n 35

# Chaîne et certificat présentés
echo | openssl s_client -connect "${DOM}:443" -servername "$DOM" 2>/dev/null 
  | openssl x509 -noout -subject -issuer -dates 2>/dev/null || 
  echo | openssl s_client -connect "127.0.0.1:443" -servername "$DOM" -showcerts 2>&1 | head -n 40

Outil	Ce qu’on lit
curl -vkI	Alerte vérif, code HTTP, redirect
openssl s_client	Handshake, certificat servi
x509 -subject -issuer -dates	CN/SAN, émetteur (Staging vs R3), validité

Émetteur contenant Staging = succès lab staging. Pour la prod : retirez --staging / acme_ca staging, renew, re-vérifiez.

Étape 5 — Renouvellement, auto-signé de secours, nettoyage

# Dry-run renouvellement certbot (nginx piste)
sudo certbot renew --dry-run 2>/dev/null || true
systemctl list-timers 'certbot*' 2>/dev/null | head || ls /etc/cron.d/certbot 2>/dev/null || true

# Secours SANS LE (DNS pas prêt) : auto-signé lab — navigateur se plaindra
sudo openssl req -x509 -nodes -newkey rsa:2048 -days 7 
  -keyout /tmp/lab-tls-self.key -out /tmp/lab-tls-self.crt 
  -subj "/CN=lab.example.com" 2>/dev/null
ls -l /tmp/lab-tls-self.* 
# Ne committez jamais *.key

# Nettoyage lab (exemples — adaptez la piste utilisée)
# sudo certbot delete --cert-name lab.example.com
# sudo rm -f /etc/nginx/sites-enabled/lab-tls /etc/nginx/sites-available/lab-tls
# sudo systemctl reload nginx
# sudo tee /etc/caddy/Caddyfile >/dev/null <<< ':80 { respond "caddy reset" 200 }'
# sudo systemctl reload caddy
rm -f /tmp/lab-tls-self.key /tmp/lab-tls-self.crt
echo "lab tls : placeholders OK — pas de clés dans le dépôt"

Validé si : au moins une piste (nginx+certbot ou Caddy) sert du HTTPS ; openssl s_client montre un certificat ; vous savez distinguer staging vs prod ; l’autre pile est comprise (lue / testée quand les ports sont libres).

Erreurs fréquentes

Symptôme	Cause	Correction
unauthorized / challenge fail	DNS ≠ IP VM ou :80 fermé	getent hosts ; ouvrir 80 (nft) ; attendre DNS
Rate limit LE	Trop d’essais prod	--staging / acme_ca staging
nginx et Caddy conflict	Deux process sur 80/443	stop l’un pendant le lab de l’autre
Navigateur « non sécurisé » en staging	AC staging non trusted	Attendu ; prod sans staging ensuite
openssl connect refuse	Rien n’écoute 443	ss -tuln ; reload nginx/caddy
Renouvellement KO	Timer/cron absent, plugin cassé	certbot renew --dry-run ; logs journalctl
Clé commitée dans Git	Mauvaise hygiène	Révoquer ; secrets hors dépôt

Quiz (3 questions)

1. Pourquoi utiliser --staging (ou AC staging Caddy) en lab ?
– A. Pour obtenir des certificats plus longs
– B. Pour tester sans épuiser les rate-limits de l’AC de production
– C. Pour désactiver TLS

2. Rôle de openssl s_client -connect host:443 -servername host ?
– A. Bannir une IP
– B. Inspecter le handshake / certificat présenté (SNI)
– C. Générer une paire SSH

3. Différence utile nginx+certbot vs Caddy ACME ?
– A. Aucune
– B. certbot+plugin nginx déploie via certbot ; Caddy peut gérer ACME nativement dans le Caddyfile
– C. Caddy ne sait pas faire du HTTPS

Réponses : 1‑B · 2‑B · 3‑B

FAQ

Puis-je faire nginx et Caddy le même jour sur une VM ?
Oui en séquentiel : validez nginx+certbot, stoppez nginx, validez Caddy (ou l’inverse). Évitez deux ACME concurrents sur le même FQDN.

HTTP-01 ou DNS-01 ?
Lab VPS classique : HTTP-01 (port 80). DNS-01 pour wildcards (*.example.com) ou quand 80 est inaccessible — API DNS requise (hors cœur).

Où sont les fichiers certbot ?
Sous /etc/letsencrypt/live/<domaine>/ (fullchain.pem, privkey.pem). Permissions root ; ne les copiez pas dans Git.

Pour aller plus loin

• man certbot, doc Let’s Encrypt, doc Caddy TLS
• Suite : SSH hardening : AllowUsers, sshd et 2FA
• Hub : Linux Réseau & Sécurité

Maillage série Linux Réseau & Sécurité

← Précédent	fail2ban avancé : jails, filtres, banactions
→ Suivant	SSH hardening : AllowUsers, sshd et 2FA
Hub	Linux Réseau & Sécurité
Aussi	nftables · réseau ip/ss/curl

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Certbot TLS : HTTPS avec nginx et Caddy (2026)
• Meta description (≤ 155) : Obtenez un certificat Let’s Encrypt avec certbot devant nginx ou Caddy. Lab Linux DevOps 2026.
• Focus keyphrase : certbot
• KW secondaires : let’s encrypt, openssl s_client, nginx, caddy
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-tls-certbot-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire+
• Slug : linux-tls-certbot
• Statut : HOLD — draft only (ne pas publier)