Mettre en place un certificat SSL wildcard avec Let's Encrypt

Lorsque plusieurs services utilisent app.domaine.fr, api.domaine.fr, mail.domaine.fr ou admin.domaine.fr, gérer un certificat TLS distinct pour chaque sous-domaine peut devenir fastidieux. Un certificat wildcard simplifie cette organisation en protégeant tous les sous-domaines directs avec un seul certificat.

Let’s Encrypt permet d’obtenir gratuitement ce type de certificat avec Certbot. Le wildcard est particulièrement utile pour une infrastructure qui crée régulièrement de nouveaux sous-domaines, par exemple une plateforme SaaS, un reverse proxy ou un environnement multi-tenant. Sa mise en place impose toutefois une validation DNS spécifique et quelques précautions de sécurité.

Ce que couvre un certificat wildcard

Un certificat émis pour :

*.domaine.fr

couvre les sous-domaines directs de domaine.fr, notamment :

app.domaine.fr
api.domaine.fr
mail.domaine.fr
client1.domaine.fr

Il ne couvre pas le domaine racine, aussi appelé domaine apex :

domaine.fr

Il ne couvre pas non plus les sous-domaines situés à un niveau supplémentaire :

admin.app.domaine.fr
api.client1.domaine.fr

Pour protéger simultanément le domaine principal et ses sous-domaines directs, il faut demander les deux noms dans le même certificat :

*.domaine.fr
domaine.fr

Le certificat contiendra alors deux identifiants DNS. Cette configuration est généralement la plus pratique pour un site principal accompagné de plusieurs applications ou services.

Le point crucial : le challenge DNS-01 est obligatoire

Let’s Encrypt doit vérifier que vous contrôlez chaque domaine demandé. Pour un certificat classique, Certbot peut utiliser le challenge HTTP-01 en déposant temporairement un fichier sous /.well-known/acme-challenge/.

Cette méthode ne fonctionne pas pour un wildcard. Un certificat *.domaine.fr exige obligatoirement le challenge DNS-01.

La validation consiste à publier un enregistrement TXT dans la zone DNS :

_acme-challenge.domaine.fr

Let’s Encrypt interroge ensuite le DNS public et vérifie que la valeur TXT correspond au jeton fourni par Certbot. Cette procédure prouve que vous contrôlez la zone DNS complète et que vous êtes donc autorisé à demander un certificat couvrant ses sous-domaines.

Deux approches sont possibles :

• créer manuellement l’enregistrement TXT à chaque émission ou renouvellement ;
• laisser Certbot gérer automatiquement cet enregistrement grâce à l’API du fournisseur DNS.

La seconde méthode est recommandée en production.

Prérequis

Avant de commencer, vérifiez que vous disposez des éléments suivants :

• un nom de domaine actif ;
• un accès à sa zone DNS ;
• idéalement, une API proposée par le fournisseur DNS ;
• un serveur Linux avec Certbot installé ;
• les droits administrateur sur le serveur ;
• un pare-feu autorisant ensuite le trafic HTTPS sur le port TCP 443.

L’hébergement du site et la gestion DNS peuvent être assurés par des prestataires différents. Le plugin Certbot doit correspondre au fournisseur qui héberge réellement la zone DNS.

Sur une infrastructure TalCloud, les serveurs sont situés en France et peuvent accueillir un reverse proxy ou plusieurs services web sur stockage NVMe. L’Anti-DDoS Netrix complète la protection réseau, mais ne remplace ni TLS, ni la sécurisation des clés privées, ni une configuration correcte des services exposés. Le support humain peut également accompagner le diagnostic d’un problème de configuration ou de propagation DNS. Les offres VPS démarrent à 4,99 € par mois.

Installer Certbot

Sur Debian ou Ubuntu, Certbot peut être installé depuis les paquets du système :

sudo apt update
sudo apt install certbot

Pour vérifier l’installation :

certbot --version

Certbot peut aussi être distribué par Snap selon la version du système et les recommandations de la distribution. Évitez de mélanger plusieurs méthodes d’installation sur le même serveur, car les chemins, plugins disponibles et mécanismes de mise à jour pourraient différer.

Le plugin DNS doit être installé séparément. Par exemple, pour une zone hébergée chez Cloudflare :

sudo apt install python3-certbot-dns-cloudflare

Pour OVH, le paquet généralement utilisé sur Debian ou Ubuntu est :

sudo apt install python3-certbot-dns-ovh

Confirmez toujours que le paquet existe dans les dépôts de votre version du système.

Méthode A : créer manuellement le TXT

La méthode manuelle fonctionne avec presque tous les fournisseurs DNS, même lorsqu’aucune API compatible n’est disponible.

Lancez Certbot en demandant le wildcard et le domaine apex :

sudo certbot certonly --manual --preferred-challenges dns -d '*.domaine.fr' -d domaine.fr

Les apostrophes autour de *.domaine.fr empêchent le shell d’interpréter l’astérisque.

Certbot affiche alors le nom de l’enregistrement TXT et la valeur à publier. Dans l’interface du fournisseur DNS, créez un enregistrement similaire à celui-ci :

Type: TXT
Name: _acme-challenge
Value: valeur-fournie-par-certbot

Attendez que l’enregistrement soit visible depuis le DNS public avant de valider dans Certbot. La propagation peut être rapide, mais elle dépend du fournisseur et du TTL de la zone.

Lorsque le certificat contient à la fois *.domaine.fr et domaine.fr, Certbot peut demander plusieurs valeurs TXT successives sous le même nom _acme-challenge.domaine.fr. Suivez exactement les indications affichées. Si Certbot demande de conserver une première valeur pendant l’ajout de la seconde, publiez simultanément les deux enregistrements TXT.

Le principal inconvénient est le renouvellement. Les certificats Let’s Encrypt ont une durée de validité de 90 jours et sont normalement renouvelés avant leur expiration, souvent autour de 60 jours après leur émission. Avec le mode manuel, Certbot ne peut pas modifier seul la zone DNS. Il faut donc répéter l’opération régulièrement.

Cette méthode convient pour un test, une migration ponctuelle ou un fournisseur sans API. Elle est contraignante pour un service de production.

Méthode B : automatiser avec un plugin DNS

Avec un plugin DNS, Certbot utilise l’API du fournisseur pour créer puis supprimer automatiquement le TXT de validation. Le certificat peut ainsi être renouvelé sans intervention humaine.

L’exemple suivant utilise Cloudflare. Créez d’abord un token API restreint à la modification DNS de la seule zone concernée. Évitez une clé globale donnant accès à l’ensemble du compte.

Créez ensuite un fichier réservé à l’utilisateur root :

sudo mkdir -p /root/.secrets/certbot
sudo nano /root/.secrets/certbot/cloudflare.ini

Ajoutez le token :

dns_cloudflare_api_token = VOTRE_TOKEN_API

Protégez immédiatement le fichier :

sudo chmod 600 /root/.secrets/certbot/cloudflare.ini

Demandez le certificat :

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  -d '*.domaine.fr' \
  -d domaine.fr

Pour OVH, le principe reste identique, mais le plugin, le format des identifiants et les options changent. La commande utilise notamment --dns-ovh et --dns-ovh-credentials. Les noms exacts des paramètres doivent correspondre au plugin installé.

Un délai de propagation peut être configuré si le fournisseur DNS met du temps à rendre le TXT visible. Avec Cloudflare, par exemple :

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 30 \
  -d '*.domaine.fr' \
  -d domaine.fr

Une fois configurée, cette méthode permet à certbot renew de réutiliser automatiquement le même mécanisme DNS.

Utiliser le certificat

Certbot stocke généralement le certificat et sa clé privée dans :

/etc/letsencrypt/live/domaine.fr/fullchain.pem
/etc/letsencrypt/live/domaine.fr/privkey.pem

Le nom exact du répertoire peut varier si plusieurs certificats similaires existent. Vérifiez-le avec :

sudo certbot certificates

Dans Nginx, chaque bloc serveur concerné peut référencer les mêmes fichiers :

ssl_certificate /etc/letsencrypt/live/domaine.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domaine.fr/privkey.pem;

Apache, HAProxy, Traefik ou un autre reverse proxy peuvent également utiliser ce certificat. Chaque sous-domaine doit néanmoins posséder sa propre configuration DNS et être routé vers le bon service.

Après un renouvellement, le serveur web doit recharger sa configuration pour lire le nouveau certificat. Certbot peut installer un hook de déploiement adapté :

sudo certbot renew --deploy-hook "systemctl reload nginx"

Vérifier le renouvellement automatique

Les installations modernes activent généralement un timer systemd ou une tâche cron qui exécute périodiquement le renouvellement.

Vérifiez le timer :

systemctl list-timers | grep certbot

Testez ensuite toute la procédure sans attendre l’expiration :

sudo certbot renew --dry-run

Avec un plugin DNS correctement configuré, Certbot crée le TXT, réalise la validation, supprime le TXT et simule le renouvellement automatiquement.

Avec la méthode manuelle, le test redemande la création du TXT. Un simple timer ne suffit donc pas à rendre le renouvellement autonome.

Sécuriser les identifiants et la clé privée

Le token API DNS permet de modifier une partie critique de votre domaine. Accordez uniquement les droits nécessaires à l’édition des enregistrements DNS et limitez son accès à la zone concernée.

Le fichier d’identifiants doit appartenir à root, rester protégé avec des permissions 600 et ne jamais être ajouté à Git, copié dans une image de conteneur ou exposé dans des journaux.

Protégez également privkey.pem. Toute personne possédant cette clé peut usurper les services couverts tant que le certificat reste utilisable. En cas de fuite, révoquez le certificat, remplacez la clé et corrigez la source de l’exposition.

Quand éviter un certificat wildcard

Un wildcard n’est pas toujours le meilleur choix. Si vous ne gérez que deux ou trois sous-domaines stables, des certificats individuels obtenus avec HTTP-01 sont souvent plus simples et ne nécessitent aucun accès API au DNS.

Le wildcard concentre aussi le risque. Si sa clé privée est compromise, tous les sous-domaines directs couverts sont concernés. Des certificats séparés limitent l’impact d’une fuite et permettent d’isoler les services sensibles.

Le wildcard devient surtout pertinent lorsque les sous-domaines sont nombreux, dynamiques ou centralisés derrière un reverse proxy correctement sécurisé. Dans ce cas, le challenge DNS-01 automatisé avec un token API à privilèges minimaux offre le meilleur équilibre entre simplicité opérationnelle et fiabilité du renouvellement.