Certificats SSL Wildcard multi-domaines

Un certificat SSL multi-domaines wildcard combine deux produits en un seul : un certificat multi-domaines (SAN) et un certificat wildcard. Au lieu d’acheter les deux séparément ou de gérer plusieurs certificats dans votre infrastructure, vous couvrez plusieurs domaines distincts et les sous-domaines de chacun à partir d’un seul certificat émis.

Le mécanisme repose sur le champ SAN. SAN, ou Subject Alternative Name, est une extension X.509 qui répertorie chaque domaine couvert par un seul certificat. Dans ce champ, les entrées peuvent être des noms de domaine ordinaires, des entrées wildcard, ou un mélange des deux.

Une configuration typique ressemble à ceci :

• example.com
• *.example.com
• *.brand.net

Ce certificat unique sécurise désormais le domaine nu example.com, chaque sous-domaine de premier niveau qui en dépend (shop.example.com, blog.example.com, etc.), ainsi que chaque sous-domaine de premier niveau de brand.net.

La plupart des produits de cette catégorie prennent en charge jusqu’à 250 SAN au total, bien que certaines marques fixent une limite inférieure par défaut et d’autres une limite supérieure. Notez que le caractère wildcard * couvre exactement un niveau de sous-domaine.

Le choix entre les trois dépend de la structure de vos domaines :

• Vous gérez un seul site web avec de nombreux sous-domaines ? Un certificat wildcard suffit.
• Vous avez plusieurs sites web distincts sans structure de sous-domaines à gérer ? Un certificat multi-domaines (SAN) est moins cher et plus simple.
• Dès lors que vous avez plusieurs sites web et des sous-domaines sous chacun, le certificat multi-domaines wildcard est le seul produit qui couvre les deux configurations dans un seul certificat, ce qui explique pourquoi les acheteurs disposant d’un portefeuille de marques ou de domaines clients hébergés finissent par choisir cette option.

Les certificats multi-domaines wildcard sont émis à deux niveaux de validation : Domain Validation et Organization Validation. Chacun vérifie quelque chose de différent concernant le demandeur avant l’émission du certificat.

• DV vérifie uniquement que le demandeur contrôle les domaines listés.
  La validation s’effectue via l’une des trois méthodes (e-mail, enregistrement DNS ou vérification de fichier HTTP) et les certificats sont émis en quelques minutes. Les sites personnels et les environnements de développement/test correspondent à ce niveau, tout comme les outils internes et les plateformes SaaS où la rapidité prime sur l’identité organisationnelle affichée.
• OV vérifie l’entreprise demandeuse via des registres officiels :
  Immatriculation de l’entreprise, adresse enregistrée et rappel téléphonique vers un numéro vérifié. L’émission prend 1 à 2 jours ouvrables. Le nom de l’entreprise vérifié apparaît dans les détails du certificat, où les acheteurs, les équipes de sécurité (et les responsables des achats, dans les transactions importantes) peuvent le consulter. Les sites e-commerce, les secteurs réglementés et toute propriété pour laquelle la déclaration d’identité du certificat a une valeur commerciale bénéficient de la vérification OV.

Extended Validation n’est proposé pour aucun produit multi-domaines wildcard, où que ce soit.

Les Baseline Requirements du CA/Browser Forum interdisent les entrées SAN wildcard sur les certificats EV, et cette règle s’applique à tout certificat comportant ne serait-ce qu’une seule entrée wildcard. Cette disposition existe depuis la définition initiale de l’EV et n’a pas changé. Les pages affirmant qu’un « EV multi-domaines wildcard » existe sont dans l’erreur. Si vous avez besoin de l’EV pour un domaine spécifique, achetez-le sous la forme d’un certificat EV mono-domaine distinct, en complément de votre certificat multi-domaines wildcard.

Un dernier point qu’il convient de préciser clairement : la robustesse du chiffrement est identique pour DV, OV et EV. Les trois négocient le même chiffrement symétrique 256 bits lors de la poignée de main TLS. Le niveau de validation change ce que la CA vérifie concernant le demandeur, et non ce qui est chiffré sur le réseau.

Le 11 avril 2025, le CA/Browser Forum a approuvé le Ballot SC-081v3, un calendrier progressif qui réduit la durée de vie maximale de chaque certificat TLS public à 47 jours. Ce calendrier comporte trois phases :

• Phase 1 – déjà en vigueur depuis le 15 mars 2026 : la validité maximale des certificats TLS publics est désormais de 200 jours.
• Phase 2 – 15 mars 2027 : la limite passe à 100 jours.
• Phase 3 – 15 mars 2029 : la limite passe à 47 jours.

Cette règle s’applique à tous les certificats TLS publics, à tous les niveaux de validation (DV, OV, EV) et à tous les types de produits : wildcard, multi-domaines et multi-domaines wildcard inclus.

Les acheteurs de certificats multi-domaines wildcard ressentent ce changement plus fortement que les acheteurs de certificats uniques. Un renouvellement est ici plus lourd, car vous devez re-prouver le contrôle de chaque domaine figurant dans la liste SAN, et pas seulement d’un seul. À mesure que le plafond de validité diminue, ce coût opérationnel s’accumule. D’ici 2029, vous effectuerez ce cycle de renouvellement environ toutes les 6 à 7 semaines. Toute personne planifiant des opérations pluriannuelles sur un portefeuille de domaines devrait envisager l’automatisation dès maintenant, et non en 2029.

Si vous êtes prêt à automatiser, commencez par notre page ACME. Une mise en garde honnête : tous les produits multi-domaines wildcard du marché ne sont pas également compatibles avec l’automatisation. Les produits DV avec des vérifications simples du contrôle de domaine s’automatisent facilement ; les produits OV qui nécessitent des cycles de re-validation de l’organisation ajoutent des contraintes que ACME seul ne résoudra pas.

SSL Dragon propose des certificats EV de quatre autorités de certification.

• Portefeuilles d’entreprises multi-marques
  Une entreprise qui possède plusieurs domaines de marque ainsi que des sous-domaines sous chacun (brandA.com, *.brandA.com, brandB.net, *.brandB.net) peut remplacer quatre achats de certificats distincts ou plus par un seul certificat émis.
• Plateformes SaaS avec sous-domaines par client
  Lorsque chaque client dispose d’un sous-domaine personnalisé tel que customer1.app.com et customer2.app.com, la couverture wildcard sur le domaine de l’application gère un nombre illimité de clients. Les emplacements SAN restants couvrent le site marketing, la page de statut et l’API sur des domaines différents.
• Hébergeurs et agences
  La gestion des domaines clients sur de nombreuses marques, toutes servies depuis une infrastructure partagée, correspond parfaitement à ce produit. Un seul certificat, un seul cycle de renouvellement, une seule clé privée à faire tourner.
• Environnements Microsoft Exchange et communications
  Les certificats multi-domaines wildcard fonctionnent comme des Unified Communications Certificates (UCC), ce qu’Exchange requiert lorsqu’il a besoin que plusieurs noms d’hôtes de service – autodiscover, mail, webmail et autres – soient représentés sur le même certificat.

1. Tous les domaines listés sont publics sur le certificat. Toute personne qui clique sur le cadenas et inspecte les détails du certificat peut lire chaque domaine figurant dans la liste SAN. Si vous ne souhaitez pas que deux de vos marques soient publiquement associées l’une à l’autre, utilisez des certificats séparés.
2. Une entrée SAN wildcard ne couvre pas automatiquement le domaine nu. Une entrée SAN de *.example.com couvre mail.example.com et shop.example.com, mais ne couvre pas example.com lui-même. Ajoutez le domaine nu comme entrée SAN distincte si vous en avez besoin.
3. Les wildcards standard couvrent un seul niveau de sous-domaine. *.example.com couvre mail.example.com mais pas dev.mail.example.com. Pour sécuriser des niveaux plus profonds, ajoutez le wildcard correspondant comme entrée SAN distincte, par exemple *.mail.example.com.
4. Les réémissions sont gratuites, mais la date d’expiration est conservée. L’ajout ou la suppression d’un SAN en cours de cycle ne remet pas le compteur à zéro ; le nouveau certificat hérite de la date d’expiration d’origine. Pour les produits DV, aucune re-validation n’est requise pour modifier les SAN ; pour les produits OV, la validation organisationnelle existante peut généralement être réutilisée si la modification intervient dans la fenêtre de validité.