Ce guide couvre l’obtention d’un certificat Let’s Encrypt avec Certbot sous Apache ou Nginx, son renouvellement et les erreurs fréquentes. Les exemples utilisent exemple.fr, à remplacer par votre domaine.
Prérequis avant la demande de certificat
Trois conditions doivent être réunies avant de lancer Certbot :
- le nom de domaine pointe vers l’adresse IP publique du serveur ;
- les ports 80 (HTTP) et 443 (HTTPS) sont accessibles depuis Internet ;
- un virtual host Apache ou un bloc
serverNginx répond déjà au nom de domaine demandé.
Le port 80 reste nécessaire même si le site n’est servi qu’en HTTPS : la validation HTTP-01 de Let’s Encrypt y vérifie un fichier de contrôle.
Vérifier la résolution DNS
# Note : dig est fourni par le paquet dnsutils (Debian, Ubuntu) ou bind-utils (RHEL et dérivés)
dig +short exemple.fr A
dig +short exemple.fr AAAASi un enregistrement AAAA (IPv6) existe, le serveur doit aussi écouter en IPv6. Dans le cas contraire, la validation peut être tentée vers une adresse qui ne répond pas.
Vérifier l’accessibilité des ports
Depuis un autre poste, curl -I http://exemple.fr/ doit obtenir une réponse. Si un pare-feu est actif, ouvrez les ports 80 et 443 avec son outil.
Comprendre le fonctionnement d’ACME
Let’s Encrypt délivre ses certificats via le protocole ACME. Certbot est le client qui demande le certificat et prouve le contrôle du domaine. Avec la méthode HTTP-01, Let’s Encrypt demande qu’un fichier soit servi sous /.well-known/acme-challenge/ sur le port 80. La méthode DNS-01 passe par un enregistrement TXT ; elle est obligatoire pour un certificat wildcard (*.exemple.fr).
Un certificat est valide 90 jours. Let’s Encrypt recommande de le renouveler avant 60 jours, et Certbot le renouvelle par défaut lorsqu’il reste moins de 30 jours de validité. La durée de validité peut évoluer : à confirmer dans la documentation officielle de Let’s Encrypt.
Installer Certbot sur Apache ou Nginx
Le paquet à installer dépend du serveur web. Les plugins --apache et --nginx modifient la configuration automatiquement. L’option certonly se contente de récupérer les fichiers du certificat.
Installation avec Apache
# Note : noms des paquets selon la distribution (exemple Debian ou Ubuntu)
sudo apt update
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d exemple.fr -d www.exemple.frCertbot demande ensuite si le trafic HTTP doit être redirigé vers HTTPS. Activez la redirection une fois le HTTPS validé. Testez la configuration avant chaque rechargement :
# Note : apache2ctl (Debian, Ubuntu) ou apachectl et httpd (RHEL)
sudo apache2ctl configtest
sudo systemctl reload apache2Installation avec Nginx
# Note : noms des paquets selon la distribution (exemple Debian ou Ubuntu)
sudo apt update
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d exemple.fr -d www.exemple.frCertbot ajoute les directives ssl_certificate et ssl_certificate_key dans le bloc server concerné. Si vous préférez gérer la configuration vous-même, récupérez seulement les fichiers avec la méthode webroot. Le chemin indiqué doit correspondre à la racine réellement servie par Nginx :
sudo certbot certonly --webroot -w /var/www/exemple.fr -d exemple.fr -d www.exemple.frLe bloc HTTPS ressemble alors à ceci :
server {
listen 443 ssl;
server_name exemple.fr www.exemple.fr;
ssl_certificate /etc/letsencrypt/live/exemple.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;
root /var/www/exemple.fr;
}Vérifiez puis rechargez Nginx :
sudo nginx -t
sudo systemctl reload nginxConfigurer le renouvellement automatique
Vérifier le timer systemd
Une installation par paquet installe généralement un timer systemd qui lance le renouvellement deux fois par jour. Vérifiez sa présence :
# Note : nom de l'unité selon le mode d'installation (certbot.timer, ou snap.certbot.renew.timer pour une installation snap)
systemctl list-timers | grep -i certbot
sudo systemctl status certbot.timerTester le renouvellement à blanc
sudo certbot renew --dry-runCette commande simule le renouvellement sur l’environnement de test de Let’s Encrypt et ne remplace aucun certificat. Lancez-la après l’installation, puis après chaque modification du serveur web. Pour contrôler la date d’expiration des certificats réellement installés :
sudo certbot certificatesPlanifier avec cron si aucun timer n’existe
Si aucun timer n’est présent, ajoutez une tâche dans la crontab de root avec sudo crontab -e. Gardez un seul mécanisme, timer ou cron, pour éviter les doubles exécutions. Le hook --deploy-hook ne s’exécute que lorsqu’un certificat a effectivement été renouvelé :
# Note : chemin de certbot (sortie de « command -v certbot ») et service à recharger
0 3 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"Sur un hébergement dont la planification passe par un panneau cPanel, utilisez l’interface prévue à cet effet, comme décrit dans ce guide sur les tâches cron via cPanel.
Diagnostiquer les erreurs fréquentes
Échec de la validation HTTP
Les messages courants sont Timeout during connect ou Invalid response ... 404. Les causes les plus fréquentes sont :
- le domaine pointe encore vers une ancienne adresse IP ;
- le port 80 est filtré par le pare-feu ;
- aucun virtual host ou bloc
serverne correspond au nom demandé ; - une règle de réécriture envoie
/.well-known/acme-challenge/vers l’application ; - un proxy ou un CDN placé devant le serveur ne transmet pas cette requête.
Testez le chemin de validation depuis l’extérieur :
curl -I http://exemple.fr/.well-known/acme-challenge/testUne réponse 404 émise par votre serveur est normale, puisque le fichier de test n’existe pas. Une erreur de connexion, ou une page générée par l’application, indique en revanche le problème à corriger.
Erreurs de DNS
Le message DNS problem: NXDOMAIN indique un domaine introuvable : l’enregistrement A est absent ou la propagation n’est pas terminée. no valid A records found apparaît lorsqu’un AAAA pointe vers une IPv6 non servie. Corrigez la zone DNS, puis relancez Certbot.
Limites de tentatives
Let’s Encrypt applique des limites par compte, par nom de domaine et par période. Après plusieurs échecs de validation pour le même nom, les nouvelles demandes sont temporairement refusées. Pour tester une configuration sans consommer les limites de production, utilisez l’environnement de test :
sudo certbot certonly --test-cert --webroot -w /var/www/exemple.fr -d exemple.frLes seuils en vigueur sont publiés sur la page officielle des limites de Let’s Encrypt. à confirmer, car ils évoluent.
Renouvellement qui échoue sans alerte
Après un échec, consultez le journal de Certbot :
sudo tail -n 100 /var/log/letsencrypt/letsencrypt.logUn renouvellement réussi n’est appliqué qu’après rechargement du serveur : vérifiez le --deploy-hook.
Vérifier HTTPS et HSTS
Contrôlez le certificat présenté par le serveur, son émetteur et sa date d’expiration :
openssl s_client -connect exemple.fr:443 -servername exemple.fr </dev/null 2>/dev/null | openssl x509 -noout -issuer -enddateVérifiez ensuite la redirection HTTP vers HTTPS. La première requête doit renvoyer une redirection 301 vers https:// :
curl -I http://exemple.fr/
curl -I https://exemple.fr/Pour la redirection sur un site WordPress, voir le guide pour rediriger HTTP vers HTTPS avec WordPress.
Activer HSTS avec prudence
HSTS impose HTTPS pendant la durée max-age. Une valeur trop élevée peut bloquer un sous-domaine encore servi en HTTP : commencez par une durée courte, puis augmentez-la après contrôle.
Avec Nginx, placez la directive dans le bloc HTTPS uniquement :
add_header Strict-Transport-Security "max-age=300" always;Avec Apache, le module headers doit être actif :
# Note : activation du module headers (sudo a2enmod headers sur Debian ou Ubuntu)
Header always set Strict-Transport-Security "max-age=300"N’ajoutez includeSubDomains ou preload qu’après avoir vérifié chaque sous-domaine. Les navigateurs conservent la règle pendant toute la durée de max-age, et le retrait d’un domaine de la liste de préchargement est lent.
Questions fréquentes
Pourquoi le certificat ne se renouvelle-t-il pas alors que le timer existe ?
Un timer actif ne garantit pas que le renouvellement réussit. Lancez sudo certbot renew --dry-run pour voir l’erreur, puis consultez le journal Certbot. Si le renouvellement réussit mais que le navigateur affiche toujours l’ancien certificat, le serveur n’a pas été rechargé : ajoutez un --deploy-hook adapté à votre serveur web.
Peut-on installer Certbot sur un hébergement mutualisé ?
Souvent non, faute d’accès root. Utilisez alors l’option SSL/TLS du panneau, si l’hébergeur propose Let’s Encrypt, et suivez sa procédure de renouvellement.
Faut-il activer HSTS dès l’installation du certificat ?
Non. Activez HSTS seulement après avoir vérifié que HTTPS fonctionne sur le domaine et sur ses sous-domaines, et commencez par une valeur courte, comme max-age=300.
