Un certificat SSL protège un site web pour chaque nom de domaine qu'il énumère, et pour eux seuls. Entre certificat SSL et www, la règle est stricte : le domaine en www et le domaine nu figurent tous les deux dans le certificat, sinon le navigateur affiche une alerte de sécurité.
Un seul certificat SSL multi-domaines pour le site d'une entreprise ou d'un blog, puis une redirection 301 : un certificat gratuit pour un site professionnel suffit le plus souvent.
Qu'est-ce qu'un certificat SSL, et pourquoi il énumère chaque hôte ?
Un certificat SSL est un document numérique, sous forme de fichier, qui associe une clé publique à une identité : un domaine, et parfois une organisation ou une entreprise. Une autorité de certification, tiers de confiance reconnu par les navigateurs et les systèmes d'exploitation, appose sa signature sur ce document après une vérification. Le navigateur du visiteur contrôle cette signature à chaque connexion, et c'est elle qui fait apparaître le cadenas dans la barre d'adresse.
Le sigle SSL signifie Secure Sockets Layer, le nom du protocole de chiffrement conçu par Netscape au milieu des années 1990. Son successeur, TLS pour Transport Layer Security, l'a remplacé : l'IETF a déclaré SSL 3.0 obsolète en 2015 (RFC 7568), puis TLS 1.0 et 1.1 en 2021 (RFC 8996), et la version actuelle du protocole reste TLS 1.3, publiée en 2018 (RFC 8446). L'usage a pourtant gardé l'ancien terme : hébergeurs, autorités et outils parlent toujours de certificat SSL, de certificat SSL/TLS ou de certificat serveur pour désigner cet objet.
Un certificat SSL ne protège pas « un site » au sens large, il protège une liste d'hôtes. Pour le navigateur, mondomaine.fr et www.mondomaine.fr sont deux hôtes distincts, comme boutique.mondomaine.fr. Si le certificat présenté par le serveur ne mentionne que l'une, l'autre déclenche un avertissement de sécurité. C'est tout le sujet du couple certificat SSL et www : la plupart des propriétaires de site pensent avoir sécurisé leur domaine, alors qu'ils n'ont sécurisé qu'une seule de ses deux portes d'entrée.
Pourquoi utiliser un certificat SSL sur un site internet ?
Utiliser un certificat SSL protège d'abord les données personnelles des utilisateurs. Un formulaire de contact, un formulaire de connexion, une transaction de paiement ou un panier de commande transmettent des informations sensibles ; sans chiffrement, chaque formulaire envoie ces données en clair sur le réseau, lisibles par n'importe quel intermédiaire. Le certificat SSL sert à chiffrer cette communication entre le navigateur de l'internaute et le serveur web, et apporte l'authentification du serveur : une attaque par interception devient inopérante.
La sécurité n'est pas le seul avantage. Un site web sécurisé grâce à un certificat SSL inspire confiance : le cadenas rassure l'internaute avant qu'il ne remplisse un formulaire ou n'achète un produit, alors que la mention « Non sécurisé » le fait fuir. Les navigateurs réservent également plusieurs technologies récentes aux pages sécurisées : HTTP/2 et HTTP/3, la géolocalisation, les service workers ou les notifications. Pour une entreprise, la sécurité des données relève en outre du RGPD, dont l'article 32 cite le chiffrement des données à caractère personnel parmi les mesures adaptées au risque.
Un site web sans formulaire ni compte client n'échappe pas à la règle. Un fournisseur d'accès ou un wifi public peut injecter des publicités ou du code dans une page servie en http ; une connexion sécurisée empêche cette modification. Sécuriser votre site web avec un certificat SSL, sur www comme sur le domaine nu, est aujourd'hui la norme pour tout propriétaire de site, quel que soit son secteur, et l'utilisation de HTTPS concerne désormais la quasi-totalité des pages chargées par les navigateurs qui utilisent les statistiques publiques de Google.
Comment le chiffrement SSL protège la connexion entre navigateur et serveur web
Le chiffrement SSL repose sur une paire de clés. La clé privée reste sur le serveur web et ne doit jamais en sortir ; la clé publique figure dans le certificat SSL, que le serveur envoie à chaque internaute. Cette technologie relève de la cryptographie asymétrique, au cœur de l'infrastructure à clé publique (PKI, public key infrastructure) : ce que la clé publique sert à chiffrer, seule la clé privée peut le déchiffrer, et une signature produite avec la clé privée se vérifie avec la clé publique. Les clés RSA de 2048 bits restent le minimum accepté ; les clés à courbes elliptiques (ECDSA) offrent une sécurité équivalente avec des clés plus courtes et une négociation plus rapide. Au début de la connexion, la négociation SSL (le « handshake » TLS) suit plusieurs étapes : le navigateur annonce les versions du protocole qu'il accepte, le serveur répond avec son certificat, le navigateur vérifie la chaîne de signature jusqu'à une autorité de certification racine qu'il connaît, puis les deux parties dérivent une clé de session commune. Le processus utilise ensuite une cryptographie symétrique, bien moins coûteuse pour le processeur, pour chiffrer le trafic lui-même.
Une fois cette étape franchie, la connexion chiffrée protège les données échangées : identifiants, formulaires, numéro de carte, informations personnelles, cookies de session. Un tiers placé sur le réseau, sur un wifi public par exemple, voit passer des paquets illisibles. Le certificat apporte en plus l'authentification du serveur : sans lui, un attaquant pourrait se faire passer pour le site et recueillir des informations sensibles sans que l'utilisateur s'en aperçoive.
La vérification de l'hôte intervient pendant cette négociation, avant tout échange HTTP. Le navigateur compare l'URL saisie par l'utilisateur avec les hôtes inscrits dans le certificat. Une correspondance exacte, ou couverte par un joker, laisse passer la connexion ; un écart l'interrompt et affiche une page d'erreur. Aucune redirection, aucun code de la page ne peut corriger ce refus, puisque le serveur n'a encore rien envoyé d'autre que son certificat.
D'où vient l'alerte quand l'adresse avec www manque au certificat
L'alerte de sécurité vient du champ Subject Alternative Name (SAN) du certificat SSL. Ce champ liste les noms de domaine que le certificat couvre. Le champ Common Name, longtemps utilisé, n'est plus pris en compte par Chrome depuis sa version 58 en 2017, ni par les autres navigateurs actuels : seul le SAN fait foi. Quand l'hôte saisi n'y figure pas, Chrome affiche NET::ERR_CERT_COMMON_NAME_INVALID, Firefox SSL_ERROR_BAD_CERT_DOMAIN, et Safari un message indiquant que le certificat ne correspond pas au site.
Le piège classique consiste à croire qu'une redirection suffit. Un hébergeur configure le domaine nu avec un certificat, puis redirige www.mondomaine.fr vers mondomaine.fr. Pour un visiteur qui tape l'adresse en http, la redirection fonctionne. Mais une URL https vers www passe d'abord par la négociation SSL, et le navigateur vérifie le certificat de l'hôte demandé avant de recevoir l'ordre d'aller ailleurs. Sans www dans le SAN, l'utilisateur voit l'alerte au lieu de la redirection.
Les liens entrants en www, les anciens favoris, les cartes de visite imprimées et les moteurs de recherche qui ont indexé les deux variantes rendent cette situation fréquente. Un site d'entreprise qui affiche une alerte sur la moitié de ses accès perd la confiance de ses visiteurs bien plus vite que s'il était resté en http. La règle s'applique dans les deux sens : un site principal en www exige aussi que le domaine nu figure dans le certificat SSL, puisque beaucoup d'utilisateurs le tapent sans préfixe.
Le choix de l'URL principale relève d'une autre décision, technique et éditoriale, détaillée dans la réponse faut-il garder le www dans l'adresse d'un site. Quel que soit ce choix, l'hôte secondaire garde besoin d'un certificat valide : elle ne sert qu'à rediriger, mais elle reçoit des visites.
Les types de certificats SSL selon le niveau de validation
Les types de certificats SSL se distinguent d'abord par le niveau de validation, c'est-à-dire par ce que l'autorité de certification vérifie avant d'émettre le certificat. Le chiffrement reste identique d'un niveau à l'autre : un certificat gratuit chiffre la connexion aussi bien qu'un certificat à validation étendue. Ce qui change, c'est l'identité que le certificat atteste, et donc l'information que l'utilisateur peut lire dans le détail du certificat.
| Niveau de validation | Ce que l'autorité vérifie | Délai d'émission | Usage typique |
|---|---|---|---|
| Validation de domaine (DV) | Le contrôle du domaine, par fichier HTTP, enregistrement DNS ou courriel | Quelques minutes | Blog, site vitrine, application web |
| Validation d'organisation (OV) | Le domaine, plus l'existence légale de l'organisation et le nom de l'entreprise | Plus long, selon les registres consultés | Site d'entreprise, extranet, plateforme B2B |
| Validation étendue (EV, extended validation) | Un contrôle approfondi : statut juridique, adresse, signataire habilité | Le plus long des trois | Banque, assurance, service public en ligne |
La validation de domaine, cas général
Un certificat SSL à validation de domaine prouve seulement que le demandeur contrôle le domaine au moment du contrôle. C'est le niveau que délivrent Let's Encrypt, ZeroSSL ou les hébergeurs qui activent HTTPS d'un clic. Pour un certificat SSL et www, la validation porte sur chaque hôte : l'autorité vérifie mondomaine.fr et www.mondomaine.fr séparément, ce qui impose que les deux répondent au moment du contrôle.
Validation d'organisation et validation étendue
Un certificat SSL professionnel à validation d'organisation ajoute le nom de l'entreprise et sa localisation dans le certificat. L'autorité de certification consulte des registres officiels (Kbis, répertoires d'entreprises) et confirme les coordonnées. La validation étendue va plus loin, selon des règles fixées par le CA/Browser Forum. Depuis 2019, Chrome et Firefox n'affichent plus le nom de l'organisation dans la barre d'adresse pour un certificat EV : l'information reste disponible quand l'utilisateur clique sur le cadenas pour afficher le certificat, mais elle ne se voit plus d'emblée. Une entreprise choisit donc un certificat OV ou EV pour des raisons de conformité, d'image ou d'exigence contractuelle, plus que pour l'effet visuel.
Domaine unique, multi-domaines ou wildcard : quel certificat couvre www ?
Un certificat SSL à domaine unique, au sens commercial du terme, couvre souvent deux hôtes : la plupart des autorités ajoutent d'office www au domaine demandé, ou le domaine nu quand la commande porte sur www. Ce comportement n'est pas une règle du protocole, il dépend de l'offre du fournisseur, et c'est la première chose à vérifier avant d'acheter. Trois façons de couvrir www et le domaine nu se comparent ainsi.
| Solution | Hôtes couverts | Point d'attention |
|---|---|---|
| Certificat multi-domaines (SAN) | mondomaine.fr, www.mondomaine.fr et d'autres hôtes listés un par un | La solution la plus simple, gratuite avec Let's Encrypt |
| Certificat SSL wildcard (*.mondomaine.fr) | Tous les sous-domaines d'un niveau, dont www | Ne couvre pas le domaine nu : l'ajouter en SAN |
| Deux certificats séparés | Un hôte chacun | Double surveillance des renouvellements |
Le certificat SSL wildcard surprend souvent. L'étoile remplace un seul niveau : *.mondomaine.fr couvre www.mondomaine.fr et blog.mondomaine.fr, mais ni mondomaine.fr ni a.b.mondomaine.fr. Les autorités et les hébergeurs sérieux ajoutent le domaine nu en SAN au moment de l'émission ; un fournisseur qui ne le fait pas livre un certificat qui déclenche l'alerte sur l'URL sans www. Un wildcard exige en outre une validation par enregistrement DNS (défi DNS-01 chez Let's Encrypt), puisque l'autorité ne peut pas tester par HTTP une infinité de sous-domaines.
Le certificat multi-domaines convient à la grande majorité des sites : il couvre www et le domaine nu, et peut ajouter un domaine racheté, un ancien domaine qui redirige, ou une variante en .com. Let's Encrypt accepte jusqu'à 100 hôtes par certificat. Au-delà de quelques sous-domaines, ou quand de nouveaux hôtes apparaissent souvent (une plateforme qui crée un sous-domaine par client), le wildcard devient plus pratique.
Obtenir un certificat SSL et l'installer pour les deux adresses
Obtenir un certificat SSL passe par trois étapes : générer une paire de clés, envoyer une demande de signature de certificat (CSR, certificate signing request) à l'autorité, puis installer le certificat signé sur le serveur web. Chez un hébergeur mutualisé, le panneau de gestion fait tout cela d'un clic, souvent avec Let's Encrypt ; sur un serveur administré soi-même, un client ACME automatise ces opérations.
Chez un hébergeur ou sur un CMS
La plupart des panneaux d'hébergement (cPanel, Plesk, les consoles propres aux hébergeurs) proposent une case « inclure www » ou l'ajoutent d'office. Le réflexe utile consiste à ouvrir ensuite le détail du certificat pour vérifier la liste réelle des hôtes. Sur WordPress ou un autre CMS, l'installation du certificat ne règle qu'une partie du travail : il faut aussi modifier l'URL du site en https et corriger les ressources appelées en http. Les étapes pour passer un WordPress en HTTPS sans contenu mixte sont détaillées dans une réponse dédiée.
Sur un serveur administré avec Certbot
Avec Certbot, client ACME maintenu par l'Electronic Frontier Foundation, une seule commande obtient un certificat SSL pour les deux hôtes : certbot --nginx -d mondomaine.fr -d www.mondomaine.fr. Certbot configure Nginx (ou Apache avec l'option --apache) et installe une tâche de renouvellement. L'ordre des options compte : le premier hôte donne son nom au dossier du certificat dans /etc/letsencrypt/live/.
Pour une validation par HTTP, les deux hôtes doivent déjà pointer vers le serveur dans la zone DNS : un enregistrement A (et AAAA en IPv6) pour le domaine nu, un A ou un CNAME pour www. Sans cela, l'autorité ne peut pas vérifier le contrôle du domaine et refuse l'émission du certificat. Après un changement d'hébergeur ou un transfert de nom de domaine vers un autre registraire, c'est la cause la plus courante d'un certificat émis pour une seule adresse.
Comment vérifier le certificat SSL d'un site ?
Vérifier le certificat SSL d'un site se fait d'abord dans le navigateur. Un clic sur l'icône à gauche de l'URL, le cadenas dans la barre d'adresse ou son équivalent selon le navigateur, ouvre un panneau qui permet d'afficher le certificat : émetteur, période de validité, date d'expiration et hôtes couverts. La liste des noms se trouve dans l'onglet Détails, à la ligne Subject Alternative Name. Il suffit de taper les deux URL, avec et sans www, et de vérifier que le cadenas apparaît sur chacune.
En ligne de commande, openssl lit le certificat SSL qu'un serveur présente réellement, ce qui évite les surprises de cache :
openssl s_client -connect www.mondomaine.fr:443 -servername www.mondomaine.fr </dev/null | openssl x509 -noout -ext subjectAltName -dates
La commande affiche les hôtes du SAN et la date d'expiration. L'option -servername compte : un serveur qui héberge plusieurs sites choisit le certificat d'après ce nom (SNI), et l'oublier peut afficher le certificat d'un autre site. Des outils en ligne comme SSL Labs de Qualys donnent un rapport complet : chaîne de certification, versions du protocole acceptées, suites de chiffrement, avec une note de A+ à F. Un certificat SSL correct sur l'hôte principal mais absent sur l'autre y apparaît immédiatement.
Certificat SSL gratuit ou payant : ce qui change vraiment
Un certificat SSL gratuit et un certificat SSL payant chiffrent les données de manière identique, avec des algorithmes et une taille de clé identiques. Le navigateur leur accorde une confiance égale et affiche un cadenas identique. La question du coût d'un certificat SSL porte donc sur autre chose que la sécurité de la connexion : le niveau de validation, le support, la garantie et la gestion.
- Niveau de validation : les autorités gratuites délivrent uniquement des certificats DV ; une entreprise qui veut un certificat OV ou EV passe par une autorité commerciale (DigiCert, Sectigo, GlobalSign, Certigna…).
- Garantie : les offres payantes incluent une garantie financière en cas d'erreur de l'autorité, rarement invoquée en pratique.
- Support et gestion : une console de gestion pour suivre de nombreux certificats, une aide humaine, des outils d'inventaire.
- Usages particuliers : signature de code, certificats clients, certificats de messagerie (S/MIME), qui sortent du cadre du serveur web.
Le prix d'un certificat SSL payant varie selon le niveau de validation, le nombre d'hôtes couverts et la présence d'un joker : un DV commercial reste dans le bas de fourchette, un wildcard OV dans le haut, un EV multi-domaines au plus haut. Pour un blog, un site vitrine ou une boutique de taille modeste, un certificat SSL gratuit qui couvre www et le domaine nu répond au besoin. Combien coûte un certificat SSL pour une entreprise dépend donc moins de la technique que de ses exigences de conformité.
Trois conseils pour choisir un certificat SSL qui couvre www
Le premier conseil porte sur la liste des hôtes : un certificat SSL qui ignore www ou le domaine nu pose un problème dès la première visite, quel que soit son prix. Le deuxième conseil concerne l'automatisation : avec la durée de vie des certificats qui raccourcit, une offre sans renouvellement automatique devient une source de pannes, et un fournisseur fiable propose le protocole ACME. Le troisième tient au caractère générique du wildcard : l'astérisque est pratique quand de nouveaux sous-domaines apparaissent souvent, mais il étend également l'exposition en cas de vol de la clé privée, puisqu'un seul fichier protège tous les hôtes. En matière de certificats web, il existe donc un moyen simple de trancher sur le type de certificat : un certificat multi-domaines automatisé pour un site web classique, un wildcard pour une plateforme à sous-domaines, un OV ou un EV quand l'identité de l'organisation doit figurer dans le certificat. À propos du choix entre gratuit et payant, la question se pose surtout pour une entreprise soumise à des exigences de conformité ou à un cahier des charges.
Validité des certificats et renouvellement automatique
La validité des certificats SSL publics raccourcit d'année en année. Selon le calendrier adopté par le CA/Browser Forum en 2025, la période maximale d'un certificat est passée à 200 jours le 15 mars 2026 ; elle doit descendre à 100 jours en mars 2027, puis à 47 jours en mars 2029. Let's Encrypt délivre depuis toujours des certificats de 90 jours ; d'après l'annonce de l'organisme de décembre 2025, son profil optionnel tlsserver est passé à 45 jours en mai 2026, et le profil par défaut doit descendre à 64 jours en février 2027 puis à 45 jours en février 2028.
Avec ces délais, le renouvellement manuel d'un certificat SSL n'est plus tenable. Il doit être confié à l'hébergeur ou à une tâche planifiée (timer systemd ou crontab installés par Certbot). Le renouvellement reprend les hôtes du certificat précédent : un certificat émis sans www sera renouvelé sans www. Pour ajouter l'hôte manquant, il faut relancer une émission qui liste les deux hôtes, avec l'option --expand de Certbot, plutôt qu'attendre l'échéance.
Un certificat expiré produit une alerte NET::ERR_CERT_DATE_INVALID, aussi bloquante qu'une erreur d'hôte. Let's Encrypt a cessé en juin 2025 d'envoyer des courriels avant l'expiration ; la surveillance repose désormais sur le site lui-même, sur l'hébergeur ou sur un service de supervision qui teste les deux hôtes.
Redirection, HSTS et contenu mixte après l'installation
Une fois le certificat SSL et www en place, la redirection fixe l'URL unique que les moteurs indexent. Le serveur renvoie un code 301 de http vers https, et de la variante secondaire vers la principale, en une seule étape si possible : http://mondomaine.fr doit mener directement à https://www.mondomaine.fr (ou l'inverse), sans chaîne de deux ou trois redirections. Google utilise HTTPS comme signal de classement depuis 2014, et Chrome marque les pages en http comme « Non sécurisé » depuis 2018 : les deux adresses en https, l'une redirigée vers l'autre, évitent tout signal contradictoire.
Avant d'activer HSTS
L'en-tête Strict-Transport-Security oblige le navigateur à n'utiliser que https pour un domaine pendant la période indiquée par max-age. Avec la directive includeSubDomains posée sur le domaine nu, il s'applique aussi à www et à tous les autres sous-domaines, y compris un intranet ou un ancien sous-domaine resté en http. La méthode prudente consiste à commencer par un max-age court, contrôler chaque sous-domaine, puis allonger. L'inscription dans la liste de préchargement des navigateurs (hstspreload.org) se retire difficilement : elle ne se sollicite qu'une fois tous les hôtes couverts par un certificat en règle.
Le cadenas reste barré malgré un certificat valide
Un certificat SSL valide n'empêche pas l'avertissement si la page appelle encore une image, un script ou une feuille de style en http. Ce contenu mixte vient en général d'URL absolues stockées dans la base de données du CMS ou codées en dur dans le thème. Les navigateurs bloquent les scripts mixtes et tentent de charger les images en https ; la console du navigateur liste chaque ressource fautive.
Certificat auto-signé, plusieurs serveurs, sous-domaines inutilisés : les cas limites
Un certificat SSL auto-signé porte la signature de son propre créateur et non celle d'une autorité de certification reconnue. Il chiffre la connexion, mais aucun navigateur ne lui fait confiance : chaque visiteur voit une alerte. Il convient à un serveur de test, à un équipement interne ou à un réseau privé où l'on installe soi-même le certificat racine sur les postes, jamais à un site public.
Un certificat SSL unique peut servir sur plusieurs serveurs, derrière un répartiteur de charge par exemple, à condition de copier la clé privée sur chacun, ce qui multiplie les points d'exposition. La solution plus propre consiste à terminer le chiffrement sur le répartiteur ou le CDN, ou à émettre un certificat par serveur avec une liste d'hôtes identique. Un CDN comme Cloudflare présente au visiteur son propre certificat de bord, qui couvre en principe le domaine nu et www ; le serveur d'origine garde alors besoin d'un certificat valide pour que la liaison entre le CDN et l'origine reste chiffrée et vérifiée.
Un sous-domaine qui ne sert à rien n'a pas besoin de certificat SSL s'il ne répond pas en https ; supprimer son enregistrement DNS reste plus simple que de le couvrir. S'il répond, il lui faut un certificat en règle, faute de quoi il affiche une alerte et peut servir de porte d'entrée à une prise de contrôle de sous-domaine. Les autres questions de chiffrement, de mise à jour et de sécurité des sites sont réunies dans la rubrique CMS et sécurité.
Sources : annonce de Let's Encrypt sur le passage de 90 à 45 jours (décembre 2025), exigences de base du CA/Browser Forum (ballot SC-081), RFC 7568, 8446 et 8996 de l'IETF, documentation de Certbot, documentation MDN de Mozilla sur Strict-Transport-Security.
