NET::ERR_CERT_COMMON_NAME_INVALID

Ce que signifie cette erreur et comment la reconnaître

• Chrome ou Edge affiche « Votre connexion n’est pas privée » avec NET::ERR_CERT_COMMON_NAME_INVALID.
• Les détails du certificat indiquent un Common Name ou un Subject Alternative Name correspondant à un autre nom d’hôte.
• Le domaine nu fonctionne, mais un sous-domaine particulier échoue.
• L’erreur apparaît après l’ajout d’un sous-domaine, une modification du DNS, un changement d’hébergement ou l’activation d’un CDN ou d’un load balancer.
• Un serveur mutualisé ou un CDN présente un certificat par défaut, temporaire ou sans rapport.
• Certains utilisateurs ou réseaux voient l’erreur, contrairement à d’autres, ce qui indique souvent des chemins différents selon IPv4, IPv6, le DNS ou le routage edge.

Causes principales, classées par probabilité

1. Le certificat n’inclut pas le nom d’hôte demandé. Le nom d’hôte en erreur peut être absent de la liste des SAN du certificat. Un wildcard peut couvrir certains sous-domaines, mais sa portée doit correspondre au nom demandé.
2. Le serveur sert son certificat par défaut. L’hébergement mutualisé n’a peut-être pas associé le certificat au domaine, ou la sélection du virtual host HTTPS et du certificat via SNI est incorrecte.
3. Un CDN ou un load balancer utilise le mauvais certificat edge. Le nom d’hôte n’est peut-être pas configuré sur le service, ou la requête peut atteindre un listener ou une configuration edge par défaut.
4. Le DNS pointe vers le mauvais endpoint. Un enregistrement A, AAAA ou CNAME incorrect peut envoyer la requête vers un serveur qui présente le certificat d’un autre site. Un enregistrement AAAA incorrect peut affecter les utilisateurs IPv6 même si IPv4 fonctionne.
5. Une migration ou une modification de domaine a désynchronisé les services. Le DNS, le CDN, le serveur d’origine et le certificat peuvent chacun être configurés pour des noms d’hôte ou des endpoints différents.

Comment corriger le problème

1. Identifier le nom d’hôte exact et l’incompatibilité du certificat

Vérifiez le nom d’hôte complet dans la barre d’adresse, avec tous les sous-domaines. Ouvrez les détails du certificat dans le navigateur et examinez le Common Name ainsi que les Subject Alternative Names (SAN). Le nom d’hôte demandé doit apparaître dans la liste des SAN ou correspondre à un modèle wildcard applicable.

Pour effectuer une vérification en ligne de commande, définissez la variable avec le nom d’hôte testé :

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

L’option -servername envoie le nom d’hôte via SNI, ce qui est important sur une infrastructure HTTPS mutualisée. Exécutez les commandes de diagnostic avant de modifier la configuration.

2. Ajouter le nom d’hôte au certificat

Si le certificat couvre le domaine nu mais pas le sous-domaine en erreur, réémettez-le ou remplacez-le par un certificat qui inclut le nom d’hôte requis comme SAN. Un certificat wildcard peut couvrir plusieurs sous-domaines d’un seul niveau, mais vérifiez séparément la couverture du domaine nu et de tout sous-domaine plus profond.

Si vous utilisez Certbot, vérifiez d’abord que vous êtes autorisé à demander et à déployer un certificat pour le domaine, que le webroot est correct et que la méthode de validation convient au serveur. Incluez chaque nom requis dans la demande d’émission :

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

Cette commande obtient un certificat, mais ne l’installe ni ne l’active à elle seule. Utilisez la méthode d’émission et le webroot adaptés au serveur, puis installez le certificat sur l’endpoint qui termine la connexion HTTPS et associez-le au nom d’hôte approprié.

3. Vérifier la configuration de l’hébergement mutualisé et du serveur d’origine

Dans le panneau de contrôle de l’hébergement, confirmez qu’un certificat est installé et associé au domaine ou au sous-domaine exact. Sur un serveur mutualisé, demandez au fournisseur de vérifier la sélection du certificat basée sur SNI et la configuration du virtual host HTTPS.

Ne rechargez ou ne redémarrez le serveur web qu’après avoir confirmé que les fichiers de certificat, les permissions et la configuration sont corrects. Un rechargement ou un redémarrage peut interrompre le service : suivez donc la procédure de changement du fournisseur et obtenez l’autorisation requise avant de l’appliquer.

4. Vérifier la couverture du certificat du CDN et du load balancer

Vérifiez que le nom d’hôte exact est configuré sur le CDN ou le load balancer et inclus dans son certificat edge. Confirmez également que ce nom d’hôte est dirigé vers l’origine prévue.

Si le CDN termine la connexion HTTPS, le certificat de l’origine ne suffit pas à résoudre une incompatibilité dans le navigateur. Le certificat servi par l’endpoint edge public doit couvrir le nom d’hôte. Si le CDN transmet directement HTTPS, examinez plutôt le certificat de l’origine.

5. Vérifier le DNS pour IPv4 et IPv6

Comparez les enregistrements A, AAAA et CNAME du nom d’hôte avec l’endpoint ou la cible fournie par le fournisseur d’hébergement ou du CDN. Vérifiez si le réseau en erreur utilise IPv4 ou IPv6 et si les deux chemins atteignent le service prévu.

Ne corrigez les enregistrements obsolètes ou indésirables qu’après avoir confirmé l’endpoint prévu et la procédure de modification DNS appropriée. Vérifiez le résultat depuis le réseau affecté, car les réponses DNS mises en cache peuvent persister jusqu’à l’expiration de leur TTL.

6. Tester à nouveau le même nom d’hôte HTTPS

Après avoir modifié l’association du certificat, le routage ou le DNS, testez l’URL exacte qui a échoué. Examinez à nouveau le certificat renvoyé et confirmez sa liste de SAN, son émetteur et ses dates de validité. Testez également depuis le réseau affecté ainsi que depuis l’environnement d’hébergement, du CDN ou du serveur, afin de distinguer les différences de propagation ou de resolver d’une mauvaise configuration active.

Prévention et vérification du correctif

• Vérifiez la couverture du certificat chaque fois que vous ajoutez un sous-domaine, modifiez le DNS, migrez l’hébergement ou ajoutez un CDN.
• Utilisez une couverture SAN ou un wildcard correctement limité uniquement après avoir vérifié le domaine nu, les sous-domaines d’un niveau et les noms plus profonds réellement utilisés par le service.
• Maintenez la cohérence entre les enregistrements DNS, les noms d’hôte du CDN, les listeners du load balancer, les virtual hosts de l’origine et les associations de certificats.
• Testez les chemins A et AAAA après toute modification DNS.
• Examinez le certificat servi par l’endpoint public au lieu de vous fier uniquement à l’absence d’un avertissement du navigateur.
• Notez quel service termine la connexion HTTPS afin de modifier le certificat au bon niveau.
• Maintenez des procédures de renouvellement et de déploiement des certificats qui incluent chaque nom d’hôte requis.

Questions fréquentes