ERR_CERT_COMMON_NAME_INVALID : que faire, étape par étape

ERR_CERT_COMMON_NAME_INVALID : ce que le navigateur vous dit

L’erreur NET::ERR_CERT_COMMON_NAME_INVALID signifie que le certificat HTTPS du site est valide, mais qu’il ne couvre pas le nom tapé dans la barre d’adresse. Le navigateur compare ce nom à la liste des noms du certificat. Si www, le domaine nu ou un sous‑domaine manque, il refuse la connexion.

C’est une erreur de correspondance, pas une expiration ni une panne. Elle se corrige en général en moins d’une heure, une fois qu’on sait quel nom manque. Si le certificat est expiré, vous êtes sur une autre erreur. Si vous cherchez un panorama de toutes les erreurs de certificat, c’est l’article général. Ici, on reste sur ce code précis.

Visiteur, ne cherchez pas à passer outre l’avertissement : prévenez le propriétaire du site. Propriétaire, suivez les étapes ci‑dessous.

Pourquoi cette erreur arrive

Le nom de l’erreur est trompeur. Il parle de « Common Name », mais Chrome ne lit plus ce champ. Le SAN (Subject Alternative Name) est la liste des noms de domaine qu’un certificat est autorisé à couvrir. Depuis Chrome 58, seule cette extension sert à comparer le nom visité au certificat source : Google Chrome Enterprise Help. Le principe de comparaison entre le nom attendu et l’identité du certificat est décrit dans la RFC 6125.

Les causes réelles, de la plus fréquente à la plus rare :

• www contre domaine nu : le certificat couvre exemple.fr mais pas www.exemple.fr, ou l’inverse.
• Sous‑domaine oublié : boutique.exemple.fr ou blog.exemple.fr existe dans le DNS, mais le certificat n’a jamais été étendu.
• Certificat d’un autre domaine : sur un mutualisé, le serveur répond avec le certificat par défaut d’un autre site.
• Domaine personnalisé mal relié : chez Vercel ou Netlify, le DNS ne pointe pas (ou pas entièrement) vers la plateforme, donc le certificat n’est jamais émis pour votre nom.
• Redirection mal placée : l’apex redirige vers www, mais l’apex n’a pas de certificat valide. La redirection arrive trop tard, après la négociation TLS.

1. Lire le certificat dans le navigateur

Avant de toucher à quoi que ce soit, identifiez les noms couverts. C’est le diagnostic qui oriente tout le reste.

1. Sur la page d’erreur de Chrome, cliquez sur Avancé. Le message indique souvent de quel domaine provient le certificat servi.
2. Ouvrez les outils de développement (F12), puis le panneau Sécurité et Afficher le certificat.
3. Dans l’onglet Détails, repérez le champ Subject Alternative Name (ou « Autre nom de l’objet »).

Vous obtenez trois cas :

Ce que vous lisez	Ce que ça veut dire
Le SAN contient exemple.fr mais pas www.exemple.fr (ou l’inverse)	Un nom manque : étape 2
Le SAN contient un domaine qui n’est pas le vôtre	Mauvais certificat servi : étape 3
Pas de SAN, ou certificat générique de la plateforme	Le DNS n’est pas relié : étape 4

En ligne de commande, la même lecture se fait ainsi :

openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

L’option -servername est importante : elle simule le navigateur et teste le bon nom. Un point de prudence : Chrome affiche l’entrée du SAN qui correspond au nom, sinon la première. Le nom affiché n’est donc pas forcément le seul couvert source : SSL Dragon, 2026.

2. Couvrir à la fois www et le domaine nu

C’est la cause la plus courante. Un certificat doit lister les deux noms, même si l’un redirige vers l’autre.

Pourquoi ? Une redirection est une réponse HTTP. Or le navigateur vérifie le certificat avant de recevoir cette réponse. Si l’apex n’a pas de certificat valide, la redirection vers www n’est jamais lue. SiteGround le décrit : rediriger le non‑www vers www avec un certificat qui ne couvre que le domaine nu déclenche l’erreur.

À faire :

1. Dans votre hébergeur ou votre gestionnaire de certificats, réémettez le certificat en ajoutant les deux noms.
2. Si vous utilisez Let’s Encrypt via un panneau (cPanel, Plesk), cochez apex et www avant de relancer l’émission.
3. Testez ensuite les deux adresses en navigation privée.

Pour la redirection elle‑même, voir la redirection canonique propre.

3. Sur un mutualisé : le mauvais certificat est servi

Sur un hébergement mutualisé, plusieurs sites partagent une même adresse IP. Le SNI (Server Name Indication) désigne l’extension TLS par laquelle le navigateur indique le nom visité avant que le serveur choisisse le certificat à présenter. Si le serveur ne trouve pas de site (hôte virtuel) pour votre nom, il renvoie son certificat par défaut, celui d’un autre domaine. C’est le symptôme « le SAN contient un domaine qui n’est pas le vôtre ».

Je n’ai pas de source officielle à citer ici : c’est le fonctionnement standard des serveurs web, que l’on constate sur la plupart des mutualisés. Les causes habituelles :

• le domaine a été ajouté chez l’hébergeur sans être associé au bon dossier ;
• un alias ou un sous‑domaine a été créé dans le DNS, mais pas dans le panneau de l’hébergeur ;
• le certificat du nouveau nom n’a pas encore été émis.

Dans le panneau (cPanel, Plesk, hPanel), ajoutez le nom manquant comme domaine ou alias, puis lancez l’émission du certificat pour ce nom. Après une migration, passez aussi par la checklist de site inaccessible.

4. Chez Vercel ou Netlify : relier le domaine correctement

Ces plateformes émettent le certificat toutes seules, mais seulement si le DNS pointe vers elles. Tant que ce n’est pas le cas, votre nom n’a pas de certificat.

Vercel

• Ouvrez Settings > Domains du projet : l’état du certificat s’y affiche.
• Un apex se configure avec un enregistrement A, pas un CNAME. Un CNAME se met sur www.
• Copiez les valeurs affichées par le dashboard. Les cibles CNAME sont propres au projet : celles d’un vieux tutoriel peuvent être périmées source : Vercel, 2026.
• Vérifiez le CNAME avec dig CNAME www.exemple.fr +short. Si l’URL en .vercel.app fonctionne, le problème vient du DNS, du certificat ou du proxy du nom personnalisé source : Vercel, 2026.
• Supprimez tout enregistrement AAAA vers un autre hébergeur et vérifiez qu’aucun CAA n’exclut Let’s Encrypt, car ils bloquent l’émission source : Vercel Community, 2025.

Netlify

• Netlify ajoute automatiquement l’apex quand vous ajoutez www, et inversement : il faut configurer les deux source : Netlify, 2026.
• Valeurs attendues : A de l’apex vers 75.2.60.5, CNAME de www vers votre-site.netlify.app.
• Plusieurs A sur l’apex font échouer le certificat : supprimez les anciens source : Netlify, 2026.
• Sans certificat au bout de 24 heures, cherchez d’abord une erreur DNS source : Netlify, 2026.
• Un certificat personnalisé n’est pas renouvelé automatiquement et doit inclure les sous‑domaines de déploiement concernés. Repassez sur le certificat géré par Netlify si vous n’avez pas de besoin spécifique.

Le détail DNS et SSL de ces deux plateformes est dans l’article sur les domaines personnalisés.

5. Revérifier, puis vider les caches

Après correction, vérifiez trois choses :

1. Les deux adresses (avec et sans www) s’ouvrent en HTTPS sans avertissement.
2. La relecture du SAN, comme à l’étape 1, liste tous les noms attendus.
3. Chaque sous‑domaine utilisé répond avec un certificat qui le couvre.

Si l’erreur persiste après une modification DNS, c’est souvent la propagation. Attendez, puis testez depuis un autre réseau. Pour ce cas, voir le diagnostic DNS.

Tableau récapitulatif : cause, symptôme, solution

Cause	Symptôme dans le SAN	Solution
www ou apex absent	Un seul des deux noms listé	Réémettre le certificat avec les deux
Sous‑domaine oublié	Sous‑domaine absent	Étendre le certificat ou en émettre un dédié
Mutualisé, mauvais site servi	Domaine d’un autre site	Associer le domaine dans le panneau, émettre le certificat
Vercel : DNS différent du dashboard	Certificat générique ou absent	Copier les valeurs A/CNAME, retirer AAAA et CAA bloquants
Netlify : apex ou www non relié	Un nom sans certificat	Pointer les deux vers Netlify, supprimer les A en trop
Redirection sans certificat sur l’apex	Erreur avant la redirection	Certificat valide sur l’apex aussi

FAQ

Pourquoi le message parle‑t‑il de « Common Name » ?

C’est un héritage du nom historique du champ. Chrome ne le lit plus depuis la version 58, et seul le SAN compte. Le message est donc trompeur : c’est le SAN qu’il faut lire.

L'erreur n'apparaît que sur www, pas sur le domaine nu. Pourquoi ?

Le certificat ne liste probablement qu’un des deux noms. Réémettez‑le avec les deux, puis testez les deux adresses séparément.

Cette erreur peut‑elle venir de mon ordinateur ?

C’est rare. Elle vient presque toujours du serveur ou du DNS. Si le site s’ouvre correctement depuis un autre réseau et un autre appareil, cherchez du côté d’un antivirus ou d’un proxy qui intercepte HTTPS.

Un certificat wildcard règle‑t‑il le problème ?

Il couvre les sous‑domaines d’un niveau (*.exemple.fr), mais pas l’apex exemple.fr lui‑même, qui doit être listé séparément. Chez Vercel, un wildcard demande en plus les serveurs de noms Vercel ou une délégation de la validation.

Quand passer la main à un pro

Faites‑vous aider si le certificat se réémet correctement mais que le mauvais nom revient, si plusieurs sous‑domaines dépendent de plusieurs hébergeurs, ou si le DNS est géré par un prestataire injoignable (voir récupérer son domaine). Un certificat qui ne couvre pas un nom est une erreur de configuration évitable : c’est le genre de point qu’une maintenance suivie contrôle avant qu’un visiteur ne le découvre.