Erreur SSL sur WordPress : certificat, HTTPS et contenu mixte

Une alerte SSL sur WordPress peut venir du certificat, de la connexion HTTPS ou d’une ressource encore appelée en HTTP. Le message exact et le moment où il apparaît permettent de choisir le bon diagnostic. Avant de changer un réglage, conservez l’adresse concernée et les éléments visibles, sans transmettre d’identifiant ni de jeton.

Identifier le moment où la connexion échoue

• Le navigateur bloque avant d’afficher la page : relevez le code d’erreur et faites examiner le certificat ou la connexion sécurisée.
• La page s’ouvre, mais certains éléments manquent : recherchez notamment une alerte de contenu mixte dans la console du navigateur.
• La page redirige en boucle : vérifiez la cohérence des adresses et des règles HTTPS plutôt que de conclure immédiatement à un certificat expiré.

Comparez aussi avec un autre navigateur ou un autre appareil, sans contourner l’alerte. Une date incorrecte sur un appareil, un réseau particulier ou un logiciel intermédiaire peuvent demander un diagnostic local. Si plusieurs sites sont concernés sur un seul poste, ce constat doit être transmis au responsable de ce poste avant de modifier le serveur du site.

Vérifier le nom couvert, les dates et la chaîne du certificat

Le certificat présenté doit correspondre au nom demandé et être reconnu par le navigateur. Le responsable doit contrôler sa période de validité et les certificats intermédiaires nécessaires à la chaîne de confiance. Un renouvellement réussi dans un panneau d’hébergement ne suffit pas : il faut vérifier le certificat effectivement présenté au visiteur.

Le domaine avec www et celui sans www doivent être examinés selon les adresses réellement utilisées. Un hôte HTTPS qui redirige doit lui aussi établir sa connexion correctement. Une redirection ne rend pas valide un certificat présenté pour un autre nom.

Faites corriger le certificat ou sa chaîne depuis le service qui termine la connexion. N’ajoutez pas d’exception permanente dans les navigateurs des visiteurs et n’installez pas un certificat racine reçu d’une source non vérifiée. Tant que l’alerte de sécurité reste inexpliquée, ne poursuivez pas une connexion, un paiement ou un formulaire contenant des données privées.

Repérer les ressources en contenu mixte

Une page HTTPS qui demande une image, une police, une feuille de style ou un script en HTTP peut produire du contenu mixte. Le navigateur peut bloquer des ressources ; l’affichage ou une fonction du site peut alors sembler cassé malgré un certificat principal valide.

Dans les outils de développement, relevez les requêtes signalées et leur origine : contenu d’une page, style du thème, réglage d’extension ou service tiers. Corrigez l’URL à sa source et vérifiez que la ressource existe réellement en HTTPS. Un simple remplacement de texte ne crée pas une version sécurisée d’un service qui ne la propose pas.

Si une correction doit toucher des données WordPress, préparez-la sur une copie de test avec sauvegarde et outil adapté aux données sérialisées. Évitez un remplacement SQL global improvisé. Gardez les paramètres privés des URL hors des captures et tickets partagés.

Aligner WordPress, le proxy et les redirections

Quand un CDN ou un proxy intervient, le responsable doit distinguer la connexion du visiteur et celle qui rejoint le serveur d’origine. Leur configuration doit être cohérente, avec une vérification adaptée des certificats et une transmission fiable du protocole utilisé. Un réglage qui masque la validation ne répare pas l’origine du refus.

Contrôlez les adresses WordPress et les règles de redirection dans les couches qui les gèrent. Une règle serveur, une extension et le proxy peuvent se renvoyer mutuellement vers des adresses différentes. Le guide des boucles de redirection WordPress détaille cette branche du diagnostic.

Ne modifiez pas plusieurs couches à la fois. Conservez les réglages précédents et une sauvegarde restaurable ; prévoyez un accès de secours adapté avant un changement qui peut bloquer l’administration. La configuration exacte dépend de l’hébergement, pas d’un extrait de code universel à ajouter.

Valider les parcours avant de renforcer la politique HTTPS

Reprenez les adresses et pages concernées depuis un navigateur, puis contrôlez la connexion, les médias et les formulaires utiles. Les tests de paiement ou de création de données doivent rester dans un environnement prévu pour cela. Vérifiez que les ressources se chargent, que les redirections aboutissent et que les nouveaux messages de console ou de serveur ne reproduisent pas l’erreur.

HSTS demande aux navigateurs de conserver l’usage de HTTPS. Son activation, notamment avec les sous-domaines, exige de vérifier le périmètre concerné et la continuité du service sécurisé. Ce réglage peut rendre une erreur de certificat plus bloquante ; il doit suivre une validation complète, avec une procédure de déploiement adaptée.

Si l’accès reste bloqué, le parcours d’intervention sur un site en panne permet de décrire le domaine, le message et les adresses affectées. Il n’est pas nécessaire de joindre un mot de passe ou une clé privée pour présenter le problème.

Références officielles

• Mozilla : comprendre les codes d’alerte de sécurité
• MDN : identifier le contenu mixte
• WordPress : préparer une configuration HTTPS
• MDN : portée et fonctionnement de HSTS