Gérer des certificats SSL individuels pour chaque sous-domaine devient vite fastidieux. Un certificat SSL wildcard de Let’s Encrypt couvre tous les sous-domaines sous un seul domaine — *.example.com — avec un seul certificat. Ce guide vous accompagne dans l’obtention d’un certificat wildcard gratuit avec Certbot via le challenge DNS-01 et la configuration de Nginx pour servir le HTTPS sur tous vos sous-domaines.

Prérequis

  • Un serveur Linux (Ubuntu 22.04/24.04 ou Debian 12) avec accès root ou sudo
  • Nginx installé et en fonctionnement
  • Un nom de domaine enregistré avec accès DNS (possibilité de créer des enregistrements TXT ou accès API)
  • Port 443 ouvert dans votre pare-feu
  • Connaissance de base des commandes terminal et de la configuration Nginx

Comprendre les certificats wildcard

Un certificat wildcard sécurise tous les sous-domaines de premier niveau d’un domaine. Un certificat pour *.example.com couvre www.example.com, api.example.com, staging.example.com et tout autre sous-domaine — mais pas le domaine nu example.com lui-même, et pas les sous-domaines multi-niveaux comme dev.api.example.com.

Let’s Encrypt exige le challenge DNS-01 pour les certificats wildcard. Contrairement au challenge HTTP-01 (qui dépose un fichier sur votre serveur web), le DNS-01 nécessite la création d’un enregistrement TXT à _acme-challenge.example.com pour prouver la propriété du domaine. Cela est logique : un wildcard couvre l’ensemble du domaine, vous devez donc prouver le contrôle du DNS du domaine, pas seulement d’un seul serveur.

Installation de Certbot et des plugins DNS

Installez Certbot et le plugin DNS correspondant à votre fournisseur DNS. Pour Cloudflare :

sudo apt update
sudo apt install certbot python3-certbot-nginx python3-certbot-dns-cloudflare

Pour d’autres fournisseurs, remplacez le paquet du plugin :

# AWS Route 53
sudo apt install python3-certbot-dns-route53

# DigitalOcean
sudo apt install python3-certbot-dns-digitalocean

# Google Cloud DNS
sudo apt install python3-certbot-dns-google

Si la version empaquetée est obsolète, installez via pip :

sudo pip3 install certbot certbot-nginx certbot-dns-cloudflare

Ensuite, créez le fichier d’identifiants pour votre fournisseur DNS. Pour Cloudflare, créez /etc/letsencrypt/cloudflare.ini :

# Cloudflare API token (recommended over Global API key)
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN

Verrouillez les permissions — ce fichier contient vos identifiants API :

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

Le token API Cloudflare nécessite la permission Zone:DNS:Edit limitée à votre domaine. Créez-en un dans Cloudflare Dashboard → My Profile → API Tokens.

Demande du certificat wildcard

Demandez un certificat couvrant à la fois le wildcard et le domaine nu :

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com" \
  --preferred-challenges dns-01 \
  --agree-tos \
  -m admin@example.com

Certbot crée un enregistrement DNS TXT, attend la propagation, le valide, puis le nettoie. Les fichiers du certificat se trouvent dans /etc/letsencrypt/live/example.com/ :

  • fullchain.pem — le certificat plus la chaîne intermédiaire
  • privkey.pem — la clé privée
  • chain.pem — le certificat intermédiaire uniquement

Pour un DNS manuel (sans plugin), utilisez --manual --preferred-challenges dns-01. Certbot affichera la valeur de l’enregistrement TXT à ajouter manuellement. Cela fonctionne pour les demandes ponctuelles mais ne permet pas le renouvellement automatique.

Configuration de Nginx

Créez ou mettez à jour votre bloc server Nginx pour utiliser le certificat wildcard. Cette configuration gère le HTTPS pour tous les sous-domaines et redirige le HTTP vers le HTTPS :

# Redirect all HTTP to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com *.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block for all subdomains
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com *.example.com;

    # Let's Encrypt wildcard certificate
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # SSL hardening
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # HSTS (optional, enable once confirmed working)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    root /var/www/example.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Testez et rechargez Nginx :

sudo nginx -t
sudo systemctl reload nginx

Pour un routage spécifique par sous-domaine, utilisez des blocs server séparés qui partagent les mêmes chemins de certificat mais avec des directives server_name et root / proxy_pass différentes.

Wildcard vs SAN vs certificats individuels

CaractéristiqueWildcard (*.example.com)SAN (Multi-Domaine)Certificats individuels
Couvre tous les sous-domainesOui (premier niveau uniquement)Uniquement les domaines listésUn domaine par certificat
Couverture du domaine racineDoit être ajouté explicitementOui, si listéOui
Sous-domaines multi-niveauxNon (*.*.example.com non supporté)Oui, si listésOui
Nombre de certificats111 par domaine
Challenge DNS requisOuiNon (HTTP-01 fonctionne)Non (HTTP-01 fonctionne)
Complexité de renouvellementNécessite un plugin DNS ou étape manuellePeut utiliser HTTP-01Simple avec HTTP-01
Idéal pourNombreux sous-domaines, sous-domaines dynamiquesEnsemble fixe de domaines différentsServeurs mono-domaine

Renouvellement automatique

Certbot configure un timer systemd automatiquement sur la plupart des distributions. Vérifiez qu’il est actif :

sudo systemctl status certbot.timer

S’il affiche active (waiting), le renouvellement est programmé. Vous pouvez également vérifier :

sudo certbot renew --dry-run

Ajoutez un hook post-renouvellement pour recharger Nginx après chaque renouvellement. Créez /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh :

#!/bin/bash
systemctl reload nginx

Rendez-le exécutable :

sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

Si vous préférez cron à systemd, ajoutez au crontab de root :

# Renew certificates twice daily (Certbot skips if not due)
0 3,15 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Scénario concret

Vous déployez une plateforme de microservices avec api.example.com pour le backend, app.example.com pour le frontend, staging.example.com pour les tests, et docs.example.com pour la documentation. Sans certificat wildcard, il faudrait exécuter Certbot pour chaque sous-domaine, gérer quatre certificats distincts, et ajouter de nouvelles commandes Certbot à chaque lancement d’un nouveau service. Avec un certificat wildcard, vous lancez une seule commande certbot certonly, pointez chaque bloc server Nginx vers les mêmes fichiers de certificat, et les nouveaux sous-domaines fonctionnent immédiatement — aucune modification de certificat nécessaire. Quand l’équipe lance monitoring.example.com le mois suivant, cela fonctionne tout simplement.

Pièges et cas particuliers

  • Domaine racine non couvert : *.example.com ne correspond PAS à example.com. Incluez toujours -d "*.example.com" -d "example.com" dans votre commande Certbot.
  • Délais de propagation DNS : Certains fournisseurs DNS mettent des minutes à propager les enregistrements TXT. Certbot attend 10 secondes par défaut. Augmentez ce délai avec --dns-cloudflare-propagation-seconds 60 si la validation échoue.
  • Limites de débit : Let’s Encrypt autorise 50 certificats par domaine enregistré par semaine et 5 certificats dupliqués par semaine. Le wildcard compte comme un seul certificat, donc vous êtes peu susceptible d’atteindre ces limites en usage normal. Utilisez --staging pour les tests.
  • Sous-domaines multi-niveaux : *.example.com ne couvre PAS dev.api.example.com. Vous avez besoin d’un certificat séparé ou d’un certificat SAN pour les sous-domaines imbriqués.
  • Logs de transparence des certificats : Tous les certificats Let’s Encrypt sont journalisés publiquement. Vos noms de sous-domaines seront visibles dans les logs CT. C’est inévitable avec tout certificat de confiance publique.
  • Sécurité des identifiants du plugin : Vos identifiants API DNS permettent de modifier les enregistrements DNS. Stockez-les dans /etc/letsencrypt/ avec des permissions 600 et envisagez de limiter les tokens API uniquement au domaine et aux permissions requis.

Résumé

  • Let’s Encrypt délivre des certificats wildcard gratuits couvrant *.votredomaine.com, valides 90 jours
  • Les certificats wildcard nécessitent le challenge DNS-01 — utilisez un plugin DNS Certbot pour votre fournisseur
  • Demandez toujours *.example.com et example.com dans le même certificat
  • Stockez les identifiants du plugin DNS de manière sécurisée avec chmod 600
  • Configurez Nginx avec ssl_certificate pointant vers le fullchain de Let’s Encrypt
  • Renforcez SSL avec TLSv1.2+, OCSP stapling et les en-têtes HSTS
  • Configurez le renouvellement automatique via un timer systemd ou cron avec un hook post-renouvellement pour recharger Nginx
  • Utilisez le flag --staging pendant les tests pour éviter les limites de débit

Articles Connexes