Obtenir et installer un certificat TLS

Un site accessible en HTTPS doit présenter un certificat valide pour le nom demandé. Si ce certificat manque, ne couvre pas les deux hôtes ou expire, les visiteurs voient un avertissement et les connexions ne sont plus correctement sécurisées.

Dans cette leçon, vous préparez un certificat pour site.example.test et api.example.test avec Certbot. Ces noms appartiennent ici à un environnement d’exemple : une autorité de certification publique ne délivrera pas de certificat pour des noms réservés en .test. Pour exécuter les commandes d’obtention sur un serveur réel, remplacez-les par des noms de domaine publics que vous contrôlez et qui pointent vers ce serveur.

Ce que fournit un certificat TLS

Un certificat TLS permet au navigateur de vérifier l’identité du serveur et de chiffrer les échanges avec lui. Une autorité de certification valide qu’un demandeur peut obtenir un certificat pour les noms indiqués. Comme les deux hôtes de ce projet sont distincts, le certificat doit couvrir chacun d’eux, même s’ils sont hébergés sur la même machine.

Pour valider la demande, Certbot peut utiliser le challenge HTTP-01 : l’autorité demande un contenu temporaire à une adresse sous le domaine, accessible en HTTP depuis Internet. Il faut donc que chaque nom résolve vers le serveur et que le trafic entrant sur le port 80 puisse atteindre Apache. Une entrée dans le fichier local /etc/hosts sert aux tests de votre poste, mais ne prouve pas publiquement le contrôle du domaine.

Installer Certbot et demander le certificat

Sur Debian ou Ubuntu, le paquet certbot fournit l’outil de demande et de renouvellement. L’intégration python3-certbot-apache permet à Certbot de travailler avec Apache. Ici, vous utilisez le mode certonly --webroot : Certbot valide les noms en déposant un fichier temporaire dans une racine de site, sans lui demander de réécrire les fichiers d’hôtes virtuels.

sudo apt update
sudo apt install certbot python3-certbot-apache
sudo certbot certonly --webroot \
  -w /var/www/application \
  -d site.example.test \
  -d api.example.test

Pour les noms d’exemple en .test, l’autorité publique refuse la validation : ces domaines ne sont pas publiquement validables. Sur un serveur réel, utilisez les noms publics configurés dans le DNS. Après validation réussie, Certbot enregistre les fichiers du certificat sous /etc/letsencrypt/live/<premier-nom>/.

Le paramètre -w désigne la racine utilisée pour le challenge, et chaque option -d ajoute un nom au certificat demandé. Dans cet exemple, les deux noms doivent pouvoir atteindre le contenu de validation servi depuis /var/www/application. Si un nom pointe vers une autre racine, préparez un challenge accessible sous cette racine ou choisissez une méthode de validation adaptée avant la demande.

Après une émission réussie, Certbot indique l’emplacement des fichiers du certificat. Le certificat public et la clé privée sont généralement accessibles sous /etc/letsencrypt/live/site.example.test/, notamment dans fullchain.pem et privkey.pem. La clé privée doit rester protégée : ne la copiez pas dans le répertoire servi aux visiteurs et ne la publiez pas dans le dépôt du projet.

Vérifier le renouvellement automatique

Les certificats ont une durée de validité limitée. Après émission, Certbot installe habituellement un mécanisme de renouvellement automatique fourni par le système, par exemple un minuteur systemd ou une tâche planifiée. La simulation ci-dessous vérifie que le renouvellement peut aboutir sans remplacer le certificat en service ; elle ne prouve pas que le DNS ni l’accès externe resteront disponibles à l’avenir.

sudo certbot certificates
sudo certbot renew --dry-run

La première commande répertorie les certificats connus et leurs dates d’expiration. La simulation affiche un résultat de renouvellement réussi si la configuration et les conditions de validation sont correctes ; aucune émission réelle n’est effectuée.

Si la simulation échoue, lisez le message de Certbot avant toute modification : il peut signaler un échec de résolution DNS, une connexion impossible ou un challenge inaccessible. Corrigez le prérequis concerné, puis relancez le test. Ne supprimez pas le certificat existant pour tenter de contourner un échec de renouvellement.

À ce stade, vous avez préparé l’obtention du certificat et la vérification de son renouvellement. La configuration de l’hôte HTTPS et les chemins du certificat seront utilisés dans la leçon suivante, consacrée à la redirection du trafic HTTP vers HTTPS ; vous ne modifiez pas encore les fichiers d’hôtes virtuels dans cette leçon.

À retenir

• Un certificat doit inclure tous les noms d’hôte que les visiteurs utilisent.
• Le challenge HTTP-01 exige des noms publiquement validables et un accès HTTP au serveur.
• Certbot peut obtenir le certificat sans réécrire les fichiers d’hôtes virtuels avec le mode webroot.
• Protégez la clé privée et vérifiez le renouvellement avec sudo certbot renew --dry-run.