Un certificat wildcard sécurise un seul niveau de sous-domaine, le plus à gauche, sous un nom unique (*.example.com), tandis qu'un certificat SAN (également appelé certificat UCC ou multi-domaines) énumère un ensemble explicite de noms d'hôte dans son extension Subject Alternative Name. Aucun n'est à proprement parler « meilleur » : ils répondent à des problèmes de couverture différents, et un mauvais choix se manifeste généralement plus tard par une erreur de certificat inattendue sur un sous-domaine que personne n'a pensé à ajouter.
Ce que couvre réellement un certificat wildcard
Un certificat wildcard utilise un astérisque dans le label le plus à gauche, comme dans *.example.com. Selon la RFC 6125, cet astérisque ne peut remplacer qu'un seul label complet, le plus à gauche : *.example.com est valide, *.sub.example.com est valide en tant que wildcard distinct, mais f*.example.com (label partiel) et *.*.example.com (plusieurs labels) ne relèvent pas de la syntaxe wildcard standard que les autorités de certification (CA) publiques acceptent d'émettre.
Le détail qui piège souvent : un wildcard ne couvre pas le domaine apex nu, et il ne descend pas au-delà d'un niveau. *.example.com protège www.example.com et api.example.com, mais pas example.com lui-même ni a.b.example.com. Si vous devez aussi couvrir l'apex, ajoutez-le comme seconde entrée SAN sur le même certificat. La plupart des émetteurs le font automatiquement lorsque vous demandez un wildcard via leur processus standard, mais il vaut mieux vérifier la liste SAN obtenue plutôt que de le supposer.
Les CA publiques n'émettent pas non plus de wildcard au niveau du suffixe public ou au-dessus : impossible d'obtenir *.co.uk auprès d'une CA publiquement reconnue, pour des raisons évidentes.
WarningLes CA publiques n'émettent des certificats wildcard que via la validation de domaine DNS-01, qui consiste à prouver le contrôle de la zone DNS en publiant un enregistrement TXT. La validation HTTP ne permet pas de prouver le contrôle de sous-domaines qui n'existent pas encore ; si votre DNS est réparti entre plusieurs fournisseurs ou soumis à un processus de gestion des changements, tenez compte de ce délai lors des renouvellements.
Ce que couvre réellement un certificat SAN
Un certificat SAN énumère individuellement chaque nom d'hôte qu'il protège dans l'extension subjectAltName du certificat : www.example.com, app.example.com, example.net et shop.example.org peuvent tous figurer sur un même certificat, même s'il s'agit de domaines sans aucun rapport entre eux. Il n'existe aucune limite au niveau du protocole quant au nombre de noms qu'un certificat peut contenir (la RFC 5280 n'en fixe pas), mais les CA imposent leurs propres plafonds pratiques, généralement compris entre 100 et 250 noms selon le fournisseur et la gamme de produit. Consultez donc la documentation actuelle de la CA émettrice si vous constituez une longue liste.
Chaque nom d'un certificat SAN peut, en principe, utiliser une méthode de validation différente, et une liste SAN peut combiner des noms d'hôte exacts et des entrées wildcard, par exemple *.example.com, example.com et api.partner-domain.com sur un seul certificat. Cette flexibilité est la principale raison d'être des certificats SAN : ils permettent à un seul certificat de couvrir un ensemble dispersé de services qui ne partagent pas un schéma de sous-domaine homogène.
Certificat wildcard ou SAN : le comparatif
| Wildcard | SAN / UCC | |
|---|---|---|
| Couvre | Un niveau de sous-domaine sous un nom | Chaque nom d'hôte listé explicitement |
| Domaine apex | Non inclus automatiquement | À ajouter comme entrée SAN distincte |
| Nouveaux sous-domaines | Couverts automatiquement s'ils relèvent du wildcard | À ajouter, avec réémission du certificat |
| Validation | DNS-01 uniquement (CA publiques) | Variable selon le nom |
| Idéal pour | De nombreux sous-domaines, un seul schéma | Une liste fixe et hétérogène de noms d'hôte/domaines |
| Validité max. | 398 jours (CA publiques, comme tout certificat) | 398 jours |
Quand utiliser un certificat wildcard
Optez pour un wildcard lorsque des sous-domaines sont créés fréquemment et de façon prévisible sous un même nom : par exemple des sous-domaines par client sur une plateforme SaaS (tenant1.example.com, tenant2.example.com), ou une architecture de microservices dans laquelle de nouveaux services internes apparaissent sous *.internal.example.com plus vite que quiconque ne voudrait gérer une liste SAN. Un seul certificat couvre discrètement l'ensemble, et vous n'avez pas à le réémettre à chaque mise en ligne d'un nouveau sous-domaine.
La contrepartie : la compromission de la clé privée d'un wildcard expose d'un coup tous les sous-domaines actuels et futurs relevant de ce nom, ce qui représente un rayon d'impact plus large que le vol d'un seul certificat SAN couvrant une liste fixe. Si vous utilisez un wildcard, protégez sa clé privée en conséquence et surveillez les journaux de Certificate Transparency pour repérer tout certificat émis pour votre domaine que vous n'avez pas demandé.
Quand utiliser un certificat SAN
Les certificats SAN sont pertinents lorsque vous disposez d'un ensemble connu et relativement stable de noms d'hôte qui ne suivent pas un schéma unique : un site marketing sur l'apex, une application sur un sous-domaine, une API sur un autre TLD, voire un domaine partenaire pour lequel vous terminez également le TLS. Les énumérer explicitement réduit le rayon d'impact (seuls les hôtes nommés sont couverts) et permet d'auditer la validation nom par nom.
La contrepartie joue en sens inverse : chaque nouveau nom d'hôte implique de modifier la liste SAN et de réémettre le certificat. Si votre liste change chaque semaine, cette charge s'accumule rapidement, et un wildcard (ou l'automatisation) devient plus intéressant.
TipVous n'êtes pas obligé de choisir l'un ou l'autre. Un même certificat peut combiner une entrée wildcard et des noms d'hôte SAN explicites :
*.example.com,example.cometapi.partner.comsur un seul certificat, c'est valide et courant en pratique.
Vérifier ce que contient réellement un certificat
Ne déduisez pas la couverture du seul nom commun (CN) du certificat : il est souvent purement informatif aujourd'hui, et c'est la liste SAN qui compte réellement pour la correspondance. Passez n'importe quel certificat en production dans notre vérificateur SSL gratuit pour voir toutes les entrées SAN, la date d'expiration et la chaîne de certificats, en une seule vue. C'est le moyen le plus rapide de confirmer qu'un wildcard couvre bien ce que vous pensez, ou de repérer un certificat SAN auquel il manque un nom d'hôte avant qu'un navigateur ne le fasse à votre place.
Si vous hésitez encore entre un certificat gratuit automatisé et un certificat commercial, indépendamment du type SAN ou wildcard, consultez notre comparatif Let's Encrypt ou SSL commercial : le choix entre wildcard et SAN est indépendant de cette décision, et les deux modes d'émission prennent en charge l'un comme l'autre.
Renouveler tous vos certificats sans tableur
Quel que soit le type choisi, le risque opérationnel reste le même : un certificat qui expire sans prévenir ou qui ne couvre plus un nom d'hôte ajouté le mois dernier. La gestion des certificats d'InfraNest suit chaque certificat chez chaque fournisseur, signale les lacunes de couverture SAN et automatise le renouvellement afin que les certificats wildcard comme SAN soient réémis avant leur expiration, et non après qu'un client a signalé un avertissement du navigateur.
Questions fréquentes
#Un certificat wildcard peut-il aussi couvrir le domaine apex nu ?
Pas automatiquement. Un wildcard comme *.example.com ne couvre qu'un seul niveau de sous-domaine ; l'apex (example.com) doit être ajouté comme entrée SAN distincte, ce que la plupart des émetteurs font par défaut si vous demandez les deux lors de la demande de certificat.
#Un certificat wildcard coûte-t-il moins cher qu'un certificat SAN comportant le même nombre de noms ?
Les tarifs varient selon la CA, mais les wildcards sont généralement vendus comme couvrant un nombre illimité de sous-domaines sur un niveau sous un nom unique, tandis que les certificats SAN sont habituellement facturés par hôte nommé ou par paliers selon le nombre de SAN. Comparez les tarifs actuels de la CA concernée plutôt que de supposer que l'un est moins cher que l'autre.
#Puis-je inclure une entrée wildcard dans un certificat SAN ?
Oui. Une liste SAN peut combiner une entrée wildcard (par ex. *.example.com) avec des noms d'hôte explicites, voire des domaines sans rapport, sur le même certificat. C'est une manière courante de cumuler la couverture des deux approches.
#Les certificats wildcard nécessitent-ils une méthode de validation différente de celle des certificats SAN ?
Les CA publiques ne valident les entrées wildcard que via DNS-01 (un enregistrement DNS TXT prouvant le contrôle de la zone), car la validation HTTP ne permet pas de confirmer le contrôle de sous-domaines qui n'existent pas encore. Les noms d'hôte SAN individuels peuvent généralement utiliser DNS-01 ou HTTP-01, selon ce que la CA prend en charge pour ce nom.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
