Certificat SAN expliqué | Le guide de la confiance...

Vue d'ensemble

Un certificat SAN — également appelé certificat multi-domaines ou Unified Communications Certificate (UCC) — est un certificat TLS/SSL unique qui protège plusieurs noms de domaine, sous-domaines ou adresses IP distincts, en listant chacun d'eux dans l'extension Subject Alternative Name. Au lieu d'acheter et de gérer un certificat distinct pour chaque nom d'hôte, les organisations peuvent consolider cinq, dix, voire une centaine de domaines sur un seul certificat.

Les certificats SAN sont le choix standard pour les environnements où plusieurs domaines indépendants nécessitent une protection TLS dans un même déploiement : configurations Microsoft Exchange et Office 365, plateformes SaaS desservant des domaines clients personnalisés, nœuds de périphérie CDN et infrastructures d'hébergement multi-tenant. Ils offrent un équilibre entre la couverture minimale d'un certificat mono-domaine et la flexibilité, limitée aux sous-domaines, d'un certificat wildcard.

Ce guide se concentre sur le certificat SAN en tant que produit : comment en demander un, dans quels cas le choisir plutôt que ses alternatives, les éléments tarifaires à considérer et la gestion de certificats SAN à l'échelle de l'entreprise. Pour une exploration approfondie de l'extension SAN au sens X.509, consultez le guide dédié à Subject Alternative Name.

Qu'est-ce qu'un certificat SAN ?

Un certificat SAN est un certificat TLS/SSL conçu pour protéger plusieurs noms d'hôte au sein d'un même fichier de certificat. Le terme « SAN » renvoie à l'extension Subject Alternative Name définie dans le standard X.509, qui permet à un certificat de lister des identités supplémentaires au-delà du Common Name du Subject.

En pratique, tout certificat TLS moderne utilise l'extension SAN : les navigateurs valident l'identité du serveur par rapport aux entrées SAN, pas au champ CN. Cependant, lorsque l'industrie parle d'un « certificat SAN », elle désigne plus précisément un certificat multi-domaines qui liste plusieurs noms de domaine pleinement qualifiés (FQDN) distincts en tant qu'entrées SAN. Un certificat SAN pour une entreprise pourrait inclure `example.com`, `www.example.com`, `app.example.net` et `portal.example.org` — tous protégés par un seul certificat et une seule clé privée.

Les autorités de certification (CA) commercialisent les certificats SAN avec un nombre de domaines inclus de base (généralement 3 à 5) et proposent des emplacements SAN supplémentaires moyennant un coût additionnel par domaine. Ce modèle tarifaire fait du certificat SAN l'option la plus économique lorsque vous devez sécuriser un nombre modéré de domaines indépendants, sans avoir à acheter un certificat individuel pour chacun.

Comment fonctionnent les certificats SAN

Le fonctionnement d'un certificat SAN est simple. Chaque domaine que le certificat doit protéger est explicitement listé en tant qu'entrée `dNSName` dans l'extension Subject Alternative Name. Lorsqu'un client TLS se connecte à un serveur, il compare le nom d'hôte demandé à chacune des entrées SAN du certificat. Si une entrée correspond, la connexion se poursuit.

Un point essentiel : pour ajouter un nouveau domaine à un certificat SAN existant, vous ne pouvez pas simplement l'y joindre. Vous devez soumettre un nouveau CSR avec la liste SAN mise à jour et demander à la CA de rééditer le certificat. La plupart des CA commerciales autorisent une réédition gratuite pendant la période de validité du certificat, mais le processus de revalidation et de redéploiement reste consommateur de temps.

1

Identifier tous les domaines à sécuriser

Dressez la liste complète des FQDN, sous-domaines et, le cas échéant, adresses IP que le certificat doit couvrir. Contrairement à un certificat wildcard, chaque nom d'hôte doit être énuméré explicitement — il n'y a pas de correspondance par motif.

2

Générer un CSR avec les entrées SAN

Créez une Certificate Signing Request qui inclut tous les domaines cibles dans l'attribut `extensionRequest`. Avec OpenSSL, cela nécessite un fichier de configuration spécifiant chaque SAN. Avec la plupart des portails web des CA, il vous suffit de saisir les domaines supplémentaires lors de la commande.

3

Valider chaque domaine du SAN

L'autorité de certification doit valider le contrôle sur chacun des domaines listés dans le certificat. Pour les certificats DV, cela suppose de réaliser un défi DNS, un défi HTTP ou un défi par e-mail pour chaque domaine indépendamment. C'est l'étape la plus chronophage lorsque les SAN sont nombreux.

4

La CA émet le certificat multi-domaines

Une fois la validation passée pour tous les domaines, la CA émet un certificat unique contenant chaque domaine dans l'extension SAN. Le certificat inclut également la chaîne de confiance complète nécessaire à sa vérification par les navigateurs.

5

Installer et déployer

Installez le certificat et sa clé privée sur chaque serveur ou répartiteur de charge desservant les domaines listés. Chaque serveur présentant ce certificat peut alors répondre aux connexions pour n'importe quel domaine présent dans la liste SAN.

Certificat SAN, wildcard et mono-domaine

Le choix entre un certificat SAN, un wildcard et un certificat mono-domaine dépend de l'architecture de vos domaines et de vos besoins opérationnels.

Un certificat mono-domaine est l'option la plus simple et la moins chère, mais il ne protège qu'un seul nom d'hôte. Si vous gérez plus d'une poignée de domaines, le coût opérationnel du suivi de dizaines de certificats individuels dépasse rapidement les économies réalisées.

Un certificat wildcard couvre un nombre illimité de sous-domaines sous un même domaine (par exemple `*.example.com`), mais il ne peut pas protéger des domaines racines différents. Il ne peut pas non plus prétendre à une validation EV. Si votre infrastructure s'étend sur plusieurs domaines racines, un wildcard seul ne suffit pas.

Un certificat SAN est le bon choix lorsque vous devez sécuriser plusieurs domaines distincts — `example.com`, `example.net`, `brand.io` — au sein d'un même certificat. Il prend en charge la validation EV, autorise le mélange de domaines et de sous-domaines en toute liberté, et certaines CA permettent même de combiner des entrées wildcard et des SAN classiques dans un même certificat.

De nombreuses organisations combinent ces approches : un wildcard pour `*.example.com` afin de couvrir les sous-domaines internes, complété par un certificat SAN pour les domaines exposés aux clients de plusieurs marques.

Certificat mono-domaine

Couvre un seul FQDN. Ajouter un nouveau nom impose un nouveau certificat. Disponible en DV, OV et EV au coût le plus bas. Idéal pour des applications uniques et des microservices.

Certificat wildcard

Couvre un domaine et tous ses sous-domaines de premier niveau. Les nouveaux sous-domaines sont couverts automatiquement. Disponible uniquement en DV et OV (pas d'EV). Coût intermédiaire. Idéal pour de nombreux sous-domaines sous un même domaine.

Certificat SAN (multi-domaines)

Couvre plusieurs FQDN indépendants. L'ajout d'un nouveau domaine impose une réédition avec une liste SAN mise à jour. Disponible en DV, OV et EV. Coût intermédiaire à élevé, avec une tarification au SAN. Idéal pour plusieurs domaines distincts, Exchange/O365 et l'hébergement multi-marques.

Comment demander un certificat SAN

La procédure de demande d'un certificat SAN repose sur la construction d'un CSR incluant tous les domaines nécessaires. Voici comment ajouter des SAN à une requête de certificat avec OpenSSL, l'outil le plus courant.

Dans les environnements utilisant la gestion automatisée des certificats, les outils prenant en charge le protocole ACME peuvent demander des certificats SAN de manière programmatique, en spécifiant plusieurs identifiants de domaine dans la commande. Cela supprime totalement la création manuelle de CSR et la validation.

1

Créer un fichier de configuration OpenSSL

Rédigez un fichier de configuration (par exemple `san.cnf`) qui définit vos entrées SAN. Dans la section `[req]`, définissez `req_extensions = v3_req`. Dans `[v3_req]`, ajoutez `subjectAltName = @alt_names`. Dans `[alt_names]`, listez chaque domaine : `DNS.1 = example.com`, `DNS.2 = www.example.com`, `DNS.3 = app.example.net`, `DNS.4 = portal.example.org`. Vous pouvez également ajouter des adresses IP avec `IP.1 = 192.168.1.1` si nécessaire.

2

Générer la paire de clés et le CSR

Exécutez `openssl req -new -newkey rsa:2048 -nodes -keyout multi.key -out multi.csr -config san.cnf`. Cela produit une clé privée et un CSR contenant l'ensemble de vos entrées SAN. Pour renforcer la sécurité, utilisez `-newkey rsa:4096` ou générez une clé ECDSA avec `openssl ecparam -genkey -name prime256v1`.

3

Vérifier que le CSR contient bien les SAN

Avant de soumettre, inspectez le CSR avec `openssl req -text -noout -in multi.csr` et vérifiez que chaque domaine apparaît sous « X509v3 Subject Alternative Name ». Oublier un domaine à ce stade impose de rééditer le certificat plus tard.

4

Soumettre à votre CA

Téléversez le CSR via le portail ou l'API de votre CA. La plupart des CA proposent également un formulaire web où saisir des SAN supplémentaires lors de la commande, que la CA ajoute à ce qui se trouve déjà dans le CSR. Sélectionnez le nombre d'emplacements SAN inclus dans votre offre et ajoutez-en si le nombre de domaines dépasse la base.

5

Valider chaque domaine

La CA envoie un défi de validation pour chaque domaine de la liste SAN. Pour la validation DNS, vous créez un enregistrement TXT par domaine. Pour la validation HTTP, vous déposez un fichier sur le serveur web de chaque domaine. Tous les domaines doivent réussir la validation avant l'émission du certificat.

6

Télécharger et déployer

Récupérez le certificat émis, installez-le aux côtés de la clé privée sur votre serveur, et configurez votre serveur web ou répartiteur de charge pour qu'il le présente pour tous les domaines listés.

Cas d'usage des certificats SAN

Microsoft Exchange et Office 365

Les serveurs Exchange exigent des certificats couvrant plusieurs noms d'hôte : `mail.example.com`, `autodiscover.example.com`, `owa.example.com` et le FQDN interne du serveur. Le certificat SAN est la solution standard recommandée par Microsoft pour Exchange et les déploiements hybrides Office 365.

Organisations multi-marques

Les entreprises exploitant plusieurs marques ou gammes de produits sous des domaines différents — `brand-a.com`, `brand-b.com`, `brand-c.io` — peuvent consolider tous leurs domaines sur un seul certificat SAN, réduisant ainsi le nombre de certificats à gérer et à renouveler.

Plateformes SaaS avec domaines personnalisés

Les fournisseurs SaaS qui permettent à leurs clients d'utiliser leur propre domaine ont besoin d'un certificat couvrant chacun de ces domaines clients. Un certificat SAN avec une limite élevée (certaines CA prennent en charge plus de 100 entrées) peut y répondre, à condition d'automatiser sa gestion à grande échelle.

Répartiteurs de charge et reverse proxies

Un seul répartiteur de charge terminant le TLS pour plusieurs applications backend peut utiliser un unique certificat SAN au lieu de gérer un certificat distinct par application. La configuration s'en trouve simplifiée et le nombre de certificats stockés sur l'équipement diminue.

Communications unifiées (UC)

Les plateformes VoIP, les serveurs de visioconférence et les systèmes de messagerie exposent souvent plusieurs points d'accès sous des noms d'hôte différents. Les certificats SAN dédiés aux UC (UCC) sont conçus précisément pour ce scénario, couramment utilisés avec Microsoft Skype for Business et Lync.

Environnements de développement et de pré-production

Les équipes qui maintiennent des environnements parallèles sous plusieurs domaines — `dev.example.com`, `staging.example.net`, `test.example.org` — peuvent utiliser un seul certificat SAN pour assurer une terminaison TLS valide sur tous les environnements, sans gestion individuelle de certificats.

Tarification et nombre d'emplacements SAN

La tarification d'un certificat SAN suit un modèle « base + coût par SAN ». Un certificat SAN commercial typique inclut 3 à 5 domaines dans le prix de base, les domaines additionnels coûtant entre 10 et 50 dollars par SAN et par an selon la CA et le niveau de validation.

Les principaux facteurs de coût à évaluer :

- Nombre de SAN inclus de base : certaines CA en incluent davantage que d'autres. Pour 10 domaines, une CA proposant 5 SAN de base est moins chère qu'une CA en proposant 3. - Nombre maximal de SAN : les CA plafonnent généralement les certificats SAN à 100 ou 250 entrées. Si vous approchez de ces limites, plusieurs certificats peuvent s'avérer nécessaires. - Politique de réédition : vérifiez que l'ajout ou la suppression de SAN via réédition est gratuit pendant la période de validité du certificat. La plupart des grandes CA autorisent un nombre illimité de rééditions. - Niveau de validation : les certificats SAN OV et EV coûtent nettement plus cher par SAN que les certificats DV. Évaluez si les indicateurs visuels de confiance d'un EV justifient le surcoût pour votre cas d'usage. - Alternatives gratuites : Let's Encrypt et les autres CA fondées sur ACME émettent des certificats SAN sans frais, avec jusqu'à 100 SAN par certificat. Pour les organisations dotées de l'infrastructure d'automatisation nécessaire à des renouvellements fréquents, cela supprime totalement les coûts de certificats.

Gérer les certificats SAN à grande échelle

Les certificats SAN simplifient le déploiement en consolidant les domaines, mais ils introduisent leur propre complexité de gestion. Chaque ajout, retrait ou modification de domaine impose de rééditer le certificat et de le redéployer sur chaque serveur qui l'utilise. Dans les grands environnements, cela génère des défis de coordination que les processus manuels ne peuvent traiter de manière fiable.

Les principaux risques opérationnels liés aux certificats SAN à grande échelle sont :

Cascades de réédition. Ajouter un seul domaine à un certificat de 50 SAN déclenche une revalidation, une réédition et un redéploiement sur chaque serveur présentant ce certificat. Sans automatisation, le processus est source d'erreurs et chronophage.

Périmètre d'impact. Si la clé privée d'un certificat SAN est compromise, chaque domaine présent sur ce certificat est exposé. Plus le certificat compte de domaines, plus le périmètre d'impact s'étend. Les organisations doivent mettre en balance les bénéfices de la consolidation et ce risque.

Coordination des renouvellements. Lorsqu'un certificat SAN expire, tous les domaines qu'il protège perdent simultanément leur protection TLS. Un renouvellement manqué n'est pas une interruption mono-domaine : c'est une interruption multi-domaines. Une supervision proactive et des workflows de renouvellement automatisés sont indispensables.

Dérive de la liste SAN. Au fil du temps, des domaines sont ajoutés et retirés des certificats SAN sans suivi centralisé. Le résultat : des certificats protégeant des domaines qui n'existent plus et des domaines manquants qui auraient dû être couverts. Un inventaire des certificats qui suit chaque entrée SAN constitue la seule défense efficace contre cette dérive.

Bonnes pratiques pour les certificats SAN

Maintenir la liste SAN au strict nécessaire

N'incluez que les domaines qui doivent réellement partager un certificat. Chaque SAN supplémentaire accroît le périmètre d'impact d'une compromission de clé et le coût de coordination des rééditions. Si des domaines ont des exigences de sécurité ou des cycles de vie différents, utilisez des certificats distincts.

Automatiser la génération du CSR et la validation

La création manuelle de CSR pour des certificats multi-domaines est la principale source d'erreurs : domaines oubliés, fautes de frappe, SAN omis. Utilisez un outillage automatisé ou une plateforme CLM qui génère les CSR de manière programmatique et gère la validation par domaine.

Anticiper la réédition avant d'en avoir besoin

Documentez votre processus de réédition avant la première fois où vous devrez ajouter un domaine. Sachez quel portail ou API de CA utiliser, qui est habilité à modifier la liste SAN et comment le certificat mis à jour atteint chaque point de déploiement.

Surveiller l'expiration sur l'ensemble des SAN

L'expiration d'un certificat SAN est un événement multi-domaines. Configurez des alertes très en amont — 90, 60 et 30 jours avant l'échéance — et vérifiez que chaque serveur présentant le certificat reçoit bien la version renouvelée.

Combiner stratégiquement entrées SAN et wildcard

Certaines CA autorisent les entrées wildcard (par exemple `*.example.com`) aux côtés de SAN classiques dans un même certificat. Vous pouvez ainsi couvrir un nombre illimité de sous-domaines sous un domaine, tout en incluant des domaines indépendants, pour une flexibilité maximale dans un seul certificat.

Protéger la clé privée à la hauteur du risque

La clé privée d'un certificat SAN protège chaque domaine listé. Stockez-la dans un module de sécurité matériel ou un coffre sécurisé, limitez sa diffusion au strict minimum de systèmes et faites-la tourner à chaque cycle de renouvellement.

Comment nous aidons

Evertrust & Certificat SAN : explications, schémas et bonnes pratiques

Inventaire centralisé des certificats SAN — Evertrust CLM découvre et suit chaque certificat SAN de votre infrastructure, offrant une visibilité complète sur les domaines couverts, les points de déploiement de chaque certificat et leurs dates d'expiration. Fini la dérive des listes SAN et les expirations imprévues.

Enrôlement multi-domaines automatisé — Demandez des certificats SAN via une interface unique, Evertrust prenant en charge automatiquement la génération du CSR, l'assemblage de la liste SAN et la validation par domaine. Ajoutez ou retirez des domaines et déclenchez la réédition sans intervention manuelle.

Contrôle de la composition des SAN par politique — Définissez les règles qui régissent quels domaines peuvent figurer sur un même certificat, les nombres maximaux de SAN, les niveaux de validation requis et les motifs de domaines autorisés. Evertrust applique ces politiques au moment de la demande, ce qui prévient la prolifération de certificats et les erreurs de configuration de sécurité.

Automatisation du cycle de vie à grande échelle — Evertrust supervise chaque certificat SAN, déclenche le renouvellement avant l'expiration et déploie les certificats mis à jour sur l'ensemble des serveurs concernés. Que vous gériez 10 certificats SAN ou 10 000, le processus de renouvellement est entièrement automatisé et auditable.

Parler à un expert Découvrir CLM

Certificat SAN : explications, schémas et bonnes pratiques

En bref