SSL : Certificat Let’s Encrypt avec Certbot sur Debian/Ubuntu (sans Snap)

Let’s Encrypt est une autorité de certification gratuite, automatisée et ouverte, qui délivre des certificats SSL/TLS reconnus par tous les navigateurs modernes. Certbot est l’outil officiel développé par l’EFF pour obtenir et renouveler ces certificats automatiquement. Ensemble, ils permettent de déployer HTTPS sur vos serveurs Linux en quelques minutes, sans frais et sans gérer manuellement les renouvellements.

Par défaut, la documentation officielle de Certbot recommande désormais l’installation via Snap (snapd). Cette approche pose des problèmes dans de nombreux environnements : serveurs minimalistes, conteneurs LXC non-privilégiés, politiques de sécurité internes, ou simple préférence pour les outils système natifs. Snap introduit un daemon supplémentaire, des montages loop devices, et des mises à jour automatiques difficiles à auditer. Heureusement, Certbot peut être installé proprement via pip dans un environnement virtuel Python, sans toucher à Snap ni aux paquets APT obsolètes.

Ce guide couvre l’installation complète de Certbot sur Debian et Ubuntu via la méthode pip officielle, l’obtention de certificats pour Nginx et Apache, et la configuration du renouvellement automatique.

Prérequis

Avant de commencer, assurez-vous que :

• Votre nom de domaine pointe vers l’adresse IP publique de votre serveur (résolution DNS active et propagée).
• Les ports 80 (HTTP) et 443 (HTTPS) sont ouverts dans votre pare-feu — Let’s Encrypt en a besoin pour valider la propriété du domaine.
• Votre serveur web (Nginx ou Apache) est installé et répond sur le domaine cible.
• Vous disposez des droits sudo sur la machine.

Si vous utilisez nftables comme pare-feu, vérifiez que les ports 80 et 443 sont bien autorisés en entrée. Consultez l’article nftables en pratique sur Debian/Ubuntu pour configurer vos règles avant de poursuivre.

Pourquoi éviter Snap pour Certbot ?

L’alternative pip dans un virtualenv offre plusieurs avantages concrets par rapport à Snap :

• Compatibilité totale avec les conteneurs LXC non-privilégiés, les systèmes sans snapd, et les environnements minimalistes.
• Contrôle des mises à jour : vous décidez quand mettre à jour Certbot, avec les mêmes outils que le reste de votre système.
• Isolation propre des dépendances Python dans /opt/certbot/, sans polluer l’environnement système.
• Intégration native avec cron ou systemd, sans daemon Snap supplémentaire.

Installation de Certbot via pip

1. Supprimer les anciennes installations

Si Certbot a déjà été installé via APT ou Snap, supprimez ces versions pour éviter les conflits :

# Supprimer les paquets APT si présents
sudo apt remove certbot python3-certbot-nginx python3-certbot-apache 2>/dev/null

# Supprimer la version Snap si installée
sudo snap remove certbot 2>/dev/null || true

2. Installer les dépendances système

sudo apt update
sudo apt install -y python3 python3-dev python3-venv libaugeas-dev gcc

Le paquet libaugeas-dev est requis par le plugin Apache de Certbot (il permet la modification automatique des VirtualHosts). Pour une utilisation exclusivement avec Nginx, il n’est pas strictement nécessaire mais son installation ne pose aucun problème.

3. Créer l’environnement virtuel Python

# Créer le virtualenv dédié à Certbot
sudo python3 -m venv /opt/certbot/

# Mettre à jour pip à l'intérieur du virtualenv
sudo /opt/certbot/bin/pip install --upgrade pip

4. Installer Certbot et le plugin adapté à votre serveur web

Pour Nginx :

sudo /opt/certbot/bin/pip install certbot certbot-nginx

Pour Apache :

sudo /opt/certbot/bin/pip install certbot certbot-apache

Pour les deux serveurs :

sudo /opt/certbot/bin/pip install certbot certbot-nginx certbot-apache

5. Créer le lien symbolique

sudo ln -s /opt/certbot/bin/certbot /usr/local/bin/certbot

# Vérifier la version installée
certbot --version

Résultat attendu (version actuelle en 2026) :

certbot 5.6.0

Obtenir un certificat SSL

Avec Nginx — configuration automatique

La commande suivante obtient le certificat et modifie automatiquement la configuration Nginx pour activer HTTPS, la redirection HTTP→HTTPS, et les paramètres SSL recommandés :

sudo certbot --nginx -d exemple.com -d www.exemple.com

Certbot vous demandera une adresse e-mail (pour les alertes d’expiration) et votre accord avec les conditions d’utilisation. Il modifiera le bloc server Nginx correspondant et rechargera la configuration.

Pour obtenir uniquement le certificat sans toucher à la configuration Nginx (si vous gérez manuellement vos blocs server) :

sudo certbot certonly --nginx -d exemple.com -d www.exemple.com

Avec Apache — configuration automatique

sudo certbot --apache -d exemple.com -d www.exemple.com

Certbot modifie le VirtualHost Apache pour y ajouter les directives SSL, active le module mod_ssl, et configure la redirection HTTP→HTTPS.

Mode standalone (sans serveur web actif)

Si votre serveur web n’est pas encore configuré, le mode standalone lance un serveur HTTP temporaire sur le port 80 pour répondre au défi de validation :

# Arrêter temporairement le serveur web (port 80 doit être libre)
sudo systemctl stop nginx

# Obtenir le certificat
sudo certbot certonly --standalone -d exemple.com -d www.exemple.com

# Relancer le serveur web
sudo systemctl start nginx

Mode webroot (sans interrompre le serveur web)

Le mode webroot place des fichiers de validation dans un répertoire servi par votre serveur, sans l’interrompre. C’est la méthode la plus propre en production :

sudo certbot certonly --webroot 
  -w /var/www/exemple.com/public 
  -d exemple.com -d www.exemple.com

Les certificats obtenus sont stockés dans /etc/letsencrypt/live/exemple.com/ :

ls /etc/letsencrypt/live/exemple.com/
# cert.pem       → certificat du domaine seul
# chain.pem      → chaîne de certification intermédiaire
# fullchain.pem  → cert.pem + chain.pem (à utiliser dans nginx/apache)
# privkey.pem    → clé privée (à protéger, jamais exposée publiquement)

Renouvellement automatique

Les certificats Let’s Encrypt ont une durée de vie de 90 jours. Certbot peut les renouveler automatiquement lorsqu’ils approchent de l’expiration (seuil : moins de 30 jours restants). La pratique recommandée par Let’s Encrypt est de tenter le renouvellement deux fois par jour :

echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

Cette entrée cron :

• S’exécute à 00h00 et 12h00 chaque jour.
• Attend un délai aléatoire (jusqu’à 1 heure) pour répartir la charge sur les serveurs Let’s Encrypt.
• Lance certbot renew -q qui ne renouvelle que les certificats expirant dans moins de 30 jours.

Testez le renouvellement en mode simulation avant de valider :

sudo certbot renew --dry-run

Mise à jour mensuelle de Certbot

Contrairement à la version Snap, Certbot installé via pip ne se met pas à jour automatiquement. Ajoutez une mise à jour mensuelle dans cron :

echo "0 3 1 * * root /opt/certbot/bin/pip install --upgrade certbot certbot-nginx certbot-apache -q" | sudo tee -a /etc/crontab > /dev/null

Vérification et dépannage

Lister les certificats et leurs dates d’expiration

sudo certbot certificates

Sortie typique :

Found the following certs:
  Certificate Name: exemple.com
    Domains: exemple.com www.exemple.com
    Expiry Date: 2026-09-28 12:00:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/exemple.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/exemple.com/privkey.pem

Tester la connexion SSL

# Vérifier le certificat présenté par le serveur
openssl s_client -connect exemple.com:443 -servername exemple.com /dev/null 
  | openssl x509 -noout -issuer -dates

# Tester avec curl
curl -vI https://exemple.com 2>&1 | grep -E "SSL|issuer|expire|subject"

Erreurs fréquentes

Erreur « Too many requests » (429) : Let’s Encrypt limite à 5 certificats émis par domaine enregistré par semaine en production. Utilisez l’option --test-cert pour les tests — les certificats de staging ne sont pas reconnus par les navigateurs mais n’ont pas de limite de taux.

# Mode staging pour les tests (sans limite de taux)
sudo certbot certonly --nginx --test-cert -d exemple.com

Port 80 inaccessible : Let’s Encrypt doit pouvoir joindre votre serveur sur le port 80 pour valider le domaine. Vérifiez vos règles de pare-feu et qu’aucun redirect immédiat vers HTTPS ne bloque la requête de validation sur /.well-known/acme-challenge/.

Erreur de permissions sur /etc/letsencrypt : Les certificats appartiennent à root. Si votre serveur web tourne sous un autre utilisateur, assurez-vous que les fichiers dans /etc/letsencrypt/live/ et /etc/letsencrypt/archive/ sont lisibles par ce processus, ou utilisez des ACL POSIX.

À lire également

• nftables en pratique — remplacer iptables sur Debian/Ubuntu — Configurer les règles de pare-feu pour autoriser le trafic sur les ports 80 et 443, indispensable pour la validation Let’s Encrypt.
• ProFTPd : authentification MySQL, FTPs (SSL) et SFTP sur Debian/Ubuntu — Sécuriser les transferts FTP avec SSL/TLS, en complément du HTTPS déployé sur vos services web.
• Fail2ban — configuration avancée et filtres personnalisés — Protéger vos services exposés sur Internet contre les attaques par force brute, en parallèle de la mise en place du HTTPS.
• Durcissement SSH — au-delà des clés publiques — Compléter la sécurisation de votre infrastructure serveur au-delà du seul certificat SSL.

Références

• Instructions officielles Certbot — Nginx via pip (EFF)
• Documentation officielle Certbot — Guide d’installation
• Documentation Let’s Encrypt
• Let’s Encrypt Community — Comparatif apt vs snap vs pip