Chaque agence qui gère des sites de démonstration en sous-domaines finit par se poser la même question : faut-il un seul certificat wildcard couvrant *.dev.exemple.fr, ou un certificat distinct par sous-domaine émis à la volée ? Sur notre parc, la réponse a changé deux fois en trois ans, et pas pour des raisons de coût.
Ce comparatif ne revient pas sur l’installation de base de Certbot ou sur la mécanique du défi ACME, déjà largement documentée ailleurs. Il se concentre sur ce qui se joue réellement au quotidien : qui a accès à la clé privée, ce qui se passe quand un sous-domaine de démonstration reste actif six mois après le départ du client, et combien de temps prend une révocation d’urgence selon l’architecture choisie.
Le wildcard, un seul secret pour tout un domaine
Un certificat wildcard signé pour *.dev.exemple.fr couvre tous les sous-domaines présents et futurs sans nouvelle émission. Le renouvellement se fait via un défi DNS-01 (indispensable puisque le wildcard interdit le défi HTTP-01), typiquement automatisé avec un hook DNS chez OVH ou Gandi. Le confort opérationnel est réel : ajouter un nouveau site de démonstration ne demande aucune action côté certificat, juste une entrée DNS et un bloc serveur.
Le revers de cette simplicité, c’est que la clé privée du wildcard protège tous les sous-domaines à la fois. Si un serveur de préproduction mal isolé expose cette clé, l’attaquant peut usurper n’importe quel sous-domaine du domaine parent, y compris ceux de clients qui n’ont rien à voir avec l’incident initial.
Le certificat par sous-domaine, une clé par site
À l’opposé, générer un certificat SAN distinct pour chaque sous-domaine (via un défi HTTP-01 classique, déclenché automatiquement à la création du site) cloisonne le risque : une fuite de clé ne compromet qu’un seul sous-domaine. C’est l’approche que nous avons adoptée après un audit de sécurité qui pointait justement notre wildcard unique comme point de défaillance central.
Le coût opérationnel est différent : chaque nouveau sous-domaine déclenche une émission, ce qui suppose une automatisation fiable (script de provisioning appelant certbot certonly --nginx -d nouveau-client.dev.exemple.fr) et une vraie discipline de nettoyage, faute de quoi le nombre de certificats actifs dérive rapidement.
Ce que change le volume de création
Le bon choix dépend surtout du rythme de création de sous-domaines. Sur un parc où l’agence ouvre deux ou trois environnements de démonstration par semaine, l’émission automatique par sous-domaine tient sans effort dans un script de provisioning déjà existant. Sur un parc plus statique, où les sous-domaines changent rarement, le wildcard reste pertinent à condition d’isoler strictement la clé privée sur un serveur dédié, jamais partagée avec les environnements applicatifs.
| Critère | Wildcard | Par sous-domaine |
|---|---|---|
| Renouvellement | Un seul défi DNS-01 | Un défi HTTP-01 par site |
| Rayon d’exposition en cas de fuite | Tout le domaine | Un seul sous-domaine |
| Effort à la création d’un site | Nul | Script d’émission requis |
| Nettoyage des sites abandonnés | Sans impact sur le certificat | Certificat à révoquer explicitement |
Un compromis : le wildcard segmenté
Une troisième voie, que nous utilisons désormais pour les gros clients, consiste à émettre un wildcard par client plutôt qu’un wildcard global : *.client-a.dev.exemple.fr, *.client-b.dev.exemple.fr, etc. Cela conserve le confort du wildcard pour les sous-domaines internes à un client (préproduction, recette, démonstration commerciale) tout en limitant l’exposition à un seul portefeuille en cas de compromission.
- Chaque client dispose de sa propre clé privée, stockée séparément.
- La révocation d’un incident ne touche qu’un seul client, jamais l’ensemble du parc.
- Le renouvellement reste automatisable via un hook DNS générique, paramétré par client.
Sur un parc de plus de quinze clients actifs, le wildcard global n’est plus un choix de simplicité : c’est un pari sur le fait qu’aucun serveur de démonstration ne sera jamais compromis. Ce pari, nous avons fini par ne plus le prendre.
Ce que révoquer un wildcard implique vraiment
Un point souvent négligé : révoquer un certificat wildcard en urgence via certbot revoke ne suffit pas. Il faut aussi couper immédiatement l’accès au serveur qui hébergeait la clé, vérifier les journaux d’accès pour détecter un usage frauduleux antérieur à la révocation, et réémettre un nouveau wildcard pour l’ensemble des sous-domaines concernés — soit potentiellement des dizaines de sites à reconfigurer en urgence. Sur notre incident de référence, cette opération a mobilisé deux personnes pendant une matinée entière, alors qu’une révocation par sous-domaine se traite en quelques minutes sans effet de bord sur le reste du parc.
Notre verdict
Pour un petit parc stable, un wildcard bien isolé reste un choix raisonnable. Dès que le volume de sous-domaines dépasse la dizaine et que leur cycle de vie devient rapide (création, test, suppression), le certificat par sous-domaine ou le wildcard segmenté par client l’emporte largement sur la simplicité apparente d’un certificat unique. La documentation officielle de Certbot sur les défis DNS reste la référence pour automatiser proprement l’une ou l’autre approche : certbot.eff.org/docs.
