Certificats wildcard expliqués | Le guide de la co...

Vue d'ensemble

Un certificat wildcard est un certificat TLS/SSL qui sécurise un domaine et l'ensemble de ses sous-domaines à un même niveau, en utilisant un astérisque (*) comme caractère générique dans le nom de domaine. Un certificat émis pour *.example.com sera valide pour www.example.com, api.example.com, mail.example.com, et tout autre sous-domaine de premier niveau, le tout avec un seul certificat et une seule clé privée.

Pour les organisations qui gèrent des dizaines ou des centaines de sous-domaines, les certificats wildcard réduisent considérablement la charge opérationnelle. Au lieu de demander, valider, installer et renouveler des certificats individuels pour chaque sous-domaine, un seul certificat wildcard les couvre tous. Cette simplification explique pourquoi les certificats SSL wildcard restent l'un des choix les plus populaires pour les infrastructures web, les services internes et les environnements de développement.

Cette commodité s'accompagne toutefois de compromis. Une seule clé privée protège tous les sous-domaines du certificat. Si cette clé est compromise, l'ensemble des services qui la partagent est exposé. Savoir quand un certificat wildcard est le bon choix, quand il ne l'est pas, et comment le gérer en toute sécurité est essentiel pour toute équipe responsable de la PKI et des opérations liées aux certificats.

Qu'est-ce qu'un certificat wildcard ?

Un certificat wildcard est un certificat TLS/SSL qui utilise un astérisque en position la plus à gauche du nom de domaine pour correspondre à n'importe quel sous-domaine de premier niveau. Le caractère wildcard est placé dans le champ Subject Alternative Name (SAN) sous la forme d'une entrée dNSName du type `*.example.com`.

Lorsqu'un client se connecte à `app.example.com`, il vérifie le certificat du serveur. Si le SAN contient `*.example.com`, le client fait correspondre `app` au caractère générique et la connexion est établie. Le même certificat fonctionne pour `www.example.com`, `staging.example.com`, `intranet.example.com`, ou tout autre nom à ce niveau.

Point essentiel : l'astérisque ne correspond qu'à un seul label. Un certificat wildcard pour `.example.com` ne couvre pas `example.com` lui-même (le domaine racine), ni les sous-domaines multi-niveaux comme `api.staging.example.com`. Le domaine racine doit être ajouté comme entrée SAN distincte, et les sous-domaines plus profonds nécessitent leurs propres certificats ou un wildcard supplémentaire comme `.staging.example.com`.

Comment fonctionnent les certificats wildcard

1

Génération de la paire de clés

L'organisation génère une paire de clés publique-privée, comme pour tout certificat TLS. La clé privée doit être stockée en toute sécurité, car elle protégera l'ensemble des sous-domaines couverts par le wildcard.

2

Certificate Signing Request (CSR)

Un CSR est créé avec le Common Name ou le SAN défini à `*.example.com`. La plupart des organisations incluent également le domaine racine `example.com` comme entrée SAN supplémentaire, afin qu'un seul certificat couvre les deux.

3

Validation de domaine

L'autorité de certification (CA) valide le contrôle du domaine de base. Pour les certificats wildcard DV, cela implique généralement un enregistrement DNS TXT ou un défi HTTP sur le domaine de base. La validation OV et EV ajoute des vérifications d'identité organisationnelle.

4

Émission et installation

La CA signe le certificat et le retourne. Le certificat et la clé privée sont installés sur chaque serveur ou load balancer qui héberge les sous-domaines sous `example.com`. Chaque déploiement utilise le même fichier de certificat, mais devrait idéalement utiliser des copies indépendantes de la clé privée, protégées par des contrôles d'accès ou un HSM.

5

Correspondance côté client

Lorsqu'un navigateur ou un client API se connecte à `api.example.com`, il reçoit le certificat wildcard. La bibliothèque TLS compare le nom d'hôte demandé à chaque entrée SAN. Le motif wildcard `*.example.com` correspond à n'importe quel label unique à la place de l'astérisque, la connexion est donc acceptée.

Wildcard, SAN ou mono-domaine : comment choisir

Le choix du type de certificat dépend de l'architecture de votre domaine, de vos exigences de sécurité et de votre maturité opérationnelle.

Un certificat mono-domaine offre la plus petite surface d'attaque : si sa clé est compromise, un seul service est touché. Un certificat wildcard troque cette isolation contre la commodité, couvrant un nombre illimité de sous-domaines avec un seul certificat. Un certificat SAN offre le plus de flexibilité, en autorisant des domaines non liés sur un même certificat, mais chaque domaine doit être listé explicitement et le certificat doit être réémis lorsque la liste change.

De nombreuses organisations combinent ces approches. Un certificat wildcard couvre `*.example.com` pour l'infrastructure web générale, tandis que des certificats SAN ou mono-domaines individuels protègent les services à haute sécurité où l'isolation des clés est requise.

Certificat mono-domaine

Couvre un seul FQDN (par exemple www.example.com). Rayon d'impact minimal : si sa clé est compromise, un seul service est affecté. Disponible en DV, OV et EV. Idéal pour les applications individuelles et les microservices où l'isolation des clés est importante.

Certificat wildcard

Couvre un domaine et l'ensemble de ses sous-domaines de premier niveau (par exemple *.example.com). Nombre illimité de sous-domaines à un même niveau, mais ne couvre pas les sous-domaines multi-niveaux comme api.staging.example.com. Disponible uniquement en DV et OV (pas d'EV). Rayon d'impact élevé : tous les sous-domaines partagent une même clé. Idéal pour les organisations qui gèrent de nombreux sous-domaines sous un même domaine.

Certificat SAN (multi-domaines)

Couvre plusieurs FQDN non liés dans un seul certificat (de 5 à plus de 100 domaines distincts). Chaque sous-domaine doit être listé explicitement. Disponible en DV, OV et EV. Rayon d'impact moyen à élevé selon le nombre de SAN. Idéal pour les CDN, les plateformes SaaS et l'hébergement multi-marques.

Quand utiliser les certificats wildcard

Sous-domaines en forte croissance

Si votre équipe crée fréquemment de nouveaux sous-domaines pour des microservices, des environnements de pré-production ou des applications destinées aux clients, un certificat wildcard évite les délais et la charge liés à l'émission d'un nouveau certificat pour chacun.

Environnements de développement et de pré-production

Les certificats wildcard sont idéaux pour les environnements hors production, où `dev.example.com`, `staging.example.com` et `test.example.com` ont tous besoin d'un TLS valide sans gestion individuelle.

Infrastructure web unifiée

Lorsqu'un même domaine héberge de nombreux sous-domaines (www, blog, shop, app, docs), un wildcard simplifie la configuration sur les reverse proxies et les load balancers.

Services internes

Les intranets d'entreprise et les API internes sous un domaine partagé tirent parti des certificats wildcard émis par une PKI privée, ce qui réduit la charge de gestion sans exposer les certificats à l'internet public.

Quand éviter les certificats wildcard

Validation étendue (EV) requise

Les CA n'émettent pas de certificats wildcard EV. Si vos exigences de conformité ou de marque imposent une validation EV, vous devez utiliser des certificats mono-domaines ou SAN.

Services isolés à haute sécurité

Les points d'accès de traitement des paiements, les passerelles d'authentification et les services API qui manipulent des données sensibles doivent disposer de leurs propres certificats avec des clés privées dédiées. Partager une clé wildcard entre ces services crée un risque inacceptable.

Architectures de sous-domaines multi-niveaux

Si votre infrastructure utilise des hiérarchies profondes de sous-domaines comme `api.us-east.prod.example.com`, un seul certificat wildcard ne peut pas les couvrir. Il faudrait des wildcards distincts à chaque niveau, ce qui annule rapidement le bénéfice en termes de gestion.

Environnements nécessitant une révocation par service

Si un service est compromis, révoquer un certificat wildcard coupe le TLS pour l'ensemble des sous-domaines qu'il couvre. Lorsqu'une révocation granulaire est requise, des certificats individuels sont le choix le plus sûr.

Risques de sécurité et bonnes pratiques

La principale préoccupation de sécurité liée aux certificats wildcard est le rayon d'impact d'une compromission de clé. Comme la même clé privée authentifie tous les sous-domaines, un attaquant qui l'obtient peut usurper l'identité de n'importe quel service du domaine, intercepter le trafic via des attaques de l'homme du milieu et déchiffrer les sessions capturées.

1

Protégez la clé privée

Stockez les clés privées des certificats wildcard dans des modules de sécurité matériels (HSM) ou des coffres-forts à clés sécurisés. Ne les stockez jamais en clair sur les serveurs applicatifs, dans les dépôts de code source ou dans des fichiers de configuration partagés.

2

Limitez la distribution de la clé

Ne copiez pas le même fichier de clé privée sur chaque serveur. Utilisez une terminaison TLS centralisée au niveau de votre load balancer ou de votre reverse proxy, ou déployez des copies distinctes de la clé avec des permissions de système de fichiers strictes. Moins la clé existe à de nombreux endroits, plus la surface d'attaque est réduite.

3

Raccourcissez la durée de vie des certificats

Des durées de vie plus courtes limitent la fenêtre d'exposition en cas de compromission. Combinez les certificats wildcard avec un renouvellement automatisé via ACME pour rendre la rotation fréquente concrètement praticable.

4

Surveillez avec la Certificate Transparency

Les journaux Certificate Transparency (CT) consignent chaque certificat publiquement reconnu comme fiable. Surveillez les journaux CT pour détecter des certificats wildcard inattendus émis pour votre domaine, ce qui pourrait indiquer un compte CA compromis ou un certificat émis à tort.

5

Segmentez par périmètre de confiance

Utilisez des certificats wildcard distincts pour des périmètres de confiance distincts. La production et la pré-production ne doivent pas partager de clé wildcard. Les services exposés à l'extérieur et les services internes ne doivent pas non plus partager de clé wildcard. Chaque périmètre de confiance dispose de son propre certificat et de sa propre clé.

6

Préparez un plan de révocation

Sachez à l'avance comment révoquer et remplacer un certificat wildcard sur l'ensemble de vos serveurs en cas de compromission. Documentez le processus, automatisez ce que vous pouvez et testez régulièrement la procédure. Une révocation de wildcard est une urgence qui affecte simultanément tous les sous-domaines.

Gérer les certificats wildcard à grande échelle

Dans les petits environnements, gérer manuellement quelques certificats wildcard reste faisable. Dans les environnements d'entreprise avec des centaines de domaines, plusieurs CA et une infrastructure distribuée, cela devient un défi opérationnel majeur.

Les principales difficultés consistent à suivre quels certificats wildcard existent, où ils sont déployés, quand ils expirent et qui en est responsable. Les shadow certificates, achetés par des équipes individuelles sans supervision centrale, aggravent le problème. Un certificat wildcard que personne ne suit est un certificat wildcard qui expirera sans avertissement, en provoquant potentiellement des interruptions sur tous les sous-domaines qu'il protège.

Une gestion efficace requiert trois capacités. Premièrement, la découverte et l'inventaire : trouver automatiquement chaque certificat wildcard dans votre infrastructure, quelle que soit la CA qui l'a émis ou l'équipe qui l'a déployé. Deuxièmement, l'application des politiques : s'assurer que les certificats wildcard respectent les standards de l'organisation en matière de longueur de clé, d'algorithme, de durée de vie et de domaines autorisés. Troisièmement, la gestion automatisée du cycle de vie : prendre en charge le renouvellement, le déploiement et la rotation sans intervention manuelle, un point particulièrement critique à mesure que la durée de vie des certificats se rapproche de 47 jours.

Les organisations qui s'appuient sur des feuilles de calcul ou des scripts ad hoc pour suivre leurs certificats wildcard finissent inévitablement par subir des échecs de renouvellement. Une plateforme dédiée de gestion du cycle de vie des certificats offre la visibilité, l'automatisation et le contrôle des politiques nécessaires pour exploiter les certificats wildcard en toute sécurité à l'échelle de l'entreprise.

Comment nous aidons

Evertrust & Certificats wildcard : tout ce qu'il faut savoir pour les choisir et les déployer

Visibilité complète sur les wildcards — Evertrust CLM découvre chaque certificat wildcard de votre infrastructure grâce au scan réseau, à la surveillance des journaux CT et à des agents sur les endpoints. Vous obtenez un inventaire unique de tous les certificats wildcard, de leurs emplacements de déploiement et de leurs dates d'expiration.

Application des politiques pour les wildcards — Définissez des règles d'entreprise qui déterminent quels domaines sont autorisés à disposer de certificats wildcard, les tailles minimales de clé, les durées de vie maximales et les workflows d'approbation requis. Evertrust signale les certificats wildcard non conformes avant qu'ils n'atteignent la production.

Renouvellement et déploiement automatisés — Evertrust s'intègre avec ACME, EST et des connecteurs natifs pour les serveurs web, les load balancers et les plateformes cloud. Les renouvellements de certificats wildcard se font automatiquement, le nouveau certificat étant poussé vers chaque point de déploiement, ce qui élimine la coordination manuelle qui rend les renouvellements de wildcards sujets aux erreurs.

Révocation et remplacement instantanés — Si une clé privée wildcard est compromise, Evertrust vous permet de révoquer le certificat et de déclencher la réémission et le redéploiement automatisés sur l'ensemble des serveurs affectés en une seule action, ce qui réduit au minimum la fenêtre d'indisponibilité qui rend les compromissions de wildcards si dangereuses.

Parler à un expert Découvrir CLM

Certificats wildcard : tout ce qu'il faut savoir pour les choisir et les déployer

En bref