TL;DR — Résumé Rapide
Certificats SSL wildcard avec Certbot et DNS-01. Couvre les plugins DNS, Cloudflare, renouvellement automatique, limites de débit et dépannage complet.
Les certificats SSL wildcard permettent à un seul certificat de sécuriser chaque sous-domaine de votre domaine — *.example.com couvre api.example.com, app.example.com, staging.example.com et tout autre sous-domaine que vous créez. Au lieu d’émettre des certificats individuels pour chaque service, vous en obtenez un seul que vous déployez sur toute votre infrastructure. Let’s Encrypt fournit des certificats wildcard gratuitement, mais exige le défi DNS-01 pour la validation — une exigence que les défis basés sur HTTP ne peuvent pas satisfaire.
Ce guide couvre tous les aspects de l’obtention et de la maintenance des certificats wildcard avec Certbot : comprendre pourquoi DNS-01 est obligatoire, la validation manuelle, les plugins DNS automatisés, la configuration détaillée de Cloudflare, le renouvellement automatique avec systemd, les SAN multi-domaines, les limites de débit et le dépannage.
Prérequis
Avant de commencer, préparez les éléments suivants :
- Ubuntu 22.04 LTS ou 24.04 LTS (ou tout Linux basé sur Debian) avec accès sudo.
- Un domaine enregistré avec DNS géré par un fournisseur compatible (Cloudflare, AWS Route 53, DigitalOcean, Google Cloud DNS, ou accès manuel à votre zone).
- Certbot installé — ou vous l’installerez ci-dessous.
- Un token API pour votre fournisseur DNS avec la permission de créer et supprimer des enregistrements DNS.
- Le port 80 N’A PAS besoin d’être ouvert pour les défis DNS-01 wildcard (contrairement aux défis HTTP-01).
Pourquoi les Certificats Wildcard ?
Un certificat standard couvre un ou plusieurs noms d’hôtes spécifiques : example.com, www.example.com, api.example.com. Si vous ajoutez un nouveau sous-domaine — metrics.example.com — vous devez soit l’ajouter à la liste SAN et réémettre le certificat, soit en obtenir un nouveau.
Un certificat wildcard (*.example.com) élimine ce problème :
- Un certificat, des sous-domaines illimités — Tout nom d’hôte correspondant à
*.example.comsur un seul niveau est couvert automatiquement. - Gestion simplifiée des certificats — Un processus de renouvellement, une clé privée, un hook de déploiement.
- Fonctionne avec les services internes — Les sous-domaines sans serveurs web publics (APIs internes, interfaces de gestion) sont couverts sans besoin d’accès HTTP.
- Efficacité des coûts — Let’s Encrypt les émet gratuitement. Les certificats wildcard commerciaux des AC traditionnelles coûtent généralement 100–300 $/an.
La seule limitation : les wildcards couvrent exactement un niveau de sous-domaine. *.example.com couvre api.example.com mais pas v1.api.example.com. Pour les sous-domaines imbriqués, ajoutez un second wildcard : *.api.example.com.
Comprendre ACME et le Défi DNS-01
Let’s Encrypt utilise le protocole ACME (RFC 8555) pour automatiser l’émission de certificats. Vous devez prouver le contrôle de votre domaine en complétant un défi.
Pourquoi HTTP-01 Ne Peut Pas Valider les Wildcards
Le défi HTTP-01 place un fichier token à http://example.com/.well-known/acme-challenge/<TOKEN>. Cela fonctionne pour des noms d’hôtes spécifiques avec un serveur web accessible. Mais *.example.com représente un ensemble infini de noms d’hôtes — dont la plupart peuvent ne pas avoir de serveur HTTP. Le serveur ACME n’a aucun moyen de sonder chaque sous-domaine possible, donc HTTP-01 est explicitement interdit pour les certificats wildcard par la spécification ACME.
Comment Fonctionne DNS-01
DNS-01 valide le contrôle du domaine en prouvant que vous pouvez écrire dans la zone DNS :
- Certbot contacte le serveur ACME et demande l’autorisation pour
*.example.com. - Le serveur ACME émet un token et demande la publication d’un enregistrement TXT à
_acme-challenge.example.comavec une valeur spécifique. - Certbot (ou son plugin DNS) crée l’enregistrement TXT via l’API de votre fournisseur DNS.
- Le serveur ACME interroge les résolveurs DNS pour vérifier l’existence de l’enregistrement TXT.
- Une fois validé, le certificat est signé et renvoyé.
- Certbot (ou son plugin) supprime l’enregistrement TXT.
DNS-01 fonctionne même sans serveur web, quand le port 80 est bloqué par un pare-feu et quand le sous-domaine n’a pas d’enregistrement A.
Installation de Certbot
Le paquet snap est la méthode d’installation officiellement maintenue.
# Supprimer tout certbot empaqueté par le système pour éviter les conflits
sudo apt remove certbot -y 2>/dev/null || true
# Installer Certbot via snap
sudo snap install --classic certbot
# Créer un lien symbolique pour que certbot soit dans le PATH
sudo ln -s /snap/bin/certbot /usr/bin/certbot
# Vérifier
certbot --version
Validation DNS Manuelle
Pour un certificat unique ou pour tester, la validation DNS manuelle ne nécessite pas de tokens API.
sudo certbot certonly \
--manual \
--preferred-challenges dns \
-d "*.example.com" \
-d example.com
Certbot affichera quelque chose comme :
Please deploy a DNS TXT record under the name:
_acme-challenge.example.com
with the following value:
gfj9Xq8R3mT2nKp1vLwY5sAqZdBcF7eH
Once deployed, press Enter to continue...
Vérifiez la propagation avant d’appuyer sur Entrée :
dig +short TXT _acme-challenge.example.com
dig @8.8.8.8 +short TXT _acme-challenge.example.com
Note : La validation manuelle ne supporte pas le renouvellement automatique. Certbot vous demandera de recréer l’enregistrement TXT manuellement tous les 60–89 jours. Pour un usage en production, configurez un plugin DNS automatisé.
Plugins DNS Automatisés
| Plugin | Fournisseur | Commande d’installation |
|---|---|---|
certbot-dns-cloudflare | Cloudflare | sudo snap install certbot-dns-cloudflare |
certbot-dns-route53 | AWS Route 53 | sudo snap install certbot-dns-route53 |
certbot-dns-google | Google Cloud DNS | sudo snap install certbot-dns-google |
certbot-dns-digitalocean | DigitalOcean | sudo snap install certbot-dns-digitalocean |
certbot-dns-linode | Linode/Akamai | sudo snap install certbot-dns-linode |
certbot-dns-hetzner | Hetzner DNS | pip install certbot-dns-hetzner |
Configuration Détaillée du Plugin Cloudflare
Étape 1 : Créer un Token API Cloudflare
Connectez-vous au tableau de bord Cloudflare → Mon profil → Tokens API → Créer un token.
Utilisez le modèle “Modifier le DNS de la zone” et configurez :
- Permissions :
Zone→DNS→Modifier - Ressources de zone :
Inclure→Zone spécifique→ sélectionnez votre domaine - Filtrage d’adresse IP : Optionnellement restreignez à l’IP de votre serveur
Étape 2 : Créer le Fichier de Credentials
sudo mkdir -p /etc/letsencrypt/cloudflare
sudo tee /etc/letsencrypt/cloudflare/credentials.ini > /dev/null <<'EOF'
dns_cloudflare_api_token = VOTRE_TOKEN_API_CLOUDFLARE_ICI
EOF
sudo chmod 600 /etc/letsencrypt/cloudflare/credentials.ini
sudo chown root:root /etc/letsencrypt/cloudflare/credentials.ini
Note de sécurité : N’utilisez jamais l’ancienne méthode
dns_cloudflare_email+dns_cloudflare_api_key(Clé API globale). Le token API à portée limitée réduit le risque si le fichier de credentials est exposé.
Étape 3 : Installer le Plugin
sudo snap install certbot-dns-cloudflare
sudo snap set certbot trust-plugin-with-root=ok
sudo snap connect certbot:plugin certbot-dns-cloudflare
Étape 4 : Obtenir le Certificat
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare/credentials.ini \
--dns-cloudflare-propagation-seconds 60 \
-d example.com \
-d "*.example.com" \
--email admin@example.com \
--agree-tos \
--non-interactive
Étape 5 : Vérifier le Certificat
sudo certbot certificates
Emplacement des Fichiers du Certificat
| Fichier | Chemin | Objectif |
|---|---|---|
| Chaîne complète | /etc/letsencrypt/live/example.com/fullchain.pem | Certificat + AC intermédiaire (utiliser dans Nginx/Apache) |
| Clé privée | /etc/letsencrypt/live/example.com/privkey.pem | Clé privée — à protéger soigneusement |
| Chaîne seule | /etc/letsencrypt/live/example.com/chain.pem | Chaîne AC intermédiaire uniquement |
| Certificat seul | /etc/letsencrypt/live/example.com/cert.pem | Certificat de domaine sans chaîne |
Configurez Nginx pour utiliser le certificat wildcard :
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name *.example.com example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}
Renouvellement Automatique avec systemd
Certbot installe automatiquement un timer systemd lors de l’installation via snap ou apt.
Vérifier le Timer
sudo systemctl status certbot.timer
sudo systemctl list-timers certbot.timer
Ajouter un Hook de Déploiement pour Nginx
sudo bash -c 'cat >> /etc/letsencrypt/renewal/example.com.conf <<EOF
[renewalparams]
deploy_hook = systemctl reload nginx
EOF'
Tester le Renouvellement
sudo certbot renew --dry-run
Wildcards Multi-Domaines
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare/credentials.ini \
-d example.com \
-d "*.example.com" \
-d staging.example.net \
-d "*.staging.example.net"
*.example.com ne couvre PAS *.api.example.com. Chaque niveau nécessite une entrée wildcard séparée.
Limites de Débit
| Limite | Valeur | Fenêtre |
|---|---|---|
| Certificats par domaine enregistré | 50 | 7 jours |
| Certificats en double | 5 | 7 jours |
| Validations échouées | 5 | 1 heure |
| Nouvelles commandes | 300 | 3 heures |
Tests avec l’Environnement de Staging
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare/credentials.ini \
--staging \
-d example.com \
-d "*.example.com"
Une fois la configuration vérifiée, supprimez le certificat de staging et obtenez un certificat de production :
sudo certbot delete --cert-name example.com
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare/credentials.ini \
-d example.com \
-d "*.example.com"
Certbot vs Alternatives
| Outil | Wildcard | DNS Auto | Let’s Encrypt | Autres AC | Notes |
|---|---|---|---|---|---|
| Certbot | Oui (plugins) | Par plugin | Oui | Limité | Client officiel EFF, écosystème le plus large |
| acme.sh | Oui | Intégré (150+) | Oui | Oui | Bash uniquement, sans dépendances, portable |
| Caddy | Oui (natif) | Automatique | Oui | Oui | Sans configuration ; module DNS à compiler |
| Traefik | Oui (natif) | Automatique | Oui | Limité | Idéal pour les environnements de conteneurs |
| AC Commerciale | Oui | Non (manuel) | Non | Oui | 100–300 $/an, options OV/EV |
Dépannage des Erreurs Courantes
Enregistrement CAA Bloquant l’Émission
Symptôme : Error: CAA record for example.com prevents issuance
dig +short CAA example.com
Si aucune entrée pour Let’s Encrypt n’existe, ajoutez-en une :
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
La balise issuewild est spécifiquement requise pour l’autorisation des certificats wildcard.
Délais de Propagation DNS
Symptôme : DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com
Augmentez le délai d’attente de propagation :
--dns-cloudflare-propagation-seconds 120
Vérifiez que l’enregistrement TXT est visible depuis un résolveur public :
dig @8.8.8.8 +short TXT _acme-challenge.example.com
dig @1.1.1.1 +short TXT _acme-challenge.example.com
Limite de Débit Atteinte
Symptôme : Error creating new order :: too many certificates already issued
Attendez l’expiration de la fenêtre de limite, ajoutez ou supprimez un domaine de la liste SAN, ou utilisez --staging pour plus de tests.
Erreur de Permissions du Fichier de Credentials
Symptôme : Unsafe permissions on credentials configuration file
sudo chmod 600 /etc/letsencrypt/cloudflare/credentials.ini
sudo chown root:root /etc/letsencrypt/cloudflare/credentials.ini
Résumé
Les certificats SSL wildcard de Let’s Encrypt offrent la flexibilité de sécuriser des sous-domaines illimités avec un seul certificat gratuit. Points clés à retenir :
- Les wildcards exigent le défi DNS-01 — HTTP-01 ne peut pas valider
*.example.com. - La validation DNS manuelle fonctionne pour une émission unique mais ne supporte pas le renouvellement automatique.
- Les plugins DNS (certbot-dns-cloudflare, certbot-dns-route53, etc.) permettent un renouvellement entièrement automatisé.
- Le token API Cloudflare doit avoir la permission
Zone:DNS:Modifier; le fichier de credentials doit être enchmod 600. - Les fichiers du certificat se trouvent dans
/etc/letsencrypt/live/— utilisez toujoursfullchain.pemdans votre serveur web. - Les hooks de déploiement rechargent Nginx, HAProxy ou d’autres services après chaque renouvellement.
- Les limites de débit sont strictes — utilisez
--stagingpour les tests et--dry-runpour valider le renouvellement. - Les enregistrements CAA doivent inclure
letsencrypt.orgavecissuewildpour l’autorisation wildcard.