Certificat wildcard : couverture, DNS-01 et risques

Un certificat wildcard protège les sous-domaines directs, par exemple boutique.example.com avec *.example.com. Il ne couvre ni example.com ni paiement.boutique.example.com sans nom supplémentaire. Chez Let’s Encrypt, utilisez DNS-01, automatisez le renouvellement et limitez strictement les droits DNS.

Lire la couverture dans le SAN

L’étoile remplace un seul libellé complet. Dans l’extension Subject Alternative Name, le nom *.example.com correspond à blog.example.com ou shop.example.com. Il ne signifie pas tous les noms qui se terminent vaguement par example.com.

Le domaine nu example.com est un nom distinct. Si le site doit répondre à la fois sur example.com et sur ses sous-domaines directs, demandez les deux identifiants dans le même certificat :

example.com
*.example.com

Le nom api.shop.example.com comporte un niveau supplémentaire. Il demande un SAN explicite ou un autre wildcard, par exemple *.shop.example.com. Les wildcards imbriqués comme ..example.com ne sont pas une solution valide.

Contrôlez la liste réelle, pas le nom commercial du certificat. C’est le contenu du SAN présenté par le serveur qui décide de la correspondance.

Choisir entre wildcard, SAN explicites et certificats séparés

Le wildcard est utile lorsque de nouveaux sous-domaines directs apparaissent souvent derrière le même point de terminaison TLS. Une plateforme qui crée boutique-a.example.com puis boutique-b.example.com évite ainsi une réémission à chaque ajout.

Cette commodité ne réduit pas toujours le travail. Si plusieurs équipes ou serveurs reçoivent la même clé privée, chaque copie agrandit le périmètre d’incident. Une compromission impose alors de révoquer, réémettre et redéployer le certificat partout où cette clé a été distribuée.

Évitez le wildcard comme raccourci organisationnel. Séparer production, préproduction et services d’administration peut limiter l’impact d’une clé volée. La bonne frontière suit la responsabilité et le lieu de terminaison TLS, pas seulement l’arborescence DNS.

Pourquoi DNS-01 est nécessaire

Chez Let’s Encrypt, HTTP-01 prouve le contrôle d’un nom en servant un jeton depuis le serveur web. Cette méthode ne permet pas d’émettre un wildcard. DNS-01 prouve le contrôle du domaine avec une valeur TXT sous _acme-challenge.example.com et accepte les demandes wildcard.

Le vrai prérequis est une automatisation DNS sûre. Le fournisseur DNS doit proposer une API utilisable par votre client ACME, ou vous devez déléguer la zone de validation vers un système dédié. Une saisie manuelle du TXT convient à un essai, pas à une exploitation durable.

Les modifications DNS ne deviennent pas visibles partout instantanément. Le client doit attendre la propagation, interroger les serveurs faisant autorité et supprimer les anciens enregistrements une fois la validation terminée. Conservez une marge adaptée à votre fournisseur plutôt qu’un délai copié sans mesure.

Pour diagnostiquer avant de relancer une demande :

dig TXT _acme-challenge.example.com
dig +trace TXT _acme-challenge.example.com

La première commande montre la réponse obtenue par votre résolveur. La seconde aide à repérer une délégation ou un serveur faisant autorité qui ne publie pas encore la valeur attendue.

Émettre avec Certbot sans piéger le renouvellement

Une émission manuelle rend la mécanique visible :

sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d example.com \
  -d '*.example.com'

Certbot demande alors de créer le TXT indiqué. Cette commande seule ne fournit pas un renouvellement automatique. Le mode manuel exige des hooks d’authentification et de nettoyage ; en exploitation, préférez le plugin DNS adapté au fournisseur et à la version installée.

Le principe d’une commande automatisée est le suivant :

sudo certbot certonly \
  --authenticator dns-FOURNISSEUR \
  --dns-FOURNISSEUR-credentials /etc/letsencrypt/dns.ini \
  -d example.com \
  -d '*.example.com'

Remplacez les options par celles du plugin officiel installé. Ne collez pas une commande prévue pour un autre fournisseur : noms d’options, format du fichier d’identifiants et délai de propagation varient.

Réduire les droits DNS et l’exposition de la clé

Un jeton DNS global transforme un renouvellement en accès d’administration. Créez un identifiant limité aux seules zones et opérations nécessaires. Protégez son fichier contre la lecture par les autres comptes et évitez de le copier sur chaque serveur web.

Une architecture plus nette consiste à exécuter ACME sur un hôte de validation, puis à livrer le certificat aux seuls terminateurs TLS. La délégation de _acme-challenge par CNAME ou NS permet aussi d’isoler la validation sans déplacer toute la zone DNS.

La clé privée du certificat mérite une séparation similaire :

• ne la placez pas dans une image de conteneur ou un dépôt ;
• limitez les comptes et services capables de la lire ;
• recensez chaque machine qui reçoit une copie ;
• préparez révocation, réémission et déploiement d’urgence.

Pour une boutique, le panier ne lit pas les excuses : un certificat expiré ou mal déployé bloque avant toute explication commerciale. Comparez donc le gain de gestion du wildcard au coût d’un remplacement coordonné.

Vérifier le certificat réellement servi

Inspectez d’abord le fichier reçu :

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem \
  -noout -subject -issuer -dates -ext subjectAltName

Puis contrôlez le certificat présenté par chaque frontal avec SNI :

openssl s_client \
  -connect shop.example.com:443 \
  -servername shop.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Le fichier correct n’assure pas le bon déploiement. Un répartiteur, un CDN ou un ancien frontal peut encore servir une autre chaîne. Testez au moins l’apex, un sous-domaine direct et chaque terminaison TLS distincte.

Enfin, lancez le test de renouvellement :

sudo certbot renew --dry-run

Un succès prouve que le client peut répéter la validation dans l’environnement actuel. Il ne remplace pas une alerte d’expiration, ni un contrôle après déploiement. Vérifiez également que le hook recharge effectivement le serveur qui consomme le certificat.

Décider sans surcouvrir

Choisissez un wildcard si les noms directs changent souvent, si la terminaison TLS est centralisée et si l’API DNS peut être restreinte. Préférez des SAN explicites pour une petite liste stable. Séparez les certificats lorsque les équipes, environnements ou niveaux de confiance ne doivent pas partager une clé.

Sur la gestion DNS, documentez le propriétaire de la zone, la délégation de validation et la procédure de révocation. Ce registre opérationnel vaut davantage qu’une promesse de couverture illimitée.