Reconnaître une erreur de nom avant de modifier WordPress
Vous ouvrez votre site et le navigateur interrompt la connexion avec un message comme « NET::ERR_CERT_COMMON_NAME_INVALID » ou « SSL_ERROR_BAD_CERT_DOMAIN ». Le certificat présenté ne correspond peut-être pas au nom demandé. Le but est de faire servir un certificat reconnu et adapté à chaque adresse utilisée, sans demander aux visiteurs d’ignorer un avertissement.
Le certificat est présenté pendant l’établissement de la connexion HTTPS, avant que WordPress puisse afficher sa page. Un réglage du thème ou une extension de redirection ne répare donc pas le certificat du serveur. La correction se fait généralement depuis le compte d’hébergement, la gestion du domaine ou le service placé devant le site.
Gardez l’avertissement comme point d’arrêt. Ne saisissez pas vos identifiants sur cette adresse, n’ajoutez pas d’exception de sécurité et ne désactivez pas la validation TLS. TLS est le protocole actuel utilisé pour sécuriser HTTPS ; les panneaux continuent souvent à employer le terme SSL. Pour administrer la réparation, ouvrez directement l’espace client habituel de votre prestataire.
Notez l’adresse exacte, le code d’erreur, l’heure et le dernier changement connu : nouveau domaine, migration, ajout de www ou activation d’un CDN. Retirez les paramètres privés de vos captures. Ces premiers éléments permettent déjà de choisir un contrôle utile.
Lire les noms couverts, sans se limiter au nom principal
Dans les détails du certificat proposés par le navigateur, recherchez « Subject Alternative Name », souvent traduit par « autre nom de l’objet » ou « noms alternatifs ». Cette liste SAN contient les noms DNS couverts. Le champ Common Name, abrégé CN, peut porter un autre libellé : il ne suffit pas à conclure que le certificat est mauvais. Comparez le nom réellement saisi avec les entrées SAN.
Prenons un exemple fictif : un certificat couvrant example.com ne couvre pas automatiquement www.example.com. Le premier est le domaine à la racine, aussi appelé apex ; www est un sous-domaine. L’adresse shop.example.com est encore un autre nom. En revanche, /contact et /blog sont des chemins du même site : ils ne demandent pas des certificats séparés.
Une entrée générique *.example.com peut couvrir www.example.com et shop.example.com, mais pas example.com lui-même, ni paiement.shop.example.com. Un certificat peut réunir plusieurs entrées pour couvrir les noms nécessaires. Le joker d’un enregistrement DNS et celui d’un certificat n’ont pas exactement les mêmes règles.
Même si www doit seulement rediriger vers le domaine principal, son accès en HTTPS nécessite d’abord un certificat valable pour www. La redirection HTTP est transmise après la négociation TLS. Corriger uniquement l’adresse finale laisserait donc les visiteurs venant de l’autre variante devant le même avertissement.
Séparer le nom incorrect des autres erreurs de certificat
Vérifiez les dates de validité et le message détaillé. Un certificat expiré peut couvrir le bon domaine : il faut alors traiter son renouvellement. Une date incorrecte sur l’appareil peut aussi produire une erreur de validité. Une autorité inconnue ou une chaîne incomplète concerne la confiance accordée au certificat ; la chaîne est l’ensemble qui relie le certificat du site à une autorité reconnue.
Ces problèmes peuvent se cumuler. Si le nom demandé apparaît dans les SAN mais que la connexion reste refusée, ne rajoutez pas ce nom plusieurs fois : transmettez le code complet au prestataire pour faire vérifier dates, chaîne et certificat effectivement servi.
Une page HTTPS qui s’affiche mais bloque une image ou un script HTTP relève généralement du contenu mixte. Ce guide ne propose pas de remplacer les liens du contenu. De même, une boucle de redirections entre deux adresses nécessite une autre recherche une fois les certificats valides.
Si le défaut apparaît seulement sur un appareil ou un réseau, comparez les observations avec un navigateur à jour sur une connexion connue, sans franchir l’avertissement. Un réseau d’entreprise ou un logiciel de sécurité peut intervenir dans la connexion. Faites examiner ce cas par son responsable avant de modifier un site qui fonctionne ailleurs.
Préparer les accès et conserver la configuration actuelle
Sur WordPress autohébergé, un compte administrateur WordPress ne donne pas nécessairement accès aux certificats. Identifiez le compte d’hébergement, le gestionnaire DNS et, s’il existe, le CDN. Un CDN est un service intermédiaire qui reçoit les visiteurs avant de joindre votre serveur. Le vendeur du domaine peut être différent du service qui gère ses DNS.
Avant une modification, relevez les noms associés au site, les certificats sélectionnés et les valeurs DNS concernées, avec leur durée de cache appelée TTL. Exportez la zone DNS si l’interface le permet, dans un emplacement privé. Une capture de chaque ligne visée est préférable à une valeur recopiée de mémoire.
Gardez l’accès à l’ancien hébergement pendant une migration tant que la nouvelle destination n’est pas vérifiée. Demandez au prestataire de conserver la configuration TLS précédente. Ne supprimez ni certificat ni clé privée pour « repartir proprement » ; la clé privée ne doit jamais être publiée dans un forum ou copiée dans un ticket ordinaire.
Choisissez ensuite l’approche correspondant aux faits. Une mauvaise destination DNS relève de la deuxième approche ; une destination correcte avec un nom absent du certificat relève de la première. Si le trafic passe par un CDN, la troisième permet d’identifier la connexion réellement en défaut. Ces approches ne sont pas trois modifications obligatoires.
Approche 1 : faire couvrir le bon domaine chez l’hébergeur
Utilisez cette approche lorsque l’hébergeur confirme que le domaine rejoint la bonne installation. Dans son espace client, sélectionnez le site concerné et vérifiez les domaines ou alias qui lui sont rattachés. Ajouter un alias indique au serveur qu’il doit accepter ce nom ; cela ne garantit pas à lui seul qu’un certificat a été émis.
Dans cPanel, le contrôle se trouve dans Sécurité, puis SSL/TLS Status, ou dans SSL/TLS Certificates et son onglet Status sur l’interface unifiée. Filtrez sur le domaine et regardez aussi www. Consultez les détails, le statut et l’éventuelle erreur AutoSSL. Les boutons d’émission dépendent des fonctions activées par l’hébergeur ; l’absence d’un bouton ne justifie pas une modification des fichiers système.
Sur l’interface cPanel unifiée, l’onglet Wizard peut proposer un bouton Let’s Encrypt lorsque l’hébergeur a activé cette possibilité. Si vous ne voyez qu’un parcours d’achat, demandez-lui de confirmer la disponibilité d’AutoSSL avant de commander.
Si un nom nécessaire manque, utilisez le parcours SSL automatique fourni pour ce site, en sélectionnant précisément les noms à protéger. Un nom absent des SAN demande un nouveau certificat couvrant le périmètre voulu, pas une modification manuelle du texte du certificat existant. Préférez le mécanisme inclus dans votre hébergement lorsqu’il convient ; il n’est pas nécessaire d’acheter un certificat uniquement pour ajouter www.
Lisez le récapitulatif avant de confirmer. Les noms sélectionnés doivent correspondre aux adresses utilisées et être validables. Ne cochez pas tous les services du compte par habitude : les noms du webmail, du panneau et des autres sites peuvent relever d’une autre configuration.
- Contrôlez l’association du domaine et de www au bon site.
- Relevez le certificat actuel et le message du gestionnaire SSL.
- Demandez l’émission ou la réémission pour les seuls noms nécessaires.
- Attendez la confirmation, puis vérifiez le certificat réellement présenté au navigateur.
Si le certificat est émis mais que le navigateur en reçoit un autre
Un statut « émis » ne prouve pas que le certificat est installé au bon endroit. Comparez les SAN et les dates visibles depuis le navigateur avec les détails du panneau. Si ce sont deux certificats différents, demandez à l’hébergeur de vérifier leur affectation au site HTTPS et leur déploiement sur les serveurs qui répondent.
Plusieurs sites peuvent partager une adresse IP. Le navigateur transmet normalement le nom voulu pendant la connexion, grâce à l’indication du nom de serveur, appelée SNI, et le serveur choisit le certificat correspondant. Une mauvaise association peut faire apparaître le certificat d’un autre site ou celui par défaut du prestataire. Tester seulement l’adresse IP dans la barre du navigateur ne reproduit pas fidèlement l’accès par domaine.
Si le domaine est correctement couvert mais mal affecté, faites corriger cette affectation plutôt que demander des certificats en boucle. Le prestataire peut aussi devoir recharger la configuration ou harmoniser plusieurs serveurs. Une purge du cache des pages WordPress ne change pas cette sélection.
En cas d’échec après une modification, demandez le rétablissement de la dernière affectation connue comme valide, si son certificat reste utilisable. Ne remettez pas volontairement en service un certificat expiré ou ne couvrant pas le nom pour retrouver une apparence de fonctionnement.
Débloquer la validation du domaine avant une nouvelle émission
L’autorité qui émet le certificat doit vérifier le contrôle des noms demandés. Le service peut le prouver par un fichier accessible sur le site ou par un enregistrement DNS précis. Une demande qui reste en attente peut donc signaler une destination incorrecte, un nom non configuré ou une validation inaccessible.
Pour une validation HTTP-01 de Let’s Encrypt, le serveur doit répondre sur le port 80 au chemin prévu sous .well-known/acme-challenge/. L’hébergeur doit contrôler ce trajet, y compris en présence de plusieurs serveurs ou d’un intermédiaire. Ne désactivez pas toute la protection du site pour rendre un seul chemin accessible.
Pour DNS-01, suivez exactement le nom et la valeur fournis sous _acme-challenge. Ne remplacez pas les autres TXT : ils peuvent servir aux courriels ou à une autre validation. Vérifiez aussi qui prendra en charge les prochaines validations ; une opération manuelle réussie aujourd’hui ne suffit pas à organiser le renouvellement.
Un échec du contrôle CAA peut venir d’une restriction d’autorité ou d’une erreur de réponse DNS. Les enregistrements CAA limitent les autorités autorisées à émettre. Faites identifier la cause et l’autorité réellement utilisée, puis ajuster la règle si nécessaire avec le gestionnaire du domaine, sans effacer toutes les restrictions. Une erreur DNSSEC, liée à la vérification des signatures des réponses DNS, demande également un diagnostic du prestataire DNS. Corrigez la cause indiquée avant de relancer : les demandes répétées peuvent atteindre une limite d’émission.
Approche 2 : corriger une destination DNS prouvée incorrecte
Utilisez cette approche après une migration ou lorsque les variantes du domaine rejoignent des destinations différentes de celles prévues. Ouvrez la zone chez le gestionnaire réellement désigné par les serveurs de noms. Modifier une ancienne zone encore visible chez le vendeur du domaine n’a aucun effet si elle ne fait plus autorité.
Examinez séparément le domaine à la racine et www. Un enregistrement A indique une adresse IPv4, AAAA une adresse IPv6 et CNAME un autre nom à suivre. Comparez leurs valeurs aux consignes propres à votre site dans le compte d’hébergement ou de CDN. N’utilisez pas une adresse trouvée dans un tutoriel.
Une adresse différente de celle du serveur WordPress peut être parfaitement normale derrière un CDN. Faites confirmer la destination attendue avant de remplacer quoi que ce soit. Plusieurs adresses peuvent aussi appartenir à une infrastructure légitime ; leur seule multiplicité ne démontre pas une erreur.
Contrôlez particulièrement AAAA : un ancien serveur IPv6 peut répondre avec un mauvais certificat alors que l’accès IPv4 fonctionne. Let’s Encrypt peut également tenter la validation par IPv6. Faites corriger l’adresse erronée ; ne supprimez l’entrée que si le responsable confirme que ce nom ne doit plus utiliser IPv6.
Préservez les MX et les TXT existants. Les MX dirigent les courriels, et certains TXT servent notamment à leur authentification. Même un changement de A mérite vérification si la messagerie utilise ce nom comme destination. Une réparation HTTPS ne doit pas devenir une réinitialisation de toute la zone DNS.
- Notez l’ancienne valeur, le type, le nom complet et le TTL de la ligne à corriger.
- Appliquez seulement la valeur confirmée pour cette ligne, puis relevez l’heure.
- Faites vérifier la réponse DNS effective avant de redemander un certificat.
- Contrôlez ensuite chaque variante du domaine en HTTPS.
Attendre une réponse DNS cohérente et prévoir le retour arrière
Après un changement DNS, des résolveurs peuvent encore conserver l’ancienne réponse pendant sa durée de cache. Le résultat peut donc varier selon le réseau. Le délai dépend de la configuration et des caches déjà constitués ; vider le cache des pages du site n’accélère pas leur mise à jour.
Ne multipliez pas les changements en attendant. Demandez au gestionnaire de comparer la zone faisant autorité avec les réponses observées. Si la valeur publiée reste mauvaise, patienter ne corrigera rien. Si elle est correcte mais encore inégalement vue, conservez l’heure et l’état des contrôles pour distinguer la transition d’une nouvelle panne.
Un retour à l’ancienne valeur doit être décidé avec la personne qui gère la migration : l’ancien serveur doit toujours héberger le bon site et disposer d’un certificat valable. Restaurer une valeur DNS ne restaure pas les contenus reçus depuis sur le nouveau site. Le retour arrière subit lui aussi les caches DNS ; il n’est pas instantané.
Approche 3 : vérifier séparément le CDN et le serveur d’origine
Quand un CDN reçoit les visiteurs, deux connexions peuvent être sécurisées séparément : navigateur vers CDN, puis CDN vers serveur d’origine. L’origine est le serveur où se trouve WordPress. Le certificat affiché au visiteur peut donc être celui du CDN, même si le panneau de l’hébergeur montre un certificat correct.
Dans Cloudflare, sélectionnez le domaine puis SSL/TLS et Edge Certificates, ou Certificats de périphérie. Vérifiez que le certificat public est actif et couvre le nom en défaut. Contrôlez aussi, sans le modifier au hasard, le statut du nom dans DNS : le certificat Cloudflare sert au trafic passant par son proxy, pas à un accès direct à l’origine.
Avec Universal SSL dans une zone entièrement gérée par Cloudflare, le domaine racine et les sous-domaines de premier niveau sont couverts ; un nom plus profond peut nécessiter une autre couverture. Faites confirmer la solution et son éventuel coût avant de modifier l’architecture. Ne présumez pas qu’un certificat générique protège tous les niveaux.
Si le navigateur rejoint correctement Cloudflare mais que celui-ci signale une erreur 526, faites vérifier le certificat de l’origine : nom, validité et confiance doivent correspondre à la connexion utilisée. Ne réduisez pas le niveau de validation pour masquer le défaut. Les autres échecs de négociation demandent leur propre diagnostic.
Un certificat Cloudflare Origin CA est destiné au trajet entre Cloudflare et l’origine ; les navigateurs ne lui accordent pas la même confiance publique. Désactiver le proxy pour « tester » peut donc créer une nouvelle erreur. Faites effectuer les contrôles de l’origine par le prestataire en conservant le nom demandé, sans exposer soudainement un trajet non préparé.
Sur WordPress.com, utiliser la gestion du domaine
WordPress.com fournit automatiquement le certificat des domaines hébergés sur sa plateforme. Dans le tableau de bord d’hébergement, ouvrez Domaines, sélectionnez le nom, puis Réglages et Domain security, ou Sécurité du domaine. Relevez le statut et le problème indiqué.
La préparation peut prendre jusqu’à vingt-quatre heures. Une fois la connexion du domaine et les blocages corrigés, le bouton Provision certificate permet de relancer la demande lorsqu’il est proposé. S’il manque ou si l’erreur revient, contactez le support avec le statut exact.
Pendant cette préparation, l’adresse WordPress.com peut servir d’adresse principale temporaire selon la configuration du site. Si elle redirige déjà vers le domaine en défaut, faites vérifier ce choix avant de la communiquer. Rétablissez le domaine personnalisé comme principal seulement après activation du certificat. Ne transposez pas des manipulations cPanel ni une installation de certificat privé à cette plateforme.
Vérifier les domaines d’un réseau multisite
Un réseau WordPress peut utiliser des sous-domaines ou plusieurs domaines personnalisés. Le certificat du site principal ne garantit pas celui de chaque site du réseau. Faites dresser la liste des noms publics et des adresses d’administration effectivement utilisées avec le responsable réseau.
Chaque domaine personnalisé doit être associé au bon site côté hébergement ou CDN et couvert par un certificat adapté. Un sous-site présenté dans un chemin du domaine principal ne crée pas ce même besoin. En revanche, un sous-domaine à plusieurs niveaux peut dépasser la portée d’un joker.
Contrôlez le site concerné après chaque correction et gardez quelques autres sites du réseau dans les vérifications. N’appliquez pas une modification globale des adresses WordPress pour résoudre le certificat d’un seul domaine.
Confirmer la réparation et conserver une procédure de suivi
Ouvrez chaque adresse HTTPS utilisée dans un navigateur à jour, sans exception de sécurité. Vérifiez le domaine principal, www s’il est utilisé et les anciens noms encore proposés aux visiteurs. Le certificat doit couvrir le nom initial, puis la redirection éventuelle doit aboutir au site attendu. Contrôlez une page publique et l’affichage de la connexion avant toute saisie d’identifiants.
Refaites un contrôle depuis une autre connexion connue si le défaut variait selon le réseau. Une réussite isolée ne suffit pas à expliquer un résultat intermittent. Si le panneau et le navigateur montrent encore des certificats différents, ou si certaines variantes échouent, gardez le ticket ouvert.
Transmettez au support les noms concernés, les codes exacts, les heures, les SAN et dates observés, le changement récent et le trajet avec ou sans CDN prévu. Ajoutez les résultats déjà obtenus et les valeurs DNS utiles par le canal privé du prestataire. Ne joignez ni clé privée, ni mot de passe, ni export complet de compte.
Après réparation, notez qui gère l’émission et le renouvellement, les domaines couverts et les alertes à surveiller. Avant un prochain ajout de domaine, préparez son association et son certificat avant de le diffuser. Cette vérification évite de découvrir la variante oubliée au moment où un visiteur l’utilise.
