Blog GlobalSign

26 mai 2017

À quoi correspond l’erreur «SSL Common Name Mismatch» et comment la résoudre ?

Avez-vous déjà eu ce message d’erreur en essayant d’accéder à un site Web ?

Chrome: votre connexion n'est pas privée

Chrome: ‘Impossible de vérifier que ce serveur est bien example.com; son certificat de sécurité vient de example.com. Cela peut être dû à une mauvaise configuration ou bien à l'interception de votre connexion par un pirate informatique.’

Internet Explorer: ‘Le certificat de sécurité présenté par ce site Web a été émis pour une autre adresse de site web. Les problèmes de certificat de sécurité peuvent indiquer une tentative de duperie ou d’interception des données que vous envoyez sur le serveur’

Dans Internet Explorer : «Le certificat de sécurité présenté par ce site Web a été émis pour une autre adresse de site web. Les problèmes de certificat de sécurité peuvent indiquer une tentative de duperie ou d’interception des données que vous envoyez sur le serveur».

Le message peut prendre différentes formes suivant le navigateur (et sa version) que vous utilisez. Que vous soyez du côté utilisateur ou exploitant, ce type d’erreur ne plaît à personne !

Commençons par expliquer à quoi elle correspond.

Une erreur de correspondance de nom commun se produit lorsque le nom commun ou le Nom de serveur supplémentaire (SAN) de votre certificat SSL/TLS ne correspond pas au domaine ou à l’adresse dans la barre du navigateur. Cela peut arriver lorsque l’on consulte https://exemple.com au lieu de https://www.exemple.com et que les deux ne figurent pas ensemble dans le champ SAN du certificat.

Premièrement, si vous n’êtes pas le propriétaire du site, contactez une personne capable de résoudre le problème. Mais surtout, N’ALLEZ PAS PLUS LOIN. Il est possible que ce message d’erreur s’affiche, car un pirate ou un «hameçonneur» essaie de vous piéger en faisant passer un faux site Web pour le site que vous cherchez à consulter.

Le site ou le domaine vous appartient ? Voici quelques conseils pour vous aider à résoudre le problème.

Mode d’emploi pour résoudre une erreur de correspondance de nom commun :

Plusieurs raisons peuvent être à l’origine du problème. Commencez par mener une analyse approfondie. Tapez le domaine de votre site Web dans le SSL Checker de GlobalSign.

entering the domain of your website into GlobalSign’s SSL checker.

Figure 1 Résultats après utilisation du SSL Checker sur le site Web présentant une erreur de correspondance

Pour ce type de vérification, on cherchera tout d’abord à découvrir quel certificat est actuellement installé sur le serveur ou l’adresse IP. Cela doit normalement vous permettre d’identifier la cause de cette erreur, parmi plusieurs raisons possibles.

Retenez simplement qu’il n’y a aucun souci avec le certificat SSL/TLS ou avec votre site Web, en soi. À un moment donné, entre la personne qui visite un domaine et une autre qui atterrit sur votre site, le mauvais certificat est proposé.

Il vous faudra peut-être contacter votre service informatique pour savoir où le certificat a été installé et où s’effectue sa configuration

Il y a eu erreur, et l’adresse du site Web n’a pas été incluse avec votre nom commun.

C’est peut-être aussi simple que dans l’exemple plus haut. Vous avez acheté un certificat avec le nom commun «www.exemple.com», mais n’avez pas ajouté «exemple.com» comme «Subject Alternative Names» (Noms alternatifs du sujet ou SAN) sur le certificat.

Cliquez sur «Ignore Certificate Mismatch» (Ignorer les erreurs de correspondance de certificat) dans le SSL Checker de GlobalSign pour effectuer une analyse complète du certificat SSL/TLS sur ce domaine. Vous voyez alors si les bons domaines et les bonnes adresses IP figurent dans la section «Common Names» (Noms communs) et «Alternative Names» (SAN).

correct IPs and SANs listed in certificate - common name mismatch error

Figure 2 Résultats après avoir cliqué sur «Ignore Certificate Mismatch» et inspecté tout le certificat.

Lorsque vous commandez un certificat chez GlobalSign avec un nom commun comme www.exemple.com, nous vous offrons gratuitement le nom «exemple.com» si vous faites valider «exemple.com». Si vous indiquez «exemple.com» comme nom commun, notre option SAN pour les communications unifiées vous permet d’ajouter gratuitement www.exemple.com pendant le processus de commande. Vous pouvez aussi l’ajouter après l’émission du certificat, mais devez pour cela modifier vos options SAN.

Le site Web n’utilise pas le protocole SSL, mais partage une adresse IP avec un site qui l’utilise.

Si votre site Web partage une adresse IP avec d’autres sites, cela peut éventuellement avoir un impact. Les solutions ne seront pas les mêmes.

Vous êtes peut-être sur un hébergement partagé. Certains hébergeurs exigent une adresse IP dédiée pour prendre en charge le SSL. Si l’un des clients qui partage cette adresse IP a installé un certificat SSL/TLS sur l’IP partagée, cela peut interférer avec les autres sites.

Autre possibilité : le client de connexion ou le serveur d’hébergement (ou même les deux) ne prend pas en charge la technologie SNI (Server Name Indication).

Ce serait le cas si le site par défaut «exemple.com» et le site «exemple.org» étaient hébergés sur la même IP. Vous avez des certificats pour les deux qui sont tous deux configurés. Mais, si le serveur ne prend pas en charge le SNI, seul le certificat SSL par défaut sera proposé. Si le client ne prend pas en charge le SNI, seul le certificat du site par défaut sera visible.

Mais si le serveur et le client prennent en charge le SNI, le bon certificat est proposé à chaque fois. La plupart des clients et des serveurs récents prennent en charge le SNI. C’est avec les systèmes plus anciens que des problèmes peuvent survenir.

La solution ? Vous devrez éventuellement prendre en charge le SNI ou obtenir une adresse IP dédiée (ce qui nécessite des modifications dans les paramètres DNS).

Le site n’existe plus, mais le nom de domaine pointe toujours vers l’ancienne adresse IP, où un autre site est désormais hébergé

Les paramètres DNS vous seront utiles ici aussi. Vérifiez que le DNS pointe vers la nouvelle IP, et non l’ancienne !

Les paramètres pré-configurés chez votre fournisseur d’hébergement prévalent sur l’installation de votre certificat.

Il est possible que certains paramètres pré-configurés chez votre hébergeur forcent le SSL sur tous leurs domaines. Si vous achetez un certificat SSL/TLS auprès d’une autre autorité de certification et que vous l’installez, une erreur de correspondance apparaîtra.

Comme indiqué plus haut, cliquez sur «Ignore Certificate Mismatch» dans le SSL Checker de GlobalSign pour voir tous les détails du certificat. Si le nom de votre hébergeur figure dans le nom commun ou le SAN, c’est probablement ce qui se passe.

Contactez alors votre hébergeur et demandez-lui de retirer son certificat pour que vous puissiez installer le vôtre. S’il refuse, changez d’hébergeur, car ce type de pratique est abusif. Vous êtes en droit d’obtenir un certificat SSL/TLS auprès du prestataire de votre choix.

Configurations de votre serveur ou de votre pare-feu.

Soyez attentif au paramétrage de votre pare-feu et de votre dispositif de répartition de charge. Un pare-feu peut notamment être configuré pour récupérer un certificat sur un serveur, même s’il pointe vers plusieurs serveurs. À vous de vérifier que le paramétrage est correct.

Malheureusement, dans ce cas de figure, vous seul pouvez résoudre le problème. Vous devez par conséquent avoir quelques connaissances en informatique ou avoir à vos côtés un collaborateur qui puisse vous aider.

En résumé...

En résumé, il est indispensable de communiquer les bonnes informations lors de la commande. Votre serveur doit également être correctement installé et configuré. Si vous n’êtes pas certain de la manière dont vous devez vous y prendre pour ajouter un SAN ou inclure votre domaine de base au processus de commande, appelez-nous !

Si vous pensez que le problème est lié à votre configuration serveur, prenez plutôt contact avec votre équipe informatique ou votre hébergeur.

Partager ce blog