Installer Certbot Apache sur Ubuntu 24.04

Ce que vous allez mettre en place

Un site Apache sur Ubuntu 24.04, accessible en HTTPS avec un certificat Let’s Encrypt gratuit et approuvé par les navigateurs. Certbot délivre le certificat. Un timer systemd le renouvelle automatiquement, sans intervention ultérieure. La commande qui effectue le travail tient sur une ligne. Les problèmes surviennent avant cette ligne : vhost sans ServerName, port 80 fermé par le pare-feu du fournisseur, DNS qui pointe encore vers l’ancien serveur. Ce guide consacre donc l’essentiel de son contenu aux prérequis et indique le message d’erreur exact affiché par chaque erreur de configuration.

Deux précisions sur le périmètre. Si votre serveur web est nginx, le déroulement général est similaire, mais le plugin et les fichiers de configuration diffèrent. Utilisez plutôt la version de ce guide pour nginx. Si le service à sécuriser est réservé au réseau interne, par exemple un panneau d’administration sur une adresse privée ou un serveur de staging que personne d’autre ne consulte, vous n’avez pas besoin d’une autorité de certification. Un certificat autosigné nécessite moins de configuration et fonctionne hors ligne.

Prérequis et trois façons dont la procédure échoue avant même le lancement de Certbot

• Apache doit déjà servir votre site en HTTP simple. Le plugin Apache de Certbot modifie un site existant ; il n’en crée pas. Si vous partez d’un VPS vierge, mettez d’abord en place la pile LAMP sur Ubuntu 24.04, puis revenez ici : ce guide en constitue le chapitre TLS manquant.
• Un domaine public doit disposer d’un enregistrement A pointant vers l’adresse de votre VPS. Le challenge HTTP-01 de Let’s Encrypt signifie que ses serveurs de validation se connectent à votre serveur depuis Internet : pas de homelab derrière NAT sans redirection de port, pas de noms .local, pas d’adresses IP seules. dig +short example.com doit renvoyer l’adresse de votre VPS et, si vous avez modifié le DNS au cours de la dernière heure, attendez l’expiration du TTL de l’ancien enregistrement avant de lancer l’émission.
• Si un enregistrement AAAA existe, il doit être correct. Let’s Encrypt privilégie IPv6 lorsqu’un enregistrement AAAA est publié. Un enregistrement AAAA obsolète fait donc échouer la validation, même si curl fonctionne correctement depuis votre ordinateur portable, probablement en IPv4. Publiez un enregistrement AAAA correct ou n’en publiez aucun.

Les ports 80 et 443 doivent être ouverts dans ufw et dans le firewall réseau de votre fournisseur. La plupart des panneaux d’hébergement disposent d’un second firewall que le système d’exploitation ne voit jamais. HTTP-01 utilise spécifiquement le port 80 pour la validation ; vous ne pouvez pas exécuter cette procédure uniquement sur 443.

sudo ufw allow "Apache Full"
sudo ufw status

Une fois ces conditions réunies, l’ensemble de la procédure prend quinze minutes, dont dix à lire.

Certbot avec snap ou apt ? Sur 24.04, apt convient enfin

Certbot est passé à la distribution snap il y a plusieurs années pour une bonne raison : les paquets des distributions étaient figés. Ubuntu 20.04 fournissait Certbot 0.40 et n’a jamais évolué, et le projet s’est lassé de déboguer des bugs vieux de cinq ans. Sur 24.04, cette raison n’existe plus : l’archive fournit Certbot 2.9.0, une version actuelle, et unattended-upgrades le maintient à jour. Pour ce système d’exploitation, je recommande apt. Vous évitez le daemon snapd, le plugin Apache s’installe dans la même transaction et le timer de renouvellement s’intègre à systemd selon la méthode Debian habituelle.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

Résultat correct : certbot 2.9.0. Le paquet python3-certbot-apache est le plugin qui lit et modifie vos configurations Apache. Sans lui, certbot --apache échoue avec The requested apache plugin does not appear to be installed.

Le snap reste le meilleur choix dans deux cas : vous voulez la version la plus récente de Certbot dès sa publication, ou vous avez besoin d’un plugin DNS distribué uniquement sous forme de snap (c’est le cas de plusieurs plugins des fournisseurs certbot-dns-*). Si vous choisissez cette solution :

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Quel que soit votre choix, n’exécutez jamais les deux. Deux installations signifient deux planificateurs de renouvellement qui se disputent /etc/letsencrypt, et le certbot trouvé par votre shell dans PATH n’est peut-être pas celui qui gère vos certificats. La ligne apt remove ci-dessus n’est pas une simple décoration facultative.

Les vhosts que Certbot modifie doivent déjà exister, le ServerName est déterminant

certbot --apache fonctionne en recherchant le virtual host sur le port 80 dont ServerName ou ServerAlias correspond à chaque domaine -d que vous indiquez. Il prouve ensuite que vous contrôlez le domaine, puis crée une copie SSL de ce vhost. Sans ServerName correspondant, aucune correspondance n’est trouvée. De plus, le 000-default.conf fourni par Ubuntu contient ServerName commenté. Cette seule ligne commentée est la cause la plus fréquente de l’échec de la commande unique de ce guide.

Avant d’utiliser Certbot, configurez donc un vhost basé sur le nom pour le site. Créez /etc/apache2/sites-available/example.com.conf :

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

Activez-le et vérifiez qu’Apache l’analyse correctement et qu’il dirige bien le nom vers ce vhost :

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest doit afficher Syntax OK. S’il affiche également AH00558: apache2: Could not reliably determine the server's fully qualified domain name, il s’agit d’un avertissement concernant le ServerName global, et non votre vhost. Cet avertissement est sans conséquence ici. Vous pouvez le supprimer avec echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

La sortie de -S est le contrôle important. Vous devez obtenir une ligne telle que port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1), avec alias www.example.com en dessous. Apache indique le lien symbolique sites-enabled qu’il a réellement lu, et non le fichier que vous avez modifié dans sites-available. Si example.com n’apparaît pas pour le port 80, Certbot ne le trouvera pas non plus.

Émettre le certificat : certbot --apache

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

La première exécution demande trois éléments : une adresse e-mail (utilisée pour votre compte ACME et les notifications urgentes de l’autorité de certification ; Let’s Encrypt n’envoie plus d’avertissements d’expiration, vous devez donc surveiller vous-même les renouvellements), l’acceptation des conditions d’utilisation de Let’s Encrypt et l’autorisation éventuelle de partager votre adresse e-mail avec l’EFF. La question sur la redirection n’est plus posée : depuis Certbot 2.0, l’installateur Apache redirige par défaut HTTP vers HTTPS, ce qui correspond au comportement recherché. Indiquez --no-redirect uniquement si vous devez réellement continuer à servir du contenu en HTTP non chiffré.

Le résultat doit ressembler à ceci. Lisez-le attentivement au lieu de le parcourir rapidement :

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

Derrière ce message, Certbot a effectué quatre opérations : il a activé le module Apache ssl s’il ne l’était pas déjà, créé example.com-le-ssl.conf, une copie de votre virtual host dans *:443 avec SSLEngine on et les chemins des certificats, activé cette configuration, puis ajouté un bloc RewriteRule au virtual host d’origine sur le port 80 afin de rediriger tout le trafic vers HTTPS avec une réponse 301. Le fichier de votre virtual host d’origine est modifié, et non remplacé. Le fichier SSL associé se trouve à côté et vous permet de lire chaque ligne ajoutée.

Emplacement réel du certificat et raison pour laquelle vous ne devez jamais le copier

Tout est placé sous /etc/letsencrypt/live/example.com/ : fullchain.pem (le certificat et la chaîne intermédiaire, vers lesquels les serveurs doivent pointer), privkey.pem (la clé privée, lisible uniquement par root), ainsi que cert.pem et chain.pem pour les logiciels qui veulent ces éléments séparément. Il s’agit de liens symboliques vers /etc/letsencrypt/archive/. Cette indirection assure le renouvellement : le renouvellement écrit les nouveaux fichiers dans archive/, puis réoriente les liens symboliques. Faites pointer les autres logiciels vers les chemins live/. Ils utiliseront alors automatiquement les certificats renouvelés. Si vous copiez les fichiers ailleurs, vous provoquez une interruption de service 90 days plus tard.

L’autre fichier à connaître est /etc/letsencrypt/renewal/example.com.conf. Il indique comment ce certificat a été émis, authenticator = apache, installer = apache, ainsi que les domaines. Le renouvellement peut ainsi répéter le processus sans intervention, notamment recharger Apache ensuite.

Le renouvellement est déjà planifié : vérifiez-le, ne le recréez pas

Les certificats Let’s Encrypt sont valides pendant 90 jours par conception, et le paquet apt a déjà installé le mécanisme nécessaire : un timer systemd qui exécute Certbot deux fois par jour à des horaires aléatoires et renouvelle tout certificat arrivant à expiration dans les 30 jours. N’ajoutez pas de tâche cron par-dessus. Un second planificateur n’apporte rien, si ce n’est du bruit dans les journaux et une exposition aux limites de débit.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

La première commande affiche le timer actif, avec une heure NEXT située dans les 24 prochaines heures. La planification prévoit deux exécutions quotidiennes avec un délai aléatoire ; l’heure exacte est donc volontairement imprévisible (avec l’installation snap, le timer est snap.certbot.renew.timer à la place). Le dry run effectue une répétition complète du renouvellement auprès de l’environnement staging de Let’s Encrypt, avec un vrai challenge, mais sans émission de certificat ni consommation de limite de débit. Un résultat correct se termine par :

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Si le dry run échoue, le renouvellement réel dans ~60 jours échouera de la même manière. Corrigez le problème maintenant, tant que le certificat actuel dispose encore de toute sa durée de validité. La cause la plus fréquente est une règle de pare-feu ajoutée après l’émission du certificat, qui a de nouveau fermé le port 80.

Vérifier avec curl et contrôler le contenu du cadenas

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

La première commande doit renvoyer HTTP/1.1 301 Moved Permanently avec un en-tête Location: https://example.com/ : il s’agit de la redirection installée par Certbot. La deuxième doit renvoyer HTTP/1.1 200 OK sans avertissement TLS de la part de curl. La troisième affiche l’émetteur, une ligne O = Let's Encrypt avec un CN court comme R12 ou E7, ainsi que notAfter à environ 90 jours. Dans un navigateur, le cadenas s’affiche. En cliquant dessus, vous voyez le même émetteur. Si curl fonctionne mais que le navigateur affiche un avertissement, vous consultez presque certainement une page mise en cache ou le mauvais nom d’hôte, et non un problème de certificat.

Plusieurs sites : un certificat SAN ou un certificat par site

Les deux méthodes fonctionnent et se renouvellent de la même façon. Pour des sites sans lien entre eux sur le même serveur, exécutez la commande d’émission une fois par site. Chaque site possède son propre répertoire sous live/ et sa propre configuration de renouvellement. Un problème avec un domaine ne bloque donc jamais le renouvellement des autres. C’est l’approche que j’utilise par défaut.

Pour un seul site avec plusieurs noms, regroupez-les dans un certificat SAN. Un seul certificat peut contenir jusqu’à 100 noms. Vous l’avez déjà fait plus haut avec example.com et www.example.com. Pour ajouter ultérieurement un nom à un certificat existant, réémettez-le en indiquant le nom du certificat et la liste complète des nouveaux noms :

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot détecte la modification de l’ensemble des domaines, vous demande de confirmer l’extension, puis remplace le certificat sur place, au même emplacement live/. Aucune autre modification n’est donc nécessaire. Notez que la liste remplace la liste précédente : si vous omettez www de cette commande, le nouveau certificat le supprime sans avertissement.

Les wildcards nécessitent DNS-01, et vous n’avez généralement pas besoin d’un wildcard

HTTP-01 ne peut pas émettre *.example.com : placer un fichier sur un serveur web prouve le contrôle d’un seul nom d’hôte, pas celui de tout un espace de noms. Les wildcards nécessitent le challenge DNS-01 : Certbot crée un enregistrement TXT à l’emplacement _acme-challenge.example.com. En pratique, il faut donc un plugin certbot-dns-* avec des identifiants d’API pour votre fournisseur DNS, ou modifier manuellement les enregistrements TXT à chaque renouvellement avec --manual (une solution pénible, sur laquelle il ne faut pas baser votre configuration). Le guide complet, de la gestion des enregistrements TXT jusqu’à un plugin qui renouvelle les certificats sans intervention, se trouve dans certificats wildcard avec Certbot via DNS-01. Conseil pratique : si vous avez quatre sous-domaines connus, un certificat SAN qui les liste tous les quatre est plus simple qu’un wildcard et ne nécessite pas de conserver des clés d’API DNS sur le serveur.

Modes d’échec et messages affichés

Certbot refuse de démarrer parce que la configuration d’Apache est incorrecte.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

Le plugin exécute configtest avant toute autre opération et s’arrête si Apache rencontre une erreur. Les \n sont littéraux, car Certbot affiche la représentation de l’exception. Exécutez vous-même sudo apache2ctl configtest : la commande indique le fichier et la ligne concernés. Il s’agit généralement d’une faute de syntaxe après une modification manuelle, d’un SSLCertificateFile qui pointe vers un chemin inexistant ou d’un module référencé mais non activé. Corrigez la configuration jusqu’à obtenir Syntax OK, puis relancez Certbot.

Aucun vhost ne correspond au domaine.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

Il s’agit de l’erreur liée à l’absence de ServerName mentionnée précédemment, détectée au moment de l’émission. Certbot a recherché, dans tous les vhosts activés sur le port 80, un ServerName/ServerAlias correspondant à votre -d, sans rien trouver. sudo apache2ctl -S affiche le routage réel d’Apache. Ajoutez la ligne ServerName au bon vhost, rechargez Apache, puis réessayez. Un problème proche survient lorsque la validation atteint le mauvais vhost : la réponse au challenge revient Invalid response ... 404 parce qu’un autre site a traité la requête. Le diagnostic et l’outil sont les mêmes : apache2ctl -S.

La validation expire.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let’s Encrypt n’a pas pu établir de connexion TCP vers le port 80 à l’adresse annoncée par votre DNS. Par ordre de probabilité : le pare-feu réseau de votre fournisseur, distinct de ufw et configuré dans le panneau d’hébergement ; un jeu de règles ufw qui n’autorise que 443 ou SSH ; le DNS qui pointe encore vers un ancien serveur ; ou le problème d’AAAA obsolète : leurs serveurs ont essayé IPv6, mais le vôtre ne répond que sur IPv4. Testez depuis l’extérieur du VPS : curl -I http://example.com depuis votre ordinateur portable reproduit ce que voit leur validateur.

Vous avez déclenché une limite de débit en réessayant.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let’s Encrypt autorise 5 validations échouées par nom d’hôte, par compte et par heure. Depuis la refonte des limites de débit en 2025, il s’agit d’un compartiment qui se recharge : vous récupérez environ une tentative toutes les 12 minutes. Réessayer sans cesse avec un pare-feu incorrect le vide rapidement. Attendre fonctionne, mais la vraie correction consiste à modifier votre méthode : après chaque échec, effectuez le diagnostic avec l’environnement staging jusqu’à la réussite.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

Notez le certonly : --dry-run est accepté uniquement par les sous-commandes certonly et renew. La forme simple certbot --apache --dry-run refuse complètement de s’exécuter et affiche --dry-run currently only works with the 'certonly' or 'renew' subcommands. Le dry run effectue la validation auprès de staging, qui dispose de limites généreuses et n’émet aucun certificat réel. Vous pouvez donc y provoquer des échecs toute l’après-midi. Ne relancez la commande réelle qu’après la réussite de staging. Les autres limites — 50 certificats par domaine enregistré et par semaine, 5 doublons du même ensemble de noms par semaine — ne vous concerneront que si un script réémet les certificats en boucle.

Une fois HTTPS fonctionnel, souvenez-vous que le certificat sécurise le transport, pas le serveur : le port 22 reçoit toujours des tentatives de mots de passe toute la journée. Associer cette configuration à Fail2ban sur Ubuntu 24.04 constitue la prochaine étape logique de trente minutes.

FAQ

Dois-je installer Certbot avec snap ou apt pour Apache sur Ubuntu 24.04 ?

Utilisez apt. Ubuntu 24.04 fournit Certbot 2.9.0, une version suffisamment récente pour tout ce qui est présenté dans ce guide. Elle reçoit les correctifs de sécurité via unattended-upgrades et ne nécessite pas snapd. Choisissez snap uniquement si vous avez besoin immédiatement de la dernière version ou d’un plugin DNS distribué exclusivement sous forme de snap. Si vous changez de méthode, apt remove certbot python3-certbot-apache d’abord afin que deux planificateurs de renouvellement ne fonctionnent jamais simultanément.

Pourquoi Certbot indique-t-il « Unable to find a virtual host listening on port 80 » ?

Aucun vhost activé sur le port 80 ne possède de ServerName ou de ServerAlias correspondant au domaine indiqué avec -d. Le vhost par défaut d’Ubuntu fournit ServerName commenté. Exécutez sudo apache2ctl -S, trouvez ou créez le vhost qui doit gérer ce nom, ajoutez ServerName example.com, rechargez Apache, puis relancez Certbot.

Comment corriger « Timeout during connect (likely firewall problem) » ?

Let’s Encrypt n’a pas pu joindre le port 80 à l’adresse publiée par votre DNS. Vérifiez le firewall réseau configuré dans le panneau de votre fournisseur ainsi que ufw. Vérifiez que dig +short example.com renvoie vers ce VPS et supprimez ou corrigez tout enregistrement AAAA obsolète. La validation privilégie IPv6 lorsqu’un tel enregistrement existe. Vérifiez la correction depuis l’extérieur du serveur avec curl -I http://example.com, puis faites un test avec sudo certbot certonly --apache --dry-run -d example.com avant l’émission réelle du certificat.

Certbot renouvelle-t-il automatiquement les certificats sur Ubuntu 24.04 ?

Oui. Le paquet apt installe certbot.timer, un timer systemd qui s’exécute deux fois par jour et renouvelle tout certificat arrivant à expiration dans les 30 jours. Il recharge ensuite Apache. Le snap utilise snap.certbot.renew.timer pour la même tâche. Vérifiez son fonctionnement avec systemctl list-timers certbot.timer et faites un test avec sudo certbot renew --dry-run. N’ajoutez pas votre propre tâche cron en parallèle.

Comment obtenir un certificat wildcard avec Certbot et Apache ?

Les certificats wildcard nécessitent le challenge DNS-01. Certbot doit créer un enregistrement TXT à l’adresse _acme-challenge.example.com. Il faut donc un plugin certbot-dns-* avec des identifiants API pour votre fournisseur DNS. L’alternative --manual nécessite de modifier manuellement les enregistrements TXT à chaque renouvellement. Si vous ne gérez qu’une poignée de sous-domaines connus, un certificat SAN les listant explicitement est plus simple et évite de conserver les clés API DNS sur le serveur.