Site multilingue avec sous-domaines : quel certificat SSL choisir ?

Si un site multilingue utilise des sous-domaines de même niveau tels que en.example.com, de.example.com et fr.example.com, et que d’autres versions linguistiques seront ajoutées par la suite, un certificat wildcard est généralement plus facile à gérer. Avant de l’acheter, vérifiez toutefois qu’il couvre également le domaine principal example.com et que la plateforme de création de sites, le CDN ou le serveur prend en charge son déploiement.

Si le site ne comporte que quelques versions linguistiques définies, un certificat multidomaine ou des certificats à domaine unique émis séparément peuvent également répondre aux besoins. Le choix ne dépend pas du nombre de langues en soi, mais des noms d’hôte complets à protéger, de la hiérarchie des domaines et de l’endroit où la connexion HTTPS prend fin.

Dressez la liste des domaines à protéger

Un certificat SSL vérifie le nom d’hôte figurant dans l’adresse consultée, et non la langue de la page, le répertoire du site ou l’adresse IP du serveur. Par conséquent, example.com/en/ et example.com/de/ utilisent le même nom d’hôte : il n’est pas nécessaire d’étendre la couverture du certificat en raison de la différence de langue. En revanche, en.example.com et de.example.com sont deux noms d’hôte distincts.

Lors de l’inventaire des domaines, ne vous limitez pas aux pages d’accueil des versions linguistiques. Incluez également le domaine principal, l’adresse www ainsi que les sous-domaines distincts réellement utilisés, par exemple pour une boutique en ligne ou un formulaire de demande de renseignements. Même une adresse qui ne sert qu’à rediriger doit disposer d’un certificat valide : lors de l’accès à une adresse HTTPS, le navigateur effectue d’abord la négociation TLS, puis reçoit les instructions de redirection. Une redirection ne peut pas corriger un certificat qui ne correspond pas au nom d’hôte.

Un wildcard ne couvre que le niveau indiqué, pas toute l’arborescence du domaine

*.example.com peut correspondre à en.example.com, de.example.com et www.example.com, mais pas à example.com ni à shop.en.example.com.

Certains certificats wildcard incluent également le domaine principal, mais cela dépend de la configuration des domaines lors de l’émission du certificat et ne découle pas automatiquement de la nature wildcard du certificat. Vérifiez la liste des noms alternatifs du sujet (SAN) du certificat au lieu de vous fier uniquement à la mention « wildcard » dans le nom du produit.

Si le site utilise en.example.com et que la boutique utilise shop.en.example.com, le certificat doit couvrir les deux niveaux. Pour quelques adresses de boutiques définies, il suffit d’ajouter leurs noms d’hôte complets : il n’est pas nécessaire d’acheter un certificat wildcard pour chaque niveau.

Les versions linguistiques sont-elles fixes ou continueront-elles à s’ajouter ?

S’il n’y a que quelques sous-domaines définis, vous pouvez inclure le domaine principal, www et les sous-domaines linguistiques dans un certificat multidomaine. Celui-ci répertorie les noms d’hôte autorisés un par un dans les SAN, ce qui délimite clairement sa couverture. Toutefois, lors de l’ajout d’une nouvelle version linguistique, il faut mettre à jour la liste des domaines, puis réémettre et déployer le certificat.

Si de nouvelles versions linguistiques sont ajoutées régulièrement et qu’elles se trouvent toutes au même niveau de domaine, un certificat wildcard demande moins de maintenance. Lors de l’ajout de es.example.com, il n’est pas nécessaire de réémettre le certificat pour ce nom, à condition que le DNS, la configuration du site et le déploiement du certificat soient corrects. Un wildcard ne crée toutefois pas automatiquement de sous-domaines et n’active pas HTTPS pour les nouveaux sites.

Si les différentes langues utilisent des domaines distincts tels que example.de et example.fr, un certificat *.example.com ne peut pas les couvrir. Vous pouvez alors opter pour un certificat multidomaine ou faire émettre un certificat distinct pour chaque site. Le choix doit tenir compte de l’emplacement du déploiement et des responsabilités de maintenance, plutôt que de viser uniquement à réduire le nombre de certificats.

Avant l’achat, vérifiez si la plateforme fournit déjà un certificat

Une plateforme de création de sites hébergée ou un CDN peut déjà prendre en charge l’émission et le renouvellement automatiques des certificats. Si le service couvre déjà tous les sous-domaines linguistiques, il n’est pas forcément nécessaire d’acheter un certificat séparément. Certaines plateformes n’autorisent pas non plus le téléversement de certificats achetés séparément. Vérifiez d’abord les domaines pris en charge, la prise en charge des certificats wildcard et l’inclusion éventuelle du service de certificats dans votre forfait actuel.

Avec un CDN, distinguez les deux connexions : celle entre le navigateur et le CDN, et celle entre le CDN et le serveur d’origine. Un certificat valide sur le nœud périphérique du CDN ne garantit pas que le certificat du serveur d’origine soit lui aussi correct. Le certificat utilisé sur le serveur d’origine doit respecter les exigences du CDN en matière de chiffrement et de validation des certificats. Un certificat du serveur d’origine destiné uniquement à la connexion du CDN au serveur ne peut pas être utilisé directement comme certificat public reconnu par les navigateurs.

Si plusieurs sites linguistiques sont répartis sur différents serveurs, l’utilisation d’un même certificat wildcard implique la distribution de la clé privée correspondante. Une fuite de cette clé peut affecter les autres sites qui utilisent la même clé. Pour les sites gérés par différentes équipes ou différents prestataires, des certificats distincts facilitent l’isolation des risques et réduisent la coordination nécessaire entre les équipes lors des renouvellements.

Ne confondez pas le niveau de validation avec la couverture du certificat

DV, OV et EV désignent des méthodes de validation de l’identité ; les certificats à domaine unique, multidomaines et wildcard décrivent leur mode de couverture des domaines. Il s’agit de deux dimensions différentes. L’achat d’un certificat OV n’augmente pas automatiquement le nombre de sous-domaines linguistiques pouvant être protégés. À configuration TLS identique, le niveau de validation ne permet pas non plus, à lui seul, de déterminer la robustesse du chiffrement.

Si l’objectif est simplement de permettre aux versions linguistiques du site d’utiliser HTTPS normalement, un certificat DV reconnu par les navigateurs et correspondant aux domaines concernés suffit pour les besoins de base. Le choix d’un certificat OV ou EV doit dépendre des exigences de vérification de l’identité de l’entreprise, des contrats ou de la gestion interne, et non du seul fait que le site s’adresse à une clientèle internationale.

Les certificats gratuits peuvent également répondre aux besoins HTTPS, à condition de disposer d’un mécanisme de renouvellement fiable. Avec Let’s Encrypt, par exemple, l’émission d’un certificat wildcard nécessite une validation DNS. Pour automatiser le renouvellement, vérifiez que le service DNS prend en charge l’automatisation correspondante et limitez soigneusement les autorisations associées aux identifiants de l’interface DNS.

Vérifiez chaque adresse lors de la validation avant mise en ligne

Avant de commander un certificat ou d’activer celui fourni par la plateforme, confirmez la liste réelle des noms d’hôte, la couverture SAN, l’emplacement du déploiement et les responsabilités de renouvellement. Il ne suffit pas de vérifier que le service « prend en charge SSL » sans préciser qui gérera les échecs d’émission, les alertes d’expiration et le redéploiement du certificat.

Après la mise en ligne, accédez successivement au domaine principal, à www et à chaque sous-domaine linguistique afin de vérifier la correspondance des domaines, la chaîne de certificats et les redirections HTTPS. Recherchez également les ressources de la page encore chargées en HTTP. L’absence d’avertissement concernant le certificat ne signifie pas que la page est entièrement chargée de manière sécurisée via HTTPS.

Pour une structure comprenant le domaine principal et des sous-domaines linguistiques de même niveau, un certificat wildcard incluant le domaine principal facilite l’extension. Pour quelques sites définis ou des sites déployés séparément, un certificat multidomaine ou des certificats distincts peuvent être plus adaptés. L’achat doit se baser sur une liste de domaines et des conditions de déploiement confirmées, plutôt que d’acheter d’abord un certificat et de modifier ensuite le site pour l’adapter.