Introduction

Sécuriser un site avec HTTPS n’est plus une option. Que vous hébergiez un blog, un site vitrine, une application métier ou un sous-domaine d’administration, un certificat TLS valide est aujourd’hui indispensable pour chiffrer les échanges, rassurer les visiteurs et éviter les alertes du navigateur.

Sur un serveur Debian + Nginx, le duo Let’s Encrypt + Certbot est l’une des solutions les plus simples pour obtenir, installer et renouveler des certificats gratuitement. Encore faut-il comprendre le rôle de chaque composant, choisir la bonne méthode d’installation, mettre en place un renouvellement automatique propre et savoir quoi faire si un challenge échoue.

Ce guide a été pensé pour être généraliste, concret et réutilisable sur un VPS ou un serveur dédié Debian avec Nginx. Il couvre :

  • ce qu’est Let’s Encrypt et pourquoi l’utiliser ;
  • ce qu’est Certbot et à quoi il sert ;
  • l’installation de Certbot ;
  • la création d’un certificat ;
  • l’ajout de sous-domaines ;
  • les commandes utiles au quotidien ;
  • le renouvellement automatique ;
  • les commandes pour tester, forcer, réémettre, supprimer ou révoquer un certificat ;
  • la maintenance et le dépannage ;
  • un cas pratique de correction d’un renouvellement défaillant ;
  • une FAQ courte en fin d’article.

À retenir

  • Let’s Encrypt permet d’obtenir gratuitement des certificats TLS valides.
  • Certbot automatise la création, l’installation et le renouvellement de ces certificats.
  • Le point le plus important n’est pas seulement d’émettre un certificat, mais de garantir que son renouvellement automatique fonctionne réellement.

Let’s Encrypt, c’est quoi exactement ?

Une autorité de certification gratuite et automatisée

Let’s Encrypt est une autorité de certification (CA) gratuite, automatisée et ouverte. Son rôle est de délivrer des certificats TLS/SSL permettant d’activer HTTPS sur un nom de domaine.

Concrètement, lorsqu’un navigateur se connecte à votre site, le certificat permet :

  • de chiffrer les échanges entre le visiteur et le serveur ;
  • d’authentifier le serveur, c’est-à-dire de prouver au navigateur qu’il parle bien au bon site ;
  • de limiter les risques d’attaque de type man-in-the-middle.

Let’s Encrypt émet principalement des certificats DV (Domain Validation). Cela signifie que l’autorité vérifie que vous contrôlez bien le domaine demandé.

Comment Let’s Encrypt valide un domaine

Le fonctionnement repose sur le protocole ACME. En simplifiant :

  1. le client ACME (par exemple Certbot) demande un certificat ;
  2. Let’s Encrypt demande une preuve de contrôle du domaine ;
  3. le client répond à un ou plusieurs challenges ;
  4. si la validation réussit, le certificat est émis.

C’est ce mécanisme qui explique pourquoi les problèmes de DNS, de port 80, de redirections ou de configuration Nginx peuvent empêcher un renouvellement.

Pourquoi utiliser Let’s Encrypt ?

Les avantages sont clairs :

  • gratuit ;
  • standardisé ;
  • automatisable ;
  • reconnu par les navigateurs ;
  • adapté à la plupart des sites publics.

Pour un administrateur Debian + Nginx, l’intérêt principal est simple : obtenir et maintenir du HTTPS propre sans gérer manuellement des certificats payants ou des procédures complexes.

À retenir

  • Let’s Encrypt est une CA gratuite qui émet des certificats TLS pour les domaines que vous contrôlez.
  • Le certificat sert à chiffrer les échanges et à authentifier le serveur.
  • La validation repose sur des challenges : si le challenge échoue, le certificat ne peut pas être émis ou renouvelé.

Certbot, c’est quoi et à quoi sert-il ?

Le rôle de Certbot

Certbot est un client ACME. C’est lui qui dialogue avec Let’s Encrypt depuis votre serveur.

Son rôle est de :

  • demander un certificat ;
  • prouver que vous contrôlez le domaine ;
  • récupérer le certificat ;
  • l’installer éventuellement dans Nginx ;
  • gérer les renouvellements ;
  • aider à réémettre, supprimer ou révoquer un certificat.

Ce que Certbot peut faire

Selon la commande utilisée, Certbot peut :

  • obtenir et installer un certificat ;
  • obtenir seulement un certificat ;
  • renouveler les certificats proches de l’expiration ;
  • modifier les domaines d’un certificat existant ;
  • supprimer un certificat géré ;
  • révoquer un certificat.

Les principales commandes à connaître

Voici les sous-commandes les plus utiles :

  • certbot ou certbot run : obtient et installe un certificat ;
  • certbot certonly : obtient ou renouvelle un certificat sans l’installer ;
  • certbot renew : renouvelle tous les certificats proches de l’expiration ;
  • certbot certificates : affiche les certificats gérés ;
  • certbot delete : supprime un certificat géré par Certbot ;
  • certbot revoke : révoque un certificat.

À retenir

  • Certbot est l’outil qui pilote la création et la maintenance des certificats.
  • certbot et certbot run installent aussi le certificat, alors que certonly laisse la main sur la configuration.
  • renew sert au cycle automatique normal ; delete et revoke répondent à des besoins différents.

Prérequis avant l’installation

Avant d’installer Certbot et de demander un certificat, vérifiez les points suivants.

Côté serveur

Il vous faut :

  • un serveur Debian ;
  • Nginx installé ;
  • un accès root ou un utilisateur avec sudo ;
  • un ou plusieurs noms de domaine pointant vers le serveur ;
  • un site HTTP déjà joignable sur le port 80 dans le cas le plus courant.

Côté DNS

Le domaine doit pointer correctement vers le serveur. Tant que la résolution DNS est erronée, Let’s Encrypt ne pourra pas valider le challenge pour le domaine visé.

Côté Nginx

Le vhost doit exister et répondre normalement. En pratique, il est préférable d’avoir déjà :

  • un server_name correct ;
  • un site accessible en HTTP ;
  • une configuration Nginx testée avec :
sudo nginx -t

Pourquoi le port 80 est souvent indispensable

Avec les méthodes courantes comme --nginx, --webroot ou --standalone en HTTP-01, la validation du domaine s’appuie généralement sur le port 80. Si ce port est bloqué par le firewall, le reverse proxy ou l’hébergeur, l’émission peut échouer.

À retenir

  • Le domaine doit déjà pointer vers le bon serveur.
  • Nginx doit fonctionner proprement avant même de lancer Certbot.
  • Beaucoup d’échecs viennent d’un détail simple : DNS incorrect, port 80 bloqué ou vhost incomplet.

Installer Certbot sur Debian

Il existe plusieurs façons d’installer Certbot. Sur un serveur Debian + Nginx, les deux approches les plus fréquentes sont :

  1. via snap : méthode fortement recommandée par la documentation Certbot pour la plupart des utilisateurs ;
  2. via les paquets Debian (apt) : méthode simple et intégrée à Debian, mais qui peut fournir une version plus ancienne.

Option 1 — Installer Certbot via snap

Cette méthode est intéressante si vous voulez rester au plus proche des recommandations officielles et profiter d’une version récente de Certbot.

Installer snapd

sudo apt update
sudo apt install snapd

Supprimer un ancien Certbot installé via apt si besoin

sudo apt remove certbot

Installer Certbot

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

Vérifier la version

sudo certbot --version

Option 2 — Installer Certbot via apt

C’est la méthode que beaucoup utilisent naturellement sur Debian.

sudo apt update
sudo apt install certbot python3-certbot-nginx

Puis vérifiez :

sudo certbot --version

Quelle méthode choisir ?

  • Snap : souvent plus à jour, recommandé officiellement par Certbot.
  • Apt : plus “Debian native”, simple à maintenir, mais la version peut être plus ancienne.

Si vous utilisez une version ancienne, gardez en tête qu’une commande disponible dans la documentation récente n’est pas forcément présente sur votre serveur.

Mettre Certbot à jour

La mise à jour dépend de la méthode d’installation :

  • si vous utilisez apt :
sudo apt update
sudo apt install --only-upgrade certbot python3-certbot-nginx
  • si vous utilisez l’installation Python/venv officielle alternative :
sudo /opt/certbot/bin/pip install --upgrade certbot certbot-nginx
  • si vous utilisez snap : les snaps sont généralement gérés automatiquement par snapd. Vous pouvez tout de même vérifier l’état de l’environnement snap selon votre politique de maintenance.

À retenir

  • La documentation Certbot recommande fortement le snap pour la plupart des usages.
  • L’installation via apt reste très pratique sur Debian, mais peut fournir une version plus ancienne.
  • La version installée compte : certaines fonctionnalités récentes ne sont pas disponibles partout.

Créer un premier certificat avec Nginx

Méthode simple : Certbot modifie Nginx automatiquement

La commande la plus simple est :

sudo certbot --nginx

Cette commande demande un certificat et modifie automatiquement la configuration Nginx pour activer HTTPS.

C’est pratique si :

  • vous avez une configuration Nginx standard ;
  • vous voulez aller vite ;
  • vous acceptez que Certbot touche au vhost.

Méthode plus prudente : obtenir seulement le certificat

Si vous préférez garder la main sur la configuration Nginx, utilisez :

sudo certbot certonly --nginx

Cette commande obtient le certificat sans effectuer toute l’installation automatique côté Nginx.

C’est souvent une bonne option si :

  • vous gérez vous-même vos fichiers Nginx ;
  • vous avez une configuration personnalisée ;
  • vous voulez distinguer clairement la partie “émission du certificat” de la partie “configuration du serveur”.

Exemple explicite avec domaines

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

Vérifier que le certificat existe bien

Après émission, contrôlez :

sudo certbot certificates

Vous verrez notamment :

  • le nom du certificat ;
  • les domaines couverts ;
  • le chemin du certificat ;
  • la date d’expiration.

À retenir

  • sudo certbot --nginx est le chemin le plus simple pour démarrer.
  • sudo certbot certonly --nginx est préférable si vous voulez garder la main sur Nginx.
  • Après chaque création, vérifiez toujours le résultat avec certbot certificates.

Comprendre où Certbot stocke les certificats

Certbot organise ses fichiers dans /etc/letsencrypt/.

Le dossier live

Exemple :

/etc/letsencrypt/live/exemple.com/

C’est ici que se trouvent les liens symboliques vers les fichiers actifs :

  • fullchain.pem
  • privkey.pem
  • chain.pem
  • cert.pem

C’est généralement ce que Nginx référence.

Le dossier archive

Exemple :

/etc/letsencrypt/archive/exemple.com/

Il contient les différentes versions générées au fil du temps. Certbot y conserve l’historique des certificats et des clés.

Le dossier renewal

Exemple :

/etc/letsencrypt/renewal/exemple.com.conf

Ce fichier contient la configuration de renouvellement de la “lineage” du certificat : méthode utilisée, options importantes, type de clé, etc.

Pourquoi il faut éviter de modifier ces fichiers à la main

Il est tentant de corriger directement un fichier dans /etc/letsencrypt/renewal/, mais c’est généralement une mauvaise idée. Une modification manuelle peut casser le comportement futur de certbot renew.

La bonne approche consiste plutôt à :

  • corriger via une commande Certbot adaptée ;
  • tester avec --dry-run ;
  • vérifier ensuite que le fichier de renewal a bien été mis à jour proprement.

À retenir

  • live = ce que le serveur utilise réellement.
  • archive = historique des versions.
  • renewal = mémoire de la configuration de renouvellement.
  • Évitez les modifications manuelles directes dans renewal sauf cas très particulier et parfaitement maîtrisé.

Ajouter un sous-domaine à un certificat existant

Le principe

Un certificat peut couvrir plusieurs noms :

  • exemple.com
  • www.exemple.com
  • blog.exemple.com
  • api.exemple.com

Pour ajouter un sous-domaine à un certificat existant, il faut être explicite et relister tous les domaines que le certificat doit conserver.

Méthode recommandée avec --cert-name

sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   -d blog.exemple.com

Ici, le certificat nommé exemple.com est mis à jour pour couvrir aussi blog.exemple.com.

Attention à ne pas oublier les domaines déjà présents

Si vous oubliez un domaine existant en refaisant la commande, le certificat final pourra ne plus le contenir.

Cas courant

Vous avez déjà un certificat pour :

  • exemple.com
  • www.exemple.com

et vous voulez ajouter admin.exemple.com :

sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   -d admin.exemple.com

À retenir

  • Pour modifier les domaines d’un certificat existant, mieux vaut utiliser --cert-name.
  • Relistez explicitement tous les domaines que vous voulez conserver.
  • Une modification de domaines doit toujours être testée et vérifiée ensuite.

Les commandes utiles à connaître au quotidien

Cette section regroupe les commandes les plus utiles dans un usage réel.

Vérifier la version de Certbot

sudo certbot --version

Voir les certificats gérés

sudo certbot certificates

Tester un renouvellement sans rien casser

sudo certbot renew --dry-run

Renouveler les certificats proches de l’expiration

sudo certbot renew

Renouveler un certificat précis

sudo certbot renew --cert-name exemple.com

Forcer le renouvellement d’un certificat précis

sudo certbot renew --cert-name exemple.com --force-renewal

Réémettre proprement un certificat avec Nginx

sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   --dry-run

Puis :

sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   --force-renewal

Vérifier l’automatisation Certbot

sudo systemctl status certbot.timer
sudo systemctl list-timers | grep certbot

Lire les derniers logs du service

sudo journalctl -u certbot.service -n 50 --no-pager

Lire le log détaillé de Certbot

sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log
sudo ls -lh /var/log/letsencrypt/

Supprimer un certificat

sudo certbot delete --cert-name exemple.com

Révoquer un certificat

sudo certbot revoke --cert-name exemple.com

À retenir

  • certbot certificates, certbot renew --dry-run et journalctl couvrent déjà une grande partie des besoins.
  • Faites bien la différence entre tester, renouveler, forcer et réémettre.
  • Avant toute correction, regardez ce que Certbot voit réellement et ce que les logs racontent.

Le renouvellement automatique : comment ça fonctionne

Pourquoi les certificats doivent être renouvelés

Un certificat Let’s Encrypt a une durée de vie limitée. L’idée n’est pas d’émettre un certificat “pour toujours”, mais de le renouveler automatiquement avant son expiration.

Le rôle de certbot renew

La commande :

sudo certbot renew

vérifie tous les certificats gérés par Certbot et tente de renouveler ceux qui sont assez proches de l’expiration.

Elle est conçue pour être lancée automatiquement et régulièrement.

Le test indispensable

Pour vérifier que l’automatisation fonctionnera, la commande la plus utile est :

sudo certbot renew --dry-run

Si ce test passe, vous avez un bon indicateur que le renouvellement réel fonctionnera lui aussi.

Cron ou timer systemd ?

Selon votre installation, l’automatisation peut être gérée :

  • via cron ;
  • via un timer systemd.

Pour vérifier :

sudo systemctl list-timers | grep certbot
sudo systemctl status certbot.timer
grep -R "certbot" /etc/cron* 2>/dev/null

Éviter les doublons

Une erreur classique consiste à avoir deux automatisations en parallèle, par exemple :

  • un certbot.timer actif ;
  • et un cron manuel ajouté en plus.

Ce n’est pas toujours dramatique, mais cela complique l’analyse des logs et peut créer de la confusion. Dans la plupart des cas, une seule automatisation propre suffit.

Savoir si le renouvellement a réellement tenté quelque chose

Un point souvent mal compris : certbot renew peut retourner un statut correct même si aucun certificat n’avait besoin d’être renouvelé. Pour savoir ce qui s’est réellement passé, il faut lire :

  • journalctl -u certbot.service
  • le log /var/log/letsencrypt/letsencrypt.log

À retenir

  • Le renouvellement automatique est le cœur de la maintenance HTTPS avec Certbot.
  • Testez toujours avec sudo certbot renew --dry-run.
  • Gardez une seule automatisation claire : timer systemd ou cron, mais pas les deux en doublon.

Forcer un renouvellement ou réémettre un certificat

Différence entre renew et certonly --force-renewal

Ces commandes ne servent pas exactement au même besoin.

renew

sudo certbot renew
  • sert au cycle normal ;
  • agit sur les certificats proches de l’expiration ;
  • réutilise la configuration mémorisée par Certbot.

renew --force-renewal

sudo certbot renew --cert-name exemple.com --force-renewal
  • force un renouvellement même si le certificat n’est pas encore proche de l’expiration ;
  • utile dans certains cas précis ;
  • à éviter comme routine inutile.

certonly --force-renewal

sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   --force-renewal
  • réémet explicitement le certificat avec la méthode choisie ;
  • utile pour remettre à plat un cas où la méthode de renouvellement mémorisée n’est plus la bonne ;
  • très pratique pour passer proprement à --nginx si une ancienne config ambiguë traîne.

Quand forcer un renouvellement ?

Quelques cas légitimes :

  • changement de méthode de validation ;
  • modification importante des domaines ;
  • correction d’une configuration persistée incohérente ;
  • besoin de régénérer immédiatement un certificat propre.

Prudence

Un --force-renewal ne doit pas être utilisé tous les jours. Il faut le réserver aux cas où il a un vrai sens technique.

À retenir

  • renew = cycle normal.
  • renew --force-renewal = renouvellement forcé.
  • certonly --force-renewal = réémission plus explicite, souvent plus propre pour corriger un cas particulier.

Maintenance courante d’un serveur Debian + Nginx avec Certbot

La maintenance ne consiste pas à relancer Certbot au hasard. Elle consiste surtout à vérifier que tout reste sain.

Vérifications régulières utiles

sudo certbot --version
sudo certbot certificates
sudo certbot renew --dry-run
sudo systemctl status certbot.timer
sudo journalctl -u certbot.service -n 50 --no-pager

Vérifier Nginx après un changement

Après une modification de configuration, pensez à :

sudo nginx -t
sudo systemctl reload nginx

Faire des mises à jour raisonnables

  • si Certbot est installé via apt, gardez les paquets à jour ;
  • si vous utilisez la méthode Python/venv, appliquez les mises à jour prévues ;
  • si vous utilisez le snap, surveillez que votre environnement snap est sain.

Garder une configuration simple

Plus votre configuration est simple, plus le renouvellement est prévisible :

  • un seul mécanisme d’automatisation ;
  • pas de mélange inutile entre webroot, nginx et standalone ;
  • pas de modifications manuelles dispersées dans les fichiers de renewal.

À retenir

  • La meilleure maintenance est préventive.
  • Un --dry-run ponctuel et la lecture des logs valent mieux qu’un bricolage en urgence le jour de l’expiration.
  • Une configuration simple est plus robuste qu’un empilement de correctifs.

Dépannage : que faire quand le renouvellement échoue ?

Le message classique : Some challenges have failed

C’est l’un des messages les plus fréquents. Il signifie que Certbot a bien tenté une validation, mais que Let’s Encrypt n’a pas pu valider le domaine demandé.

Ce message est générique. Il faut aller plus loin pour comprendre la vraie cause.

Les causes fréquentes

Voici les causes les plus courantes :

  • DNS incorrect ou propagation incomplète ;
  • port 80 inaccessible ;
  • vhost Nginx erroné ;
  • redirection mal gérée ;
  • challenge /.well-known/acme-challenge/ bloqué ;
  • mélange entre une ancienne méthode webroot et une nouvelle méthode nginx ;
  • sous-domaine non configuré côté Nginx alors qu’il est demandé dans le certificat.

Les bons réflexes

Commencez toujours par :

sudo journalctl -u certbot.service -n 50 --no-pager
sudo tail -n 200 /var/log/letsencrypt/letsencrypt.log

Puis vérifiez :

sudo certbot certificates
sudo nginx -t

Si besoin, regardez aussi le fichier de renewal :

sudo cat /etc/letsencrypt/renewal/exemple.com.conf

Ce qu’il faut chercher dans les logs

Les indices les plus utiles sont souvent :

  • unauthorized
  • invalid response
  • 404
  • 403
  • timeout
  • connection refused

Toujours finir par un test

Après correction :

sudo certbot renew --dry-run

À retenir

  • Some challenges have failed est un symptôme, pas une explication.
  • Les logs Certbot et journalctl sont la source de vérité.
  • Après chaque correction, terminez toujours par un --dry-run.

Cas pratique : corriger un renouvellement automatique défaillant

Voici un cas très réaliste.

Le symptôme

Vous avez :

  • un certificat encore valide ;
  • un renouvellement automatique qui échoue plusieurs jours de suite ;
  • un message du type :
Failed to renew certificate ... with error: Some challenges have failed.

Le diagnostic

Les bons réflexes sont :

sudo journalctl -u certbot.service --since "3 days ago"
sudo tail -n 200 /var/log/letsencrypt/letsencrypt.log
sudo certbot certificates

En lisant les logs, vous pouvez découvrir par exemple que :

  • les renouvellements automatiques passent en webroot ;
  • mais votre renouvellement manuel réussi passe en nginx ;
  • le challenge Let’s Encrypt retourne un 403 sur /.well-known/acme-challenge/....

Dans ce type de situation, le problème n’est pas forcément Nginx lui-même. Le vrai souci peut être une configuration de renouvellement persistée de façon ambiguë.

La correction

  1. vérifier qu’il n’y a pas plusieurs automatismes en doublon ;
  2. tester une réémission propre avec nginx :
sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   --dry-run
  1. si le test passe, appliquer réellement :
sudo certbot certonly --nginx   --cert-name exemple.com   -d exemple.com   -d www.exemple.com   --force-renewal
  1. vérifier ensuite le fichier de renewal :
sudo cat /etc/letsencrypt/renewal/exemple.com.conf

Vous voulez y voir une configuration cohérente, par exemple avec :

authenticator = nginx
installer = nginx
  1. finir par un contrôle global :
sudo certbot renew --dry-run

Le résultat attendu

  • le certificat est réémis proprement ;
  • la configuration de renewal est cohérente ;
  • les tests de renouvellement repassent ;
  • l’automatisation redevient saine.

À retenir

  • Un renouvellement qui échoue plusieurs fois n’est pas un hasard : il faut lire les logs.
  • Une réémission propre avec certonly --nginx --force-renewal peut remettre à plat une config ambiguë.
  • Une fois corrigé, le vrai test de validation reste sudo certbot renew --dry-run.

Révoquer ou supprimer un certificat

Révoquer un certificat

La révocation sert surtout en cas d’incident de sécurité, par exemple si vous soupçonnez une compromission de la clé privée.

sudo certbot revoke --cert-name exemple.com

Selon le contexte, vous pouvez aussi préciser une raison.

Supprimer un certificat

Si un certificat n’est plus utile, supprimez-le proprement :

sudo certbot delete --cert-name exemple.com

Ce qu’il ne faut pas faire

N’allez pas supprimer brutalement des fichiers dans :

/etc/letsencrypt/live/
/etc/letsencrypt/archive/
/etc/letsencrypt/renewal/

sans passer par Certbot.

Avant toute suppression, vérifiez aussi que Nginx n’utilise plus le certificat concerné, sinon un reload ou un restart Nginx pourra échouer.

À retenir

  • Révocation et suppression ne sont pas la même chose.
  • Révocation = incident de sécurité ou invalidation anticipée.
  • Suppression = ménage dans les certificats gérés.
  • Ne supprimez pas les fichiers Certbot à la main.

Les erreurs à éviter

1. Multiplier les automatisations

Évitez d’avoir :

  • un certbot.timer actif ;
  • plus un cron manuel ;
  • plus un autre script maison.

2. Forcer des renouvellements sans raison

--force-renewal est utile, mais ce n’est pas une commande de routine.

3. Modifier les fichiers de renewal à la main

C’est parfois tentant, mais cela peut casser la logique de Certbot.

4. Mélanger les méthodes sans raison

Par exemple :

  • un certificat initial en webroot ;
  • des réparations ensuite en nginx ;
  • puis un autre script en standalone.

Plus vous mélangez, plus le diagnostic devient difficile.

5. Corriger sans tester

Après toute modification :

sudo certbot renew --dry-run

À retenir

  • La plupart des pannes “mystérieuses” sont liées à une configuration devenue trop confuse.
  • Un seul mécanisme propre vaut mieux que plusieurs solutions partielles.
  • Après toute intervention, testez.

La routine recommandée pour un serveur Debian + Nginx

Voici une routine simple et robuste.

À la mise en place

  1. installer Certbot proprement ;
  2. créer le certificat avec --nginx ou certonly --nginx ;
  3. vérifier Nginx et les certificats ;
  4. contrôler l’automatisation ;
  5. lancer un --dry-run.

Ensuite, de temps en temps

sudo certbot certificates
sudo certbot renew --dry-run
sudo systemctl status certbot.timer
sudo journalctl -u certbot.service -n 50 --no-pager

En cas de panne

  1. lire les logs ;
  2. identifier la méthode réellement utilisée ;
  3. corriger proprement ;
  4. refaire un --dry-run.

À retenir

  • Installer proprement, automatiser proprement, vérifier régulièrement.
  • Les commandes de diagnostic doivent rester simples et connues.
  • Le meilleur moment pour corriger un problème de renouvellement est avant l’expiration du certificat.

Encadré final : les commandes utiles à garder sous la main

sudo certbot --version
sudo certbot certificates
sudo certbot renew --dry-run
sudo certbot renew
sudo certbot renew --cert-name exemple.com
sudo certbot renew --cert-name exemple.com --force-renewal
sudo certbot certonly --nginx --cert-name exemple.com -d exemple.com -d www.exemple.com --dry-run
sudo certbot certonly --nginx --cert-name exemple.com -d exemple.com -d www.exemple.com --force-renewal
sudo certbot delete --cert-name exemple.com
sudo certbot revoke --cert-name exemple.com
sudo systemctl status certbot.timer
sudo systemctl list-timers | grep certbot
sudo journalctl -u certbot.service -n 50 --no-pager
sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log
sudo nginx -t

FAQ courte

Certbot renouvelle-t-il automatiquement les certificats ?

Oui, à condition que l’automatisation soit bien en place via cron ou timer systemd et que la configuration de renouvellement soit saine.

Quelle est la commande la plus utile pour vérifier que tout fonctionne ?

La commande la plus utile est :

sudo certbot renew --dry-run

Peut-on avoir plusieurs automatisations en parallèle ?

C’est possible, mais déconseillé. En pratique, mieux vaut n’en garder qu’une seule pour éviter les doublons et la confusion.

Quelle différence entre renew et certonly --force-renewal ?

renew gère le cycle normal de renouvellement. certonly --force-renewal sert plutôt à réémettre proprement un certificat dans un cas particulier.

Peut-on supprimer un certificat en effaçant simplement les fichiers ?

Non. Il vaut mieux utiliser certbot delete et vérifier avant cela que Nginx n’utilise plus le certificat.

Que faire si Some challenges have failed apparaît ?

Lire les logs, vérifier DNS, port 80, configuration Nginx, méthode de validation réellement utilisée et refaire un --dry-run après correction.

Conclusion

Let’s Encrypt et Certbot rendent la gestion HTTPS beaucoup plus simple sur un serveur Debian + Nginx, à condition de respecter quelques principes :

  • une installation propre ;
  • une méthode claire ;
  • une automatisation unique ;
  • des vérifications régulières ;
  • des logs lus avant toute décision.

En pratique, la plupart des problèmes sérieux ne viennent pas de Certbot “en lui-même”, mais d’une configuration devenue ambiguë ou d’un challenge inaccessible. En gardant une routine simple et de bonnes habitudes de maintenance, vous pouvez avoir une gestion des certificats fiable, propre et durable.