Erreur de nom de certificat SSL : comment la diagnostiquer et la résoudre

Votre navigateur affiche un écran rouge : « Le certificat de sécurité de ce site ne correspond pas au nom du serveur », NET::ERR_CERT_COMMON_NAME_INVALID, ou SSL_ERROR_BAD_CERT_DOMAIN. Votre site reste accessible en HTTP mais pas en HTTPS. Diagnostic et résolution.

Ce que signifie l'erreur

Quand un navigateur se connecte à un site en HTTPS, il vérifie que le certificat SSL/TLS présenté par le serveur couvre bien le nom de domaine demandé. Si vous accédez à www.exemple.fr mais que le certificat ne mentionne que exemple.fr, le navigateur refuse la connexion.

Techniquement, le navigateur vérifie le champ Subject Alternative Name (SAN) du certificat. Depuis 2017, les navigateurs ignorent le champ Common Name (CN) : seule la liste SAN fait foi.

Les 6 causes les plus fréquentes

1. SAN manquant (www ou domaine nu absent)

Cas classique : le certificat couvre exemple.fr mais pas www.exemple.fr, ou l'inverse. Le site marche sur une URL et casse sur l'autre.

Diagnostic — afficher les SAN du certificat :

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

Solution : régénérer un certificat incluant les deux variantes (avec -addext "subjectAltName=DNS:exemple.fr,DNS:www.exemple.fr" dans OpenSSL, ou simplement en passant les deux domaines à certbot : certbot -d exemple.fr -d www.exemple.fr).

2. Mauvais vhost sélectionné (erreur SNI)

Sur un serveur qui héberge plusieurs sites HTTPS, Apache ou Nginx sélectionne le bon certificat grâce au SNI (Server Name Indication) envoyé par le client. Si la configuration du vhost est incorrecte, le serveur peut retomber sur un certificat par défaut qui ne correspond pas.

Diagnostic Apache :

apachectl -S     # liste les vhosts et leurs certificats
apachectl -t     # vérifie la syntaxe de la config

Solution : vérifier que chaque vhost a bien son ServerName et ses directives SSLCertificateFile / SSLCertificateKeyFile. Sous Nginx : server_name + ssl_certificate cohérents dans chaque bloc server.

3. Certificat auto-signé par défaut

Certains panneaux d'hébergement (cPanel, Plesk) génèrent automatiquement un certificat auto-signé quand aucun certificat valide n'est configuré. Résultat : le CN du certificat est localhost ou le FQDN du serveur, pas votre domaine.

Solution : installer un vrai certificat Let's Encrypt ou commercial via le panneau d'administration, ou en ligne de commande :

certbot --nginx -d www.exemple.fr -d exemple.fr

4. Enregistrement DNS pointant vers le mauvais serveur

Le domaine www.exemple.fr résout vers une IP qui n'héberge pas votre site (ancienne migration oubliée, CDN mal configuré). Le certificat présenté est celui du serveur cible, pas le vôtre.

Diagnostic :

dig www.exemple.fr +short
curl -vI https://www.exemple.fr 2>&1 | grep -i "subject"

Solution : corriger les enregistrements A/AAAA/CNAME chez votre registrar pour pointer vers le bon serveur.

5. Proxy ou CDN mal configuré

Si vous utilisez Cloudflare, un reverse-proxy ou un CDN, le certificat vu par le navigateur est celui du proxy, pas le vôtre. Problèmes fréquents : domaine pas encore provisionné chez le CDN, mode SSL mal réglé (Full/Strict vs Flexible), certificat origin expiré.

Solution : vérifier dans l'interface du CDN que le domaine est bien actif et que le certificat edge est émis. Chez Cloudflare, c'est dans SSL/TLS → Edge Certificates.

6. Certificat expiré ou chaine incomplète

Techniquement ce n'est pas une erreur de nom, mais les messages d'erreur se ressemblent. Un certificat expiré ou une chaîne intermiédiaire manquante produit des erreurs similaires qui peuvent être confondues.

Diagnostic complet via SSL Labs : score, dates de validité, chaîne de certification, SAN, protocoles supportés.

Méthode de résolution en 3 étapes

Prévenir : automatiser

La plupart des erreurs de nom de certificat viennent d'une configuration manuelle oubliée lors d'un ajout de sous-domaine ou d'une migration. La solution durable, c'est l'automatisation :

• Let's Encrypt + certbot : renouvellement automatique tous les 60 jours, avec régénération de SAN si vous ajoutez un domaine.
• Wildcard : un certificat *.exemple.fr couvre tous les sous-domaines et évite les SAN manquants (nécessite validation DNS-01).
• Monitoring : surveillance des expirations et des SAN via status page, Uptime Kuma ou SSL Labs API.

Avec la réduction progressive de la durée de vie des certificats à 47 jours d'ici 2029, la gestion manuelle devient intenable. Sur les serveurs infogérés Datacampus, la génération, le renouvellement et le déploiement des certificats sont entièrement automatisés. Une erreur de nom de certificat devient l'exception, pas la règle.