Automatiser les Certificats Wildcard avec DNS-01

Le protocole ACME (Automatic Certificate Management Environment) a révolutionné la manière dont nous obtenons et renouvelons les certificats SSL/TLS, notamment grâce à des autorités de certification comme Let’s Encrypt. Si le défi HTTP-01 est courant pour les certificats de domaines uniques, les certificats wildcard, qui couvrent tous les sous-domaines d’un domaine principal, nécessitent une approche plus avancée : le défi DNS-01. Cet article explore pourquoi et comment mettre en œuvre cette méthode puissante.

Pourquoi cet Article ?

Cet article explore un cas d’usage plus complexe et puissant d’ACME : l’automatisation des certificats wildcard. Ces certificats offrent une flexibilité considérable, et leur gestion automatisée via le défi DNS-01 est une compétence essentielle pour de nombreux administrateurs système et développeurs.

Qu’est-ce qu’un Certificat Wildcard et Quels sont ses Avantages ?

Un certificat wildcard est un type de certificat SSL/TLS qui peut sécuriser un nombre illimité de sous-domaines de premier niveau pour un domaine donné. Il est identifiable par un astérisque (*) dans le nom commun (Common Name) ou le nom alternatif du sujet (Subject Alternative Name - SAN). Par exemple, un certificat pour *.exemple.com sécurisera :

• www.exemple.com
• blog.exemple.com
• api.exemple.com
• shop.exemple.com
• Etc.

Avantages des certificats wildcard :

1. Simplicité de gestion : Un seul certificat à gérer (obtenir, renouveler, déployer) pour de multiples sous-domaines, réduisant la complexité administrative.
2. Flexibilité : Idéal pour les environnements dynamiques où de nouveaux sous-domaines sont fréquemment ajoutés. Pas besoin de réémettre un certificat à chaque ajout.
3. Couverture étendue : Couvre tous les sous-domaines de premier niveau (mais pas les sous-sous-domaines comme test.api.exemple.com sans un SAN supplémentaire ou un autre wildcard).
4. Coût (avec Let’s Encrypt) : Bien que les certificats wildcard aient été historiquement plus chers, Let’s Encrypt les fournit gratuitement, rendant leurs avantages accessibles à tous.

Pourquoi le Défi DNS-01 est Nécessaire pour les Wildcards ?

Le protocole ACME propose plusieurs types de défis pour prouver que vous contrôlez un nom de domaine avant qu’une autorité de certification (AC) n’émette un certificat pour celui-ci.

• Défi HTTP-01 : L’AC demande au client ACME de placer un fichier spécifique avec un contenu spécifique à une URL HTTP bien définie sur le serveur hébergeant le domaine. Par exemple, pour www.exemple.com, le client placerait un fichier sous http://www.exemple.com/.well-known/acme-challenge/. L’AC vérifie ensuite la présence et le contenu de ce fichier.
• Défi DNS-01 : L’AC demande au client ACME de créer un enregistrement DNS spécifique (de type TXT) avec une valeur spécifique sous le nom de domaine que vous souhaitez valider. Par exemple, pour exemple.com (et donc *.exemple.com), le client créerait un enregistrement TXT pour _acme-challenge.exemple.com.

Pour les certificats wildcard comme *.exemple.com, le défi HTTP-01 n’est pas réalisable. L’astérisque (*) ne correspond pas à un serveur unique spécifique sur lequel un fichier pourrait être placé pour validation. Il représente une multitude de serveurs potentiels (ou aucun pour les sous-domaines non encore définis).

Le défi DNS-01 est donc la méthode requise par Let’s Encrypt pour les certificats wildcard. En modifiant les enregistrements DNS d’un domaine, vous prouvez un niveau de contrôle sur l’ensemble du domaine, y compris tous ses sous-domaines potentiels.

Guide Étape par Étape pour Configurer le Défi DNS-01

La configuration du défi DNS-01 implique l’utilisation d’un client ACME capable d’interagir avec l’API de votre fournisseur DNS pour créer et supprimer automatiquement les enregistrements TXT nécessaires. Les clients populaires incluent acme.sh et Certbot (avec des plugins DNS).

Étapes générales :

1. Choisir un client ACME :
   • acme.sh: Un client shell Unix pur, très polyvalent et supportant nativement de nombreux fournisseurs DNS.
   • Certbot: Le client officiel de Let’s Encrypt, nécessitant des plugins spécifiques pour chaque fournisseur DNS (ex: certbot-dns-cloudflare, certbot-dns-ovh).
2. Obtenir les identifiants API de votre fournisseur DNS : C’est l’étape la plus cruciale. Vous aurez besoin de clés API ou de jetons qui autorisent votre client ACME à modifier les enregistrements DNS de votre zone.
3. Configurer le client ACME : Fournissez les identifiants API au client, généralement via des variables d’environnement ou des fichiers de configuration sécurisés.
4. Demander le certificat : Lancez la commande pour émettre le certificat, en spécifiant le domaine principal et le domaine wildcard (ex: -d exemple.com -d '*.exemple.com').
5. Automatiser le renouvellement : La plupart des clients ACME configurent automatiquement une tâche cron ou un timer systemd pour le renouvellement.

Exemple avec acme.sh

acme.sh est souvent privilégié pour sa simplicité d’installation et son large support des API DNS.

1. Installation de acme.sh:

   curl [https://get.acme.sh](https://get.acme.sh) | sh -s
   # ou
   git clone [https://github.com/acmesh-official/acme.sh.git](https://github.com/acmesh-official/acme.sh.git)
   cd ./acme.sh
   ./acme.sh --install -m monemail@exemple.com
   

   Suivez les instructions pour ajouter l’alias acme.sh à votre profil shell.

2. Configurer les identifiants API DNS : La méthode exacte dépend de votre fournisseur DNS. acme.sh utilise des variables d’environnement.

   Par exemple, pour Cloudflare :

   export CF_Token="VOTRE_TOKEN_API_CLOUDFLARE"
   export CF_Account_ID="VOTRE_ID_DE_COMPTE_CLOUDFLARE" # Optionnel, peut être requis pour certains setups
   # ou pour utiliser un Global API Key (moins sécurisé)
   # export CF_Key="VOTRE_CLE_API_GLOBALE_CLOUDFLARE"
   # export CF_Email="VOTRE_EMAIL_CLOUDFLARE"
   

   Pour OVH :

   export OVH_AK="VOTRE_APPLICATION_KEY_OVH"
   export OVH_AS="VOTRE_APPLICATION_SECRET_OVH"
   export OVH_CK="VOTRE_CONSUMER_KEY_OVH"
   

   (La OVH_CK est obtenue en exécutant acme.sh une première fois avec OVH_AK et OVH_AS définies, il vous guidera).

   Pour Gandi (LiveDNS v5 API) :

   export GANDIV5_API_KEY="VOTRE_CLE_API_GANDI_LIVEDNS"
   

   Consultez la documentation de acme.sh pour les variables spécifiques à votre fournisseur : How to use DNS API

3. Émettre le certificat :

   # Remplacer 'dns_cf' par l'identifiant de votre fournisseur (ex: dns_ovh, dns_gandi_livedns)
   acme.sh --issue --dns dns_cf -d exemple.com -d '*.exemple.com' --server letsencrypt
   

   Si vous utilisez un fournisseur qui n’est pas directement supporté via un script dns_xx, vous pourriez avoir besoin d’utiliser dns_manual ou des hooks plus complexes, ou des solutions comme lexicon.

4. Installer le certificat (exemple pour Nginx) : Les certificats sont généralement stockés dans ~/.acme.sh/exemple.com/.

   acme.sh --install-cert -d exemple.com \
       --key-file       /etc/nginx/ssl/exemple.com.key  \
       --fullchain-file /etc/nginx/ssl/fullchain.cer \
       --reloadcmd     "sudo systemctl reload nginx.service"
   

   Cette commande copie les certificats aux emplacements désirés et recharge Nginx. Le renouvellement automatique utilisera cette même commande.

Exemple avec Certbot et un Plugin DNS

1. Installer Certbot et le plugin DNS approprié :

   sudo apt update
   sudo apt install certbot
   # Pour Cloudflare:
   sudo apt install python3-certbot-dns-cloudflare
   # Pour OVH (via lexicon, nécessite une configuration plus manuelle ou un plugin tiers):
   # sudo pip install certbot-dns-ovh (ou un autre plugin communautaire)
   # Pour Gandi (LiveDNS ou legacy):
   # sudo apt install python3-certbot-dns-gandi (si disponible via apt)
   # ou sudo pip install certbot-dns-gandi
   

   La disponibilité des plugins via apt peut varier. pip est une alternative.

2. Créer un fichier d’identifiants sécurisé : Par exemple, pour Cloudflare (/etc/letsencrypt/cloudflare.ini):

   # Cloudflare API token used by Certbot
   dns_cloudflare_api_token = VOTRE_TOKEN_API_CLOUDFLARE
   

   Sécurisez ce fichier :

   sudo chmod 600 /etc/letsencrypt/cloudflare.ini
   

   Pour d’autres fournisseurs, la structure du fichier d’identifiants variera. Consultez la documentation du plugin Certbot spécifique.

3. Demander le certificat :

   # Pour Cloudflare
   sudo certbot certonly \
       --dns-cloudflare \
       --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
       -d exemple.com \
       -d '*.exemple.com' \
       --server [https://acme-v02.api.letsencrypt.org/directory](https://acme-v02.api.letsencrypt.org/directory)
   

   Pour d’autres fournisseurs, l’option --dns-xxx et --dns-xxx-credentials changera (ex: --dns-gandi, --dns-ovh).

Certbot configure automatiquement le renouvellement via un timer systemd ou une tâche cron.

Exemples avec des Fournisseurs DNS Populaires (API)

Cloudflare

• API : Utilise des “API Tokens” (recommandé, plus granulaire) ou une “Global API Key” (moins sécurisé).
• Permissions requises pour le token : Zone:Zone:Read, Zone:DNS:Edit pour la zone concernée.
• acme.sh variables : CF_Token et CF_Account_ID (si token), ou CF_Key et CF_Email (si clé globale).
• Certbot plugin : python3-certbot-dns-cloudflare, utilise dns_cloudflare_api_token dans le fichier credentials.

OVH

• API : Nécessite la création d’identifiants d’application (AK, AS) sur api.ovh.com puis l’obtention d’une Consumer Key (CK).
• Droits pour la Consumer Key :
  • GET /domain/zone/*
  • PUT /domain/zone/*
  • POST /domain/zone/*
  • DELETE /domain/zone/*
• acme.sh variables : OVH_AK, OVH_AS, OVH_CK.
• Certbot plugin : Peut nécessiter un plugin tiers comme certbot-dns-ovh (souvent basé sur lexicon), qui aura ses propres exigences de configuration pour les identifiants.

Gandi

• API :
  • LiveDNS API v5 : Utilise une clé API personnelle. C’est la méthode moderne.
  • Legacy XML-RPC API : Plus ancienne, utilisez LiveDNS si possible.
• acme.sh variables (LiveDNS v5) : GANDIV5_API_KEY.
• Certbot plugin (LiveDNS) : python3-certbot-dns-gandi ou certbot-dns-gandi (via pip). Le fichier credentials contiendra typiquement dns_gandi_api_key = VOTRE_CLE_API_GANDI.

Autres Fournisseurs

La plupart des grands fournisseurs DNS (AWS Route 53, Google Cloud DNS, DigitalOcean, Namecheap, etc.) ont des API et sont supportés par acme.sh et/ou des plugins Certbot.
Référez-vous toujours à la documentation du client ACME et du fournisseur DNS :

• acme.sh DNS API list: https://github.com/acmesh-official/acme.sh/wiki/dnsapi
• Certbot DNS Plugins: Listés sur le site de Certbot ou via une recherche (apt search certbot-dns, pip search certbot-dns).

Considérations de Sécurité pour la Gestion des Identifiants API DNS

La gestion des identifiants API DNS est l’aspect le plus sensible de l’utilisation du défi DNS-01. Si ces identifiants sont compromis, un attaquant pourrait prendre le contrôle de votre zone DNS.

1. Principe du moindre privilège (PoLP) :

   • Si votre fournisseur DNS le permet (ex: Cloudflare API Tokens, AWS IAM Roles), créez des identifiants API qui ont uniquement les permissions nécessaires pour créer et supprimer des enregistrements TXT (CNAME pour certains alias mode) et uniquement pour la zone DNS concernée. Évitez d’utiliser des clés API globales avec des droits administratifs complets.
   • OVH est moins granulaire ici ; la Consumer Key donnera un accès assez large à la zone. Soyez particulièrement vigilant.

2. Stockage sécurisé des identifiants :

   • acme.sh : Stocke les variables d’environnement dans son fichier de configuration (~/.acme.sh/account.conf) avec des permissions restreintes.
   • Certbot : Les fichiers d’identifiants (ex: /etc/letsencrypt/cloudflare.ini) doivent avoir des permissions très strictes (ex: chmod 600).
   • Évitez de stocker les identifiants directement dans des scripts versionnés publiquement.
   • Utilisez des coffres-forts de secrets (Vault, etc.) pour les environnements plus complexes.

3. Rotation des identifiants : Si possible et pratique, changez régulièrement vos identifiants API.

4. Surveillance : Surveillez les journaux d’audit de votre fournisseur DNS pour toute activité suspecte. Activez les alertes si des modifications DNS inattendues se produisent.

5. Utilisation de CNAME alias (si supporté par votre client et fournisseur) : Certains clients ACME, comme acme.sh avec l’option --challenge-alias, permettent de déléguer la validation DNS à un autre domaine (par exemple, un domaine dédié _acme-challenge.exemple.com CNAME validation.autre-domaine.com). Cela peut permettre de restreindre les identifiants API à la gestion d’une zone DNS moins critique ou à un service DNS tiers spécialisé dans la validation ACME (ex: acme-dns).

Conclusion

L’automatisation des certificats wildcard via le défi DNS-01 est une technique extrêmement puissante pour sécuriser vos applications et services web. Bien qu’elle nécessite une configuration initiale plus impliquée que le défi HTTP-01, notamment la gestion des identifiants API DNS, les avantages en termes de flexibilité et de couverture pour les sous-domaines sont considérables. En choisissant le bon client ACME, en comprenant les spécificités de votre fournisseur DNS et en appliquant des pratiques de sécurité rigoureuses pour vos identifiants, vous pouvez mettre en place un système de gestion de certificats robuste et entièrement automatisé.