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.com sur 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 :

  1. Certbot contacte le serveur ACME et demande l’autorisation pour *.example.com.
  2. Le serveur ACME émet un token et demande la publication d’un enregistrement TXT à _acme-challenge.example.com avec une valeur spécifique.
  3. Certbot (ou son plugin DNS) crée l’enregistrement TXT via l’API de votre fournisseur DNS.
  4. Le serveur ACME interroge les résolveurs DNS pour vérifier l’existence de l’enregistrement TXT.
  5. Une fois validé, le certificat est signé et renvoyé.
  6. 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

PluginFournisseurCommande d’installation
certbot-dns-cloudflareCloudflaresudo snap install certbot-dns-cloudflare
certbot-dns-route53AWS Route 53sudo snap install certbot-dns-route53
certbot-dns-googleGoogle Cloud DNSsudo snap install certbot-dns-google
certbot-dns-digitaloceanDigitalOceansudo snap install certbot-dns-digitalocean
certbot-dns-linodeLinode/Akamaisudo snap install certbot-dns-linode
certbot-dns-hetznerHetzner DNSpip 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 profilTokens APICréer un token.

Utilisez le modèle “Modifier le DNS de la zone” et configurez :

  • Permissions : ZoneDNSModifier
  • Ressources de zone : InclureZone 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

FichierCheminObjectif
Chaîne complète/etc/letsencrypt/live/example.com/fullchain.pemCertificat + AC intermédiaire (utiliser dans Nginx/Apache)
Clé privée/etc/letsencrypt/live/example.com/privkey.pemClé privée — à protéger soigneusement
Chaîne seule/etc/letsencrypt/live/example.com/chain.pemChaîne AC intermédiaire uniquement
Certificat seul/etc/letsencrypt/live/example.com/cert.pemCertificat 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

LimiteValeurFenêtre
Certificats par domaine enregistré507 jours
Certificats en double57 jours
Validations échouées51 heure
Nouvelles commandes3003 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

OutilWildcardDNS AutoLet’s EncryptAutres ACNotes
CertbotOui (plugins)Par pluginOuiLimitéClient officiel EFF, écosystème le plus large
acme.shOuiIntégré (150+)OuiOuiBash uniquement, sans dépendances, portable
CaddyOui (natif)AutomatiqueOuiOuiSans configuration ; module DNS à compiler
TraefikOui (natif)AutomatiqueOuiLimitéIdéal pour les environnements de conteneurs
AC CommercialeOuiNon (manuel)NonOui100–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 en chmod 600.
  • Les fichiers du certificat se trouvent dans /etc/letsencrypt/live/ — utilisez toujours fullchain.pem dans 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 --staging pour les tests et --dry-run pour valider le renouvellement.
  • Les enregistrements CAA doivent inclure letsencrypt.org avec issuewild pour l’autorisation wildcard.

Articles Connexes