Pour résoudre un problème de certificat SSL WordPress, commencez par relever le message exact du navigateur et l’adresse concernée. Un certificat expiré, un domaine mal couvert et une page HTTPS qui charge encore des fichiers en HTTP ne se corrigent pas de la même manière. Vérifiez d’abord la connexion, puis la configuration du site.
Votre premier repère
Ne forcez pas l’accès à travers une alerte pour saisir un mot de passe ou effectuer un paiement. Si votre site est devenu inaccessible et que vous manquez des accès techniques, demandez un dépannage du site internet plutôt que de modifier plusieurs réglages au hasard.
Quel problème SSL rencontrez-vous ?
On parle couramment de « SSL », même si les connexions modernes utilisent TLS. Le certificat participe à la vérification de l’identité du serveur ; il ne prouve pas, à lui seul, que tout le site est sain. Relevez le code affiché, pas seulement « mon site n’est pas sécurisé ».
| Message ou symptôme | Piste à vérifier | Premier contrôle |
|---|---|---|
NET::ERR_CERT_DATE_INVALID |
Dates du certificat ou horloge de l’appareil | Comparer la période de validité et la date de l’appareil. |
NET::ERR_CERT_COMMON_NAME_INVALID |
Nom demandé non couvert par le certificat | Vérifier le domaine exact, avec ou sans www, et le sous-domaine. |
NET::ERR_CERT_AUTHORITY_INVALID |
Confiance dans l’émetteur ou chaîne de certificats | Faire vérifier l’installation côté hébergement. |
ERR_SSL_PROTOCOL_ERROR |
Échec de la négociation de connexion | Comparer les appareils, puis la configuration TLS du serveur ou du CDN. |
Avertissement Mixed Content dans la console |
Ressources appelées en HTTP sur une page HTTPS | Identifier les fichiers concernés avant de changer leurs URL. |
ERR_TOO_MANY_REDIRECTS |
Règles de redirection incompatibles | Examiner le parcours entre WordPress, l’hébergement et le CDN éventuel. |
Sur mobile, faites défiler le tableau horizontalement pour lire les trois colonnes.
Ces pistes ne constituent pas un diagnostic automatique. Les libellés varient selon le navigateur ; DigiCert détaille les erreurs de certificat courantes. Si vous voyez plutôt un avertissement rouge « Site dangereux », consultez le guide site WordPress piraté : renouveler un certificat ne nettoie pas une infection.
Que vérifier avant de modifier WordPress ?
Délimitez le problème sans changer l’état du site. Une erreur limitée à un ordinateur et une alerte visible pour tous n’appellent pas le même premier intervenant.
- L’adresse exacte : domaine principal, variante www, sous-domaine ou adresse d’administration.
- La portée : accueil et page intérieure, autre navigateur, téléphone et autre réseau si possible.
- Le moment : première apparition et changement récent d’hébergement, DNS, CDN ou réglages HTTPS.
- Les accès utiles : hébergement et service qui gère le certificat, pas seulement le compte WordPress.
Conservez le message et les observations pour l’hébergeur, sans transmettre de mot de passe ni de clé privée. Avant toute correction de configuration ou de base de données, préparez une sauvegarde récupérable du site et un retour arrière adapté. Cette sauvegarde ne remplace pas celle des réglages du serveur ou du CDN.
Vous déléguez ces contrôles ? Votre maintenance WordPress doit préciser qui suit le certificat et qui intervient auprès de l’hébergeur.
Ne désactivez pas les protections du navigateur. Faire disparaître l’avertissement sur votre ordinateur ne corrige pas le certificat présenté aux visiteurs.
Certificat expiré ou invalide : où intervenir ?
Le certificat est servi par l’infrastructure qui reçoit la connexion HTTPS. Il peut dépendre de l’hébergement ou d’un CDN placé devant lui. La première vérification se fait donc à cet endroit, pas en réinstallant WordPress.
Lire les informations utiles
- Noms couverts
example.com·www.example.comComparer avec l’adresse réellement ouverte.- Période de validité
- Une date de début et une date de finLa date actuelle doit se situer dans cette période.
- Émetteur et chaîne
- Une chaîne de confiance reconnueUn nom et des dates corrects ne suffisent pas à tout valider.
Le parcours de contrôle
- Dans les informations de connexion du navigateur, consultez le certificat si cette fonction est disponible sans contourner l’alerte. Sinon, utilisez les informations de l’hébergeur.
- Vérifiez les noms couverts et les dates. Si l’erreur concerne les dates sur un seul appareil, contrôlez aussi son horloge.
- Dans l’hébergement ou le CDN concerné, examinez le certificat installé et actif, son renouvellement et les éventuels échecs de validation.
- Après correction, rechargez l’adresse publique : un certificat généré dans le panneau n’est pas nécessairement celui présenté au visiteur.
Un domaine qui pointe vers un ancien serveur peut encore recevoir l’ancien certificat. Une variante www ou un sous-domaine oublié peut aussi échouer alors que l’adresse principale fonctionne. Demandez à l’hébergeur de vérifier le serveur réellement joint, la couverture du nom et la chaîne complète plutôt que de renouveler plusieurs fois sans comprendre.
Pour une installation auto-hébergée, la documentation HTTPS de WordPress rappelle notamment que le SSL doit déjà être configuré côté serveur avant de forcer l’administration en HTTPS.
Le certificat est valide, mais le HTTPS fonctionne mal ?
Si la connexion est acceptée, poursuivez côté application. Une page qui s’ouvre ne garantit pas que tous ses fichiers se chargent correctement. Séparez le contrôle des ressources de celui des redirections.
Identifier les ressources encore appelées en HTTP
Ouvrez les outils de développement du navigateur, puis la Console et l’onglet Réseau / Network. Rechargez une page touchée et repérez les avertissements de contenu mixte. Selon le type de ressource, le navigateur peut tenter le HTTPS automatiquement ou bloquer la requête.
Dans la console : les trois repères à lire
Faites glisser la capture horizontalement pour lire le message.
- Console : l’onglet où apparaît l’avertissement.
- L’adresse HTTP : la ressource à retrouver dans le site.
- Le comportement : ici, Firefox tente le HTTPS pour l’image. Un script non sécurisé peut être bloqué.
La documentation MDN sur le contenu mixte explique ces comportements. Pour une ressource externe sans version HTTPS, cherchez une alternative sûre plutôt que d’autoriser du contenu non sécurisé.
Dans WordPress, vérifiez les URL sous Réglages → Général, sans les modifier à l’aveugle : certaines installations les définissent ailleurs. Un remplacement en base demande un outil compatible avec les données sérialisées, une sauvegarde et un contrôle préalable. Ne lancez pas un remplacement global sur toute la base pour corriger une seule référence.
Comprendre les boucles de redirection
Le parcours à examiner
Les règles doivent conduire vers la même adresse finale, sans renvoi contradictoire.
Par exemple, un serveur peut renvoyer le HTTP vers HTTPS alors qu’un intermédiaire lui transmet toujours la requête en HTTP. La documentation Cloudflare sur les boucles décrit ce cas avec le mode Flexible. Ce n’est pas une raison pour changer de mode au hasard : le certificat et la configuration à l’origine doivent être compatibles.
- Relevez les redirections : dans Réseau, examinez la requête principale et les adresses successives.
- Repérez qui les produit : serveur, CDN, extension ou WordPress.
- Corrigez la contradiction identifiée : conservez la configuration précédente pour pouvoir revenir en arrière.
Évitez d’empiler une extension HTTPS, une nouvelle règle serveur et une redirection CDN en même temps. Une purge de cache vient après la correction à la source si une ancienne copie persiste ; le guide vider le cache WordPress aide à choisir la bonne couche.
Comment vérifier que le problème est corrigé ?
Repartez de l’adresse et du symptôme relevés au début. Testez sans votre session administrateur, puis sur un autre appareil. Ne validez pas la réparation sur le seul écran de réglage de l’hébergeur.
Trois niveaux de validation
- 01La connexionCertificat accepté pour le bon nom, sur les adresses utiles
- 02La pageRessources chargées et redirections sans boucle
- 03Le parcoursConnexion et contact testés, selon les fonctions du site
La liste de contrôle après intervention
- Ouvrir l’accueil, une page intérieure et les variantes de domaine utilisées.
- Contrôler l’administration, les images, les scripts et les formulaires.
- Vérifier la destination finale des anciennes URL HTTP, si leur redirection est attendue.
- Envoyer un message de test identifié et vérifier sa réception ; ne pas déclencher de paiement réel involontaire.
- Noter la cause confirmée, la correction et les contrôles effectués.
Si le formulaire confirme l’envoi mais que rien n’arrive, poursuivez avec WordPress n’envoie pas de mail. Ce nouveau constat ne signifie pas que le certificat est à nouveau défectueux.
Comment éviter une nouvelle interruption SSL ?
Un renouvellement automatique peut échouer. Organisez à la fois son fonctionnement et la manière de détecter un problème. L’important n’est pas seulement qu’une alerte existe, mais qu’une personne la reçoive et sache quoi faire.
- Identifier le responsable : hébergeur, prestataire ou entreprise, avec des accès encore valides.
- Contrôler le renouvellement : état réel, erreurs éventuelles et noms de domaine couverts.
- Prévoir une alerte suivie : surveillance du certificat présenté au public et destinataire disponible.
- Recontrôler après un changement : hébergement, DNS, CDN ou ajout de sous-domaine.
Ne comptez pas sur un email de Let’s Encrypt pour vous prévenir : son service de rappel d’expiration a été arrêté. Vérifiez les alertes réellement proposées par votre hébergeur ou votre outil de suivi.
Le suivi doit préciser qui surveille, qui intervient et ce qui reste à la charge de l’hébergeur. Pour un état des lieux plus large, l’audit de sécurité WordPress couvre aussi les accès, les sauvegardes et les composants du site, sans se limiter au HTTPS.
Questions fréquentes sur les certificats SSL WordPress
Un certificat gratuit suffit-il ?
Un certificat gratuit reconnu par les navigateurs peut convenir à un site WordPress. Vérifiez surtout les noms couverts, son installation et son renouvellement. Le prix ne corrige pas une mauvaise configuration et ne garantit pas la sécurité complète du site.
Une extension peut-elle tout réparer ?
Non. Elle peut aider sur certaines URL ou redirections, selon ses fonctions. Elle ne remplace pas la correction d’un certificat invalide présenté avant le chargement de WordPress. Vérifiez ce que gère déjà votre hébergement avant d’ajouter un outil.
Pourquoi l’alerte reste-t-elle après le renouvellement ?
Le navigateur peut encore joindre un autre serveur, une variante de domaine ou le CDN. Comparez le certificat réellement présenté avec celui installé. Si le problème touche un seul appareil, vérifiez aussi sa date et son environnement, sans désactiver ses protections.
Un problème SSL signifie-t-il que le site est piraté ?
Pas à lui seul. Une expiration ou une configuration incorrecte peut suffire à provoquer l’alerte. Inversement, un certificat valide ne prouve pas l’absence d’infection. Traitez les autres symptômes éventuels séparément.
Corriger l’erreur, puis organiser le suivi
Vous ne savez pas si le blocage vient du certificat, du serveur ou de WordPress ? Présentez-moi le message et l’adresse concernés, sans transmettre d’identifiants dans le formulaire. Nous pourrons définir les vérifications nécessaires, puis le suivi utile pour votre site, sans remplacer ce qui fonctionne déjà.
