Un certificat SSL n’est plus une option en 2026 : sans cadenas valide, Chrome et Firefox affichent un écran d’avertissement qui fait fuir la quasi-totalité des visiteurs. La bonne nouvelle, c’est que vous pouvez en obtenir un gratuitement, en moins de dix minutes, avec Let’s Encrypt et Certbot. Ce tutoriel vous guide en 11 étapes concrètes, de l’installation du client ACME jusqu’au renouvellement automatique, avec une configuration Nginx durcie pour TLS 1.3.
Toutes les commandes ont été testées sur Ubuntu 24.04 LTS et Debian 12 avec Nginx. Elles fonctionnent à l’identique sur la plupart des distributions Linux récentes. Vous trouverez aussi un volet dépannage de 8 cas réels, six pièges fréquents et une section dédiée aux certificats wildcard via le défi DNS-01.
Certificat SSL gratuit : pourquoi Let’s Encrypt domine en 2026
Let’s Encrypt est une autorité de certification (CA) à but non lucratif, opérée par l’Internet Security Research Group (ISRG). Son principe est simple : délivrer des certificats TLS gratuits, de façon entièrement automatisée, pour chiffrer le trafic web. En 2026, l’autorité sécurise des centaines de millions de sites et reste la plus grande CA publique au monde par le volume de certificats actifs.
Trois raisons expliquent cette domination. D’abord le prix : zéro euro, là où un certificat commercial à validation de domaine coûte encore entre 50 et 200 euros par an. Ensuite l’automatisation : le protocole ACME permet d’obtenir, d’installer et de renouveler un certificat sans intervention humaine, ce qui élimine la principale cause d’incident TLS, à savoir le certificat expiré qu’on a oublié de renouveler. Enfin la confiance : les certificats Let’s Encrypt sont reconnus par tous les navigateurs et systèmes d’exploitation modernes via la chaîne de racine ISRG Root X1.
Pour le webmaster français, l’enjeu dépasse le simple cadenas. Le HTTPS est un signal de classement Google depuis 2014, et le passage en HTTP/2 puis HTTP/3 (QUIC) exige obligatoirement TLS. Un site non chiffré est aujourd’hui pénalisé deux fois : par les navigateurs qui le marquent comme « non sécurisé » et par les moteurs qui le déclassent. Pour comprendre ce que valide réellement le cadenas, lisez notre dossier sur le fonctionnement de HTTPS et TLS.
Certbot, développé par l’Electronic Frontier Foundation (EFF), reste le client ACME de référence. C’est lui que nous utilisons dans ce guide. Il gère à la fois l’obtention du certificat, sa pose dans la configuration Nginx et son renouvellement via une minuterie systemd. D’autres clients existent (acme.sh, lego, Caddy en natif), mais Certbot offre le meilleur compromis documentation, stabilité et intégration serveur pour un débutant.
Ce qui change en 2026 : la durée de vie des certificats chute
Le changement le plus important de l’année concerne la durée de validité. Le CA/Browser Forum, l’organisme qui réunit autorités de certification et éditeurs de navigateurs, a voté une réduction progressive de la durée de vie maximale des certificats TLS publics. L’objectif : limiter la fenêtre d’exploitation d’une clé compromise et forcer l’automatisation du renouvellement.
| Date d’entrée en vigueur | Durée maximale du certificat | Renouvellements par an |
|---|---|---|
| Avant mars 2026 | 398 jours (commercial) / 90 jours (Let’s Encrypt) | 1 à 4 |
| 15 mars 2026 | 200 jours | environ 2 |
| 15 mars 2027 | 100 jours | environ 4 |
| 15 mars 2029 | 47 jours | environ 8 |
Let’s Encrypt délivre déjà des certificats valables 90 jours, bien en dessous des plafonds commerciaux. La trajectoire vers 47 jours en 2029 ne change donc rien à votre flux de travail si vous automatisez le renouvellement dès maintenant. C’est précisément l’objet de l’étape 9 de ce tutoriel. La leçon est claire : en 2026, gérer ses certificats à la main devient ingérable, et l’automatisation n’est plus une bonne pratique mais une nécessité opérationnelle.
Autre évolution notable côté Let’s Encrypt : l’abandon progressif de l’agrafage OCSP (OCSP stapling) annoncé en 2025. L’autorité bascule vers les listes de révocation (CRL) pour des raisons de performance et de confidentialité. Concrètement, ne configurez plus l’OCSP stapling comme un prérequis : votre certificat reste parfaitement valide sans lui. Nous y revenons dans la section durcissement TLS.
Prérequis : versions et accès requis
Avant de lancer la moindre commande, vérifiez que votre environnement remplit les conditions suivantes. Sauter cette étape est la première cause d’échec : neuf erreurs sur dix lors de l’émission d’un certificat viennent d’un DNS mal pointé ou d’un port 80 fermé.
| Élément | Version / valeur requise | Comment vérifier |
|---|---|---|
| Système | Ubuntu 24.04 / Debian 12 (ou équivalent récent) | lsb_release -a |
| Nginx | 1.24 ou supérieur | nginx -v |
| Certbot | série 5.x (5.6.0, mai 2026, via snap) | certbot --version |
| snapd | 2.61 ou supérieur | snap version |
| Accès | Compte avec privilèges sudo / root | sudo -v |
| Nom de domaine | Enregistrement A/AAAA pointant vers le serveur | dig +short exemple.fr |
| Pare-feu | Ports 80 et 443 ouverts | sudo ufw status |
Un point mérite une attention particulière : le port 80 doit rester ouvert et accessible depuis l’extérieur. Le défi HTTP-01, que Certbot utilise par défaut, exige que les serveurs de validation de Let’s Encrypt atteignent votre machine sur le port 80. Beaucoup d’utilisateurs ferment ce port en pensant « tout passer en HTTPS », et bloquent du même coup l’émission du certificat. Gardez-le ouvert, quitte à y poser une redirection 301 vers HTTPS une fois le certificat en place.
Vérifiez aussi que votre domaine résout bien vers l’adresse IP publique du serveur. Si vous venez de modifier votre zone DNS, la propagation peut prendre de quelques minutes à 48 heures selon le TTL. Attendez que dig +short exemple.fr renvoie la bonne IP avant de continuer.
Le protocole ACME et les trois types de défi
ACME (Automatic Certificate Management Environment) est le protocole standardisé (RFC 8555) qui régit le dialogue entre Certbot et Let’s Encrypt. Avant de délivrer un certificat, l’autorité doit prouver que vous contrôlez bien le domaine demandé. Elle vous soumet pour cela un « défi » (challenge) que votre serveur doit relever. Trois types existent, et le choix conditionne toute la suite.
| Type de défi | Mécanisme | Port | Wildcard | Cas d’usage |
|---|---|---|---|---|
| HTTP-01 | Fichier témoin servi sous /.well-known/acme-challenge/ | 80 | Non | Défaut, site web simple |
| DNS-01 | Enregistrement TXT _acme-challenge dans la zone DNS | Aucun | Oui | Wildcard, serveur sans port 80 |
| TLS-ALPN-01 | Négociation TLS dédiée sur le port 443 | 443 | Non | Reverse proxy, port 80 indisponible |
Pour un site web classique sur un serveur dédié ou un VPS, le défi HTTP-01 est le bon choix : Certbot dépose un fichier temporaire dans un répertoire spécial, Let’s Encrypt le lit, valide, puis délivre le certificat. Aucune manipulation DNS n’est nécessaire. C’est ce que nous faisons aux étapes 4 à 6.
Le défi DNS-01 devient obligatoire dans un seul cas courant : le certificat wildcard (par exemple *.exemple.fr), qui couvre tous les sous-domaines en une seule émission. Ni HTTP-01 ni TLS-ALPN-01 ne peuvent valider un wildcard. Nous traitons ce scénario plus loin. Le TLS-ALPN-01, plus rare, sert quand le port 80 est inutilisable, par exemple derrière un répartiteur de charge qui ne route que le 443.
Étapes 1 à 3 : préparer le serveur et installer Certbot
Étape 1 : mettre à jour le système et installer Nginx. Commencez par un système à jour, puis installez Nginx si ce n’est pas déjà fait. Un serveur web fonctionnel est indispensable pour le défi HTTP-01.
sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx
sudo systemctl enable --now nginx
nginx -v
# Sortie attendue : nginx version: nginx/1.24.0 (Ubuntu)Étape 2 : ouvrir les ports 80 et 443 dans le pare-feu. Si vous utilisez UFW (le pare-feu par défaut d’Ubuntu), autorisez le profil applicatif Nginx Full, qui couvre les deux ports d’un coup. N’oubliez jamais d’autoriser aussi OpenSSH avant d’activer UFW, sous peine de vous verrouiller hors du serveur.
sudo ufw allow 'Nginx Full'
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status
# Sortie attendue :
# Nginx Full ALLOW Anywhere
# OpenSSH ALLOW AnywhereÉtape 3 : installer Certbot via snap. La documentation officielle recommande snap comme méthode d’installation Linux par défaut, car elle fournit toujours la dernière version de Certbot et la met à jour automatiquement. Évitez le paquet apt install certbot, souvent figé sur une version ancienne dans les dépôts des distributions.
sudo apt install -y snapd
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
certbot --version
# Sortie attendue : certbot 5.6.0Le lien symbolique vers /usr/bin/certbot rend la commande accessible sans chemin complet. Si certbot --version renvoie un numéro de la série 5.x, l’installation est réussie. Le numéro exact évolue, car snap pousse les mises à jour en continu : ce comportement est voulu et garantit que vous bénéficiez des correctifs de sécurité sans rien faire.
Étapes 4 à 6 : configurer Nginx et obtenir le certificat
Étape 4 : créer un bloc serveur pour votre domaine. Certbot a besoin d’un bloc server Nginx contenant la bonne directive server_name pour savoir quel certificat installer. Créez un fichier dédié.
# /etc/nginx/sites-available/exemple.fr
server {
listen 80;
listen [::]:80;
server_name exemple.fr www.exemple.fr;
root /var/www/exemple.fr;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}Activez le site, testez la syntaxe et rechargez Nginx. Le test de configuration est une habitude à prendre avant chaque rechargement : il évite de casser un serveur en production avec une accolade oubliée.
sudo mkdir -p /var/www/exemple.fr
sudo ln -s /etc/nginx/sites-available/exemple.fr /etc/nginx/sites-enabled/
sudo nginx -t
# Sortie attendue : syntax is ok / test is successful
sudo systemctl reload nginxÉtape 5 : lancer Certbot avec le greffon Nginx. Le greffon certbot-nginx automatise tout : il obtient le certificat via HTTP-01, modifie votre bloc serveur pour ajouter les directives TLS et configure la redirection HTTP vers HTTPS. Une seule commande suffit.
sudo certbot --nginx -d exemple.fr -d www.exemple.fr \
--key-type ecdsa \
--agree-tos -m [email protected] --no-eff-email
# Sortie attendue :
# Successfully received certificate.
# Certificate is saved at: /etc/letsencrypt/live/exemple.fr/fullchain.pem
# Key is saved at: /etc/letsencrypt/live/exemple.fr/privkey.pem
# This certificate expires on 2026-09-09.
# Deploying certificate
# Successfully deployed certificate for exemple.frÉtape 6 : choisir le type de clé ECDSA. Le drapeau --key-type ecdsa demande une clé sur courbe elliptique (P-256) plutôt qu’une clé RSA. Les clés ECDSA sont plus courtes, plus rapides à la poignée de main TLS et tout aussi sûres : une clé P-256 offre une sécurité comparable à une RSA 3072 bits, pour une fraction du coût de calcul. Nous comparons les deux familles plus bas. Si vous omettez ce drapeau, Certbot délivre par défaut une clé RSA 2048 bits, parfaitement valable mais moins performante.
Étapes 7 à 8 : vérifier le HTTPS et durcir TLS 1.3
Étape 7 : vérifier que le certificat fonctionne. Ouvrez votre site en HTTPS dans un navigateur : le cadenas doit apparaître. En ligne de commande, OpenSSL confirme la chaîne et la date d’expiration.
echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
| openssl x509 -noout -issuer -subject -dates
# Sortie attendue :
# issuer=C=US, O=Let's Encrypt, CN=R12
# subject=CN=exemple.fr
# notBefore=Jun 11 00:00:00 2026 GMT
# notAfter=Sep 9 23:59:59 2026 GMTPour un audit complet, le service SSL Labs de Qualys note votre configuration de A+ à F. Visez le A+. Un site fraîchement configuré avec Certbot obtient généralement un A, et atteint le A+ après le durcissement de l’étape 8 et l’ajout de l’en-tête HSTS.
Étape 8 : durcir la configuration TLS. Par défaut, Certbot pose une configuration correcte mais générique. Pour un niveau de sécurité optimal, alignez-vous sur le profil « intermediate » du générateur de configuration SSL de Mozilla, qui active TLS 1.2 et TLS 1.3 et désactive les protocoles obsolètes. TLS 1.3, publié en 2018, est désormais le socle recommandé : poignée de main plus rapide (un seul aller-retour), suites de chiffrement réduites aux algorithmes sûrs et confidentialité persistante (forward secrecy) systématique.
# /etc/nginx/snippets/ssl-durci.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
# HSTS : forcer HTTPS pendant 2 ans (a activer une fois le HTTPS stable)
add_header Strict-Transport-Security "max-age=63072000" always;Incluez ce fichier dans votre bloc serveur HTTPS avec include snippets/ssl-durci.conf;, testez avec nginx -t puis rechargez. Attention à l’en-tête HSTS : une fois envoyé avec une longue durée, le navigateur refusera tout accès non chiffré au domaine pendant deux ans. Ne l’activez que lorsque vous êtes certain que tout votre site fonctionne en HTTPS, sous-domaines compris si vous ajoutez includeSubDomains.
Étapes 9 à 11 : automatiser le renouvellement
Étape 9 : vérifier la minuterie systemd. Le paquet snap de Certbot installe automatiquement une minuterie systemd qui tente le renouvellement deux fois par jour. Certbot ne renouvelle effectivement que les certificats à moins de 30 jours de l’expiration, donc cette fréquence n’a aucun coût. Vérifiez qu’elle est bien active.
sudo systemctl list-timers | grep certbot
# Sortie attendue :
# snap.certbot.renew.timer ... snap.certbot.renew.service
sudo systemctl status snap.certbot.renew.timer
# Sortie attendue : Active: active (waiting)Étape 10 : tester le renouvellement à blanc. Ne faites jamais confiance à une automatisation sans la tester. La commande renew --dry-run simule un renouvellement complet contre l’environnement de pré-production de Let’s Encrypt, sans consommer vos quotas ni toucher au certificat réel.
sudo certbot renew --dry-run
# Sortie attendue :
# Congratulations, all simulated renewals succeeded:
# /etc/letsencrypt/live/exemple.fr/fullchain.pem (success)Étape 11 : ajouter un hook de rechargement Nginx. Après un renouvellement, Nginx doit recharger sa configuration pour servir le nouveau certificat. Ajoutez un hook de déploiement qui s’exécute automatiquement à chaque renouvellement réussi. Sur les systèmes sans systemd, une ligne cron remplace la minuterie.
# Hook de rechargement apres renouvellement
echo 'nginx -t && systemctl reload nginx' | sudo tee \
/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
# Alternative cron (systemes sans systemd) :
# 0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"Votre certificat est désormais émis, posé, durci et renouvelé sans intervention. Avec la trajectoire vers 47 jours de validité, cette chaîne d’automatisation est ce qui vous évitera une coupure de service le jour où la durée de vie chutera encore. La même logique de gestion sans intervention s’applique d’ailleurs à d’autres secrets : voyez notre tutoriel sur l’authentification JWT en Node.js pour la rotation des clés applicatives.
Certificat wildcard avec le défi DNS-01
Un certificat wildcard couvre tous les sous-domaines d’un domaine (*.exemple.fr protège blog.exemple.fr, api.exemple.fr, etc.) avec un seul certificat. C’est pratique quand vous créez des sous-domaines régulièrement. La contrepartie : l’émission exige le défi DNS-01, donc la création d’un enregistrement TXT dans votre zone DNS.
En mode manuel, Certbot vous affiche la valeur TXT à publier et attend que vous la posiez chez votre registraire ou hébergeur DNS avant de valider. Voici la commande de base.
sudo certbot certonly --manual --preferred-challenges dns \
-d exemple.fr -d '*.exemple.fr' \
--key-type ecdsa --agree-tos -m [email protected]
# Certbot affiche :
# Please deploy a DNS TXT record under the name:
# _acme-challenge.exemple.fr with the value:
# gFj8...A2Qk (chaine unique a publier)
# Press Enter to ContinuePour automatiser entièrement le wildcard, utilisez un greffon DNS adapté à votre fournisseur (par exemple certbot-dns-ovh, certbot-dns-cloudflare ou certbot-dns-gandi). Le greffon crée et supprime l’enregistrement TXT via l’API du fournisseur, ce qui permet un renouvellement sans intervention même pour un wildcard. Stockez le jeton d’API dans un fichier en lecture seule pour root (chmod 600) et ne le versionnez jamais dans Git.
Rediriger tout le trafic HTTP vers HTTPS
Obtenir un certificat ne suffit pas : il faut forcer chaque visiteur sur la version chiffrée du site. Si vous avez lancé Certbot avec le greffon --nginx, il vous a proposé d’ajouter automatiquement la redirection. Si vous avez choisi certonly ou décliné l’option, voici comment poser une redirection 301 propre et permanente. La redirection 301 (et non 302) indique aux navigateurs et à Google que le changement est définitif, ce qui transfère le « jus de référencement » de l’ancienne URL HTTP vers la nouvelle URL HTTPS.
# Bloc HTTP : ne sert qu'a rediriger vers HTTPS
server {
listen 80;
listen [::]:80;
server_name exemple.fr www.exemple.fr;
# Laisser passer le defi ACME pour les renouvellements
location /.well-known/acme-challenge/ {
root /var/www/exemple.fr;
}
location / {
return 301 https://$host$request_uri;
}
}Le détail crucial est le bloc location /.well-known/acme-challenge/. Sans lui, votre redirection 301 intercepterait aussi les requêtes de validation HTTP-01 lors des futurs renouvellements, et Certbot échouerait avec une erreur « Invalid response ». En laissant ce chemin passer en clair, vous préservez à la fois la sécurité (tout le reste bascule en HTTPS) et la capacité de renouveler automatiquement. Testez la redirection avec curl -I http://exemple.fr : vous devez voir HTTP/1.1 301 Moved Permanently suivi d’un en-tête Location en https.
Vérifiez enfin l’absence de contenu mixte (mixed content), c’est-à-dire des ressources (images, scripts, feuilles de style) encore chargées en HTTP sur une page HTTPS. Le navigateur les bloque ou affiche un cadenas barré. La console développeur de Chrome (onglet Console) liste chaque ressource fautive. Sur WordPress, l’extension « Really Simple SSL » ou une simple réécriture d’URL dans la base corrige ces appels résiduels. Un site avec du contenu mixte perd le bénéfice visuel du certificat, même si celui-ci est parfaitement valide.
RSA vs ECDSA : quelle clé choisir en 2026
Le choix du type de clé revient régulièrement. Voici les éléments objectifs pour trancher. ECDSA est le choix moderne par défaut, RSA reste le filet de sécurité pour la compatibilité maximale avec de très vieux clients.
| Critère | RSA 2048 | ECDSA P-256 |
|---|---|---|
| Sécurité équivalente | 112 bits | 128 bits |
| Taille de clé | 2048 bits | 256 bits |
| Vitesse poignée de main | Référence | Plus rapide |
| Charge CPU serveur | Plus élevée | Réduite |
| Compatibilité clients | Universelle | Très large (sauf clients antérieurs à 2015) |
| Recommandation 2026 | Repli compatibilité | Choix par défaut |
Pour la quasi-totalité des sites web grand public, ECDSA P-256 est le bon choix : meilleures performances, empreinte mémoire réduite et sécurité supérieure. RSA ne se justifie que si vous devez servir des clients très anciens (terminaux de paiement hérités, vieux Android avant 5.0, certains automates industriels). Sachez que Certbot peut aussi émettre les deux et que Nginx sait servir une clé ECDSA et une clé RSA en parallèle selon ce que négocie le client, au prix d’une configuration plus complexe. Pour la sécurité des clés à long terme face à la menace quantique, consultez notre dossier sur la cryptographie post-quantique.
Déployer le certificat sur WordPress et les CMS
La majorité des sites français tournent sous WordPress, et le passage en HTTPS y demande quelques précautions au-delà du certificat lui-même. Une fois Certbot exécuté et le site accessible en https, trois réglages restent à effectuer côté application pour éviter les boucles de redirection et le contenu mixte.
Premièrement, mettez à jour l’adresse du site dans Réglages, Général : les champs « Adresse web de WordPress » et « Adresse web du site » doivent commencer par https://. Vous pouvez aussi forcer ces valeurs dans wp-config.php, ce qui prime sur la base de données et évite tout retour en arrière accidentel.
// wp-config.php : forcer HTTPS et la prise en charge derriere un proxy
define('WP_HOME', 'https://exemple.fr');
define('WP_SITEURL', 'https://exemple.fr');
// Si WordPress est derriere un reverse proxy ou un CDN (Cloudflare)
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
&& $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}Deuxièmement, réécrivez les anciennes URL stockées dans la base, comme les liens d’images insérés du temps du HTTP. La commande WP-CLI search-replace le fait proprement, en gérant les données sérialisées que les plugins stockent souvent. Faites toujours une sauvegarde de la base avant cette opération, et lancez d’abord un essai à blanc avec --dry-run.
# Essai a blanc puis remplacement reel des URL en base
wp search-replace 'http://exemple.fr' 'https://exemple.fr' --dry-run --all-tables
wp search-replace 'http://exemple.fr' 'https://exemple.fr' --all-tables --skip-columns=guidLe drapeau --skip-columns=guid protège la colonne GUID, qui sert d’identifiant unique aux articles dans les flux RSS et ne doit jamais changer, même après le passage en HTTPS. Troisièmement, attention au cas particulier de Cloudflare ou d’un autre CDN devant votre serveur : si le mode SSL est réglé sur « Flexible », vous obtenez une boucle de redirection infinie. Réglez-le sur « Full (strict) » pour que le trafic soit chiffré de bout en bout, du visiteur jusqu’à votre Nginx, en s’appuyant sur le certificat Let’s Encrypt que vous venez d’installer.
6 erreurs fréquentes à éviter
Piège 1 : fermer le port 80. Le défi HTTP-01 a impérativement besoin du port 80 ouvert. Le fermer « pour la sécurité » bloque l’émission et le renouvellement. Gardez-le ouvert avec une redirection 301 vers HTTPS.
Piège 2 : atteindre la limite de quota. Let’s Encrypt impose un plafond de 50 certificats par domaine enregistré et par semaine, et de 5 certificats en double (même ensemble exact d’identifiants) par semaine. Pendant vos tests, utilisez toujours --dry-run ou l’environnement de pré-production (staging) pour ne pas griller vos quotas avec des essais ratés.
Piège 3 : oublier le hook de rechargement. Sans hook de déploiement, Certbot renouvelle bien le certificat sur le disque, mais Nginx continue de servir l’ancien en mémoire jusqu’au prochain rechargement. Le hook de l’étape 11 corrige cela.
Piège 4 : activer HSTS trop tôt. Poser un en-tête HSTS avec une longue durée avant que le HTTPS soit totalement stable peut rendre votre domaine inaccessible si un problème survient, et ce pendant toute la durée déclarée. Activez-le en dernier, après validation complète.
Piège 5 : installer Certbot via apt. Le paquet apt est souvent figé sur une version ancienne. Préférez snap, qui fournit la dernière version et la met à jour seul. Mélanger les deux méthodes crée des conflits de chemins difficiles à diagnostiquer.
Piège 6 : négliger l’enregistrement AAAA. Si votre domaine possède un enregistrement DNS AAAA (IPv6) mais que votre serveur n’écoute pas en IPv6, Let’s Encrypt tentera la validation sur IPv6 en priorité et échouera. Soit vous configurez Nginx pour écouter en IPv6, soit vous retirez l’enregistrement AAAA.
Dépannage : 8 problèmes Certbot et leurs solutions
| Message d’erreur | Cause probable | Solution |
|---|---|---|
| Timeout during connect (port 80) | Pare-feu ou groupe de sécurité bloque le port 80 | Ouvrir le port 80 entrant, vérifier UFW et le pare-feu cloud |
| DNS problem: NXDOMAIN looking up A | Le domaine ne résout pas vers le serveur | Vérifier l’enregistrement A avec dig +short, attendre la propagation |
| too many certificates already issued | Quota hebdomadaire atteint | Attendre 7 jours ou utiliser le staging pour les tests |
| Challenge failed: Invalid response | Bloc serveur Nginx mal configuré ou redirection interférente | Vérifier server_name, désactiver les redirections sur /.well-known/ |
| could not bind to IPv4 or IPv6 | Un autre service occupe déjà le port | sudo ss -tlnp | grep :80 pour identifier et libérer le port |
| The nginx plugin is not working | Greffon Nginx absent ou Nginx introuvable | Réinstaller via snap, vérifier que nginx est dans le PATH |
| unauthorized: incorrect TXT record | Enregistrement DNS-01 non propagé | Attendre la propagation, vérifier avec dig TXT _acme-challenge.exemple.fr |
| certificate expired après renouvellement | Hook de rechargement manquant | Ajouter le hook deploy de l’étape 11 et recharger Nginx |
Quand un diagnostic résiste, deux réflexes. D’abord, lisez le journal détaillé de Certbot dans /var/log/letsencrypt/letsencrypt.log : il contient la requête ACME complète et la réponse exacte du serveur de validation. Ensuite, basculez en mode bavard avec certbot -v et ajoutez --staging pour itérer sans toucher vos quotas de production. L’environnement de pré-production se comporte comme la production mais délivre des certificats non reconnus par les navigateurs, parfaits pour le débogage.
Astuces avancées pour la production
Surveiller l’expiration avec une sonde externe
L’automatisation peut échouer silencieusement : minuterie désactivée par une mise à jour, hook cassé, quota atteint. Surveillez l’expiration de l’extérieur avec une sonde indépendante du serveur. Un script simple en cron sur une autre machine, ou un service de monitoring TLS, vous alerte si le certificat passe sous 14 jours. Ne dépendez jamais uniquement de l’automatisation locale pour détecter sa propre panne.
# Verifier les jours restants avant expiration
fin=$(openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
| openssl x509 -noout -enddate | cut -d= -f2)
jours=$(( ($(date -d "$fin" +%s) - $(date +%s)) / 86400 ))
echo "Jours restants : $jours"
# Alerter si moins de 14 joursCouvrir plusieurs domaines et gérer le SAN
Un même certificat peut couvrir plusieurs domaines via les SAN (Subject Alternative Names) : répétez simplement le drapeau -d autant de fois que nécessaire. Attention toutefois à la limite de 100 noms par certificat et à la limite de 5 certificats en double par semaine, qui se déclenche si vous demandez à répétition exactement le même ensemble de domaines. Pour les infrastructures à grande échelle, préférez un wildcard à une longue liste de SAN.
Enfin, conservez une sauvegarde du dossier /etc/letsencrypt, qui contient vos clés privées et la configuration de renouvellement. En cas de réinstallation serveur, restaurer ce dossier évite de redemander tous vos certificats et de risquer un dépassement de quota. Chiffrez cette sauvegarde : elle contient des secrets. Pour comprendre les fondations cryptographiques de ces clés, notre guide sur le chiffrement AES-256 et celui sur les signatures numériques complètent utilement la lecture.
FAQ : certificat SSL et Certbot
Le certificat Let’s Encrypt est-il vraiment gratuit ?
Oui, totalement et sans limite de durée. Let’s Encrypt est financé par des dons et des sponsors (Mozilla, EFF, Cisco, Google, et d’autres). Vous ne payez ni l’émission, ni le renouvellement, ni le nombre de certificats, dans la limite des quotas anti-abus.
Pourquoi le certificat n’est-il valable que 90 jours ?
Une durée courte limite la fenêtre d’exploitation en cas de clé compromise et force l’automatisation, plus fiable que le renouvellement manuel annuel. La tendance du secteur va d’ailleurs vers des durées encore plus courtes : 200 jours maximum en mars 2026, puis 47 jours en 2029 pour les certificats commerciaux.
Certbot fonctionne-t-il avec Apache et d’autres serveurs ?
Oui. Certbot dispose d’un greffon Apache (certbot --apache) qui fonctionne sur le même principe que le greffon Nginx. Pour les autres serveurs (HAProxy, Caddy, équilibreurs de charge), utilisez certbot certonly pour obtenir le certificat, puis pointez votre serveur vers les fichiers PEM générés.
Que se passe-t-il si le renouvellement échoue ?
Certbot retente automatiquement deux fois par jour. Comme il commence à renouveler 30 jours avant l’expiration, vous disposez d’une large marge pour corriger un problème. Mettez en place la sonde de surveillance externe décrite dans les astuces avancées pour être alerté si l’échec persiste.
Puis-je sécuriser un sous-domaine sans certificat wildcard ?
Oui, c’est même le cas le plus courant. Ajoutez simplement chaque sous-domaine avec un drapeau -d (par exemple -d exemple.fr -d blog.exemple.fr -d api.exemple.fr). Le wildcard ne devient intéressant que si vous créez fréquemment de nouveaux sous-domaines imprévisibles.
Dois-je encore configurer l’agrafage OCSP ?
Non. Let’s Encrypt a annoncé en 2025 l’abandon progressif de l’OCSP au profit des listes de révocation (CRL). Ne traitez plus l’agrafage OCSP comme un prérequis : votre certificat reste valide et un score A+ reste atteignable sans lui.
ECDSA ou RSA pour un site WordPress classique ?
ECDSA P-256. Tous les navigateurs et appareils sortis après 2015 le prennent en charge, et vous gagnez en performance sur la poignée de main TLS. Ne gardez RSA que si vous savez devoir servir des clients très anciens.
Related Coverage
- HTTPS et TLS expliqués : ce que le cadenas signifie vraiment
- Authentification JWT en Node.js : 12 étapes
- Chiffrement AES-256 en Node.js : 12 étapes
- Cryptographie post-quantique : 50 % du web déjà protégé
- Signatures numériques : fonctionnement et rôle des hachages
- Sécurité en ligne : le guide pratique
Sources et références externes : documentation officielle Certbot (EFF), types de défi ACME (Let’s Encrypt), limites de quota Let’s Encrypt, générateur de configuration SSL Mozilla, CA/Browser Forum.
