Certificat SSL WordPress : corriger l’erreur, pas à pas

Quand WordPress affiche « Votre connexion n’est pas privée », le certificat n’est pas toujours en cause : le plus souvent, c’est une adresse, une redirection ou une horloge. La méthode la plus rapide consiste à lire le code d’erreur, à tester le certificat depuis l’extérieur, puis à vérifier les réglages du site dans cet ordre.

Voici le parcours complet, des symptômes aux correctifs, avec les commandes à copier.

Lire le code d’erreur avant de toucher à quoi que ce soit

Le navigateur affiche un code en majuscules sous le message d’alerte, par exemple NET::ERR_CERT_DATE_INVALID. C’est lui, le vrai diagnostic. Le bandeau rouge, lui, ne dit rien de précis.

Avant toute modification, faites une sauvegarde complète du site : fichiers et base de données. Notre page sur la sauvegarde 3-2-1 explique comment la tester. Un réglage d’URL ou une redirection ratée peut bloquer l’accès à l’administration.

Notez aussi trois informations : l’erreur apparaît-elle sur tous vos appareils, seulement sur mobile, ou seulement chez vous ? Un smartphone ancien est un excellent détecteur de chaîne cassée. Ces trois réponses orientent déjà vers la bonne section.

Les six codes les plus courants et ce qu’ils signifient

Deux autres messages se croisent aussi : « Connexion non sécurisée » quand le site n’est pas en HTTPS du tout, et l’absence de cadenas malgré un certificat valide, qui renvoie au contenu mixte (plus bas).

Le certificat est-il expiré ou mal renouvelé ?

C’est la panne la plus fréquente. Un certificat Let’s Encrypt, celui que la plupart des hébergeurs installent gratuitement, est valable 90 jours par défaut, et l’autorité recommande de le renouveler tous les 60 jours. Si le renouvellement automatique échoue, le site tombe en erreur de date au bout de trois mois.

Avant d’accuser le serveur, contrôlez l’horloge de votre propre ordinateur. Une date décalée de plusieurs jours suffit à faire croire au navigateur que le certificat est périmé. Côté serveur, le même défaut existe sur un VPS dont la synchronisation de l’heure est mal configurée.

Pour lire la date d’expiration depuis un poste, une seule commande suffit :

echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Elle affiche l’émetteur, le domaine protégé et la date de fin (notAfter). Si cette date est passée, le certificat est expiré et il faut le renouveler tout de suite. Sur un serveur géré avec certbot, la commande sudo certbot renew --dry-run simule un renouvellement et montre ce qui bloque.

Sur un hébergement mutualisé sans accès au serveur, ouvrez le tableau de bord de l’hébergeur et relancez l’émission du certificat gratuit depuis la rubrique SSL.

DV, OV ou EV : quel type de certificat pour WordPress ?

Les certificats se classent en trois niveaux de validation, selon ce que l’autorité vérifie avant de les émettre. Le niveau n’a aucun effet sur la solidité du chiffrement : il change la preuve d’identité apportée.

Un problème de niveau ne cause pas d’erreur dans le navigateur. Une panne vient presque toujours de la date, du nom ou de la chaîne, jamais du fait d’avoir choisi un DV.

Corriger une erreur de nom de domaine

Le code NET::ERR_CERT_COMMON_NAME_INVALID signifie que le certificat est valide, mais pour un autre nom que celui demandé. Le classique est le certificat posé sur exemple.fr alors que les visiteurs arrivent sur www.exemple.fr.

Un certificat simple couvre un seul domaine, et le www doit être prévu explicitement. Un certificat wildcard couvre tous les sous-domaines d’un même niveau, mais se valide en prouvant le contrôle du DNS. Un certificat multi-domaines liste plusieurs noms dans son champ SAN.

1. Ouvrez le certificat dans le navigateur et lisez la liste des noms couverts.
2. Choisissez la version de l’adresse que vous voulez conserver, avec ou sans www.
3. Faites réémettre le certificat pour les deux variantes si l’hébergeur le permet.
4. Posez une redirection propre de l’autre variante vers celle que vous gardez.

Un site qui répond sous plusieurs noms sur une même adresse IP repose sur le SNI : le navigateur annonce le nom demandé et le serveur présente le bon certificat. Sur un hébergement moderne, c’est automatique.

Réparer une chaîne de certificats incomplète

Un navigateur ne fait confiance qu’à des autorités racines installées d’office. Le certificat de votre site est signé par un intermédiaire, lui-même signé par cette racine. Le serveur doit donc envoyer deux certificats : le vôtre et l’intermédiaire.

Si l’intermédiaire manque, un ordinateur récent complète souvent tout seul grâce à son cache, et votre site s’ouvre. Un vieux téléphone, lui, ne le peut pas et affiche NET::ERR_CERT_AUTHORITY_INVALID. D’où le scénario piégeant : tout fonctionne chez vous, et une partie des visiteurs voit une erreur.

Une erreur visible uniquement sur smartphone pointe presque toujours vers un intermédiaire manquant, pas vers un certificat invalide. Pour inspecter la chaîne, ajoutez l’option -showcerts à la commande précédente : vous devez voir au moins deux certificats. Un test en ligne comme SSL Labs affiche aussi la chaîne et attribue une note.

Le correctif consiste à installer le fichier « fullchain » côté serveur, ou à demander à l’hébergeur de le faire. Sur un hébergement mutualisé, c’est lui qui gère ce fichier, pas vous.

Contenu mixte : le cadenas qui refuse de s’afficher

Le certificat est bon, la page se charge, mais le cadenas est barré ou absent. La page HTTPS appelle encore des ressources en HTTP : images, scripts, feuilles de style. Le navigateur les bloque ou les signale.

Ouvrez la console du navigateur avec la touche F12 : elle liste chaque ressource en HTTP. Un outil comme Why No Padlock en donne aussi la liste. Souvent, ce sont des images insérées avant le passage en HTTPS, dont l’adresse est enregistrée en dur dans la base de données.

• Les adresses saisies dans Réglages, Général, doivent commencer par https://.
• Une extension de recherche-remplacement remplace les anciennes adresses http:// par https:// dans la base. Faites une sauvegarde avant, et lancez d’abord une simulation.
• Les fichiers du thème et des extensions qui appellent une adresse http:// en dur doivent être corrigés ou remplacés.
• Videz ensuite le cache du site et celui du navigateur.

Si le contenu mixte revient après chaque correction, un thème ou une extension le réinjecte. Désactivez-les un par un pour trouver le coupable.

Boucle de redirection : HTTP, HTTPS et proxy

ERR_TOO_MANY_REDIRECTS indique une redirection qui tourne en rond. Elle apparaît souvent juste après l’activation du HTTPS, quand deux couches s’en occupent à la fois : un réglage WordPress, une règle du fichier .htaccess et un plugin, par exemple.

Le cas que les guides oublient : WordPress placé derrière un proxy inverse ou un service qui fournit le SSL, alors que lui-même tourne sans SSL. Le manuel d’administration de WordPress le décrit : forcer le HTTPS dans l’administration envoie alors les requêtes dans une boucle infinie. La parade est d’indiquer à WordPress que la connexion d’origine était sécurisée.

define( 'FORCE_SSL_ADMIN', true );
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false )
    $_SERVER['HTTPS'] = 'on';

Ces lignes s’ajoutent dans wp-config.php. Le manuel précise que ces constantes doivent être définies dans ce fichier : les poser dans un fichier d’extension ne suffit pas. Elles supposent que le proxy transmet bien l’en-tête X-Forwarded-Proto. Sans cela, la boucle persiste.

Pour le reste, gardez une seule source de redirection. Si l’hébergeur propose un bouton « forcer le HTTPS », laissez-le agir et retirez les règles équivalentes de .htaccess ainsi que l’option correspondante d’une extension. Deux mécanismes qui se renvoient la requête sont la recette classique de la boucle.

En cas de blocage total de l’accès, renommez temporairement le dossier des extensions par FTP pour les désactiver toutes, puis corrigez les adresses.

Les réglages WordPress à vérifier

Dans Réglages, Général, deux champs comptent : l’adresse de WordPress et l’adresse du site. Les deux doivent utiliser le même schéma, https://, et le même choix avec ou sans www que votre certificat.

La constante FORCE_SSL_ADMIN force les connexions et toutes les sessions d’administration à passer par SSL. Elle suppose que le SSL est déjà configuré sur le serveur : sinon, vous vous coupez de votre propre tableau de bord.

Côté protocole, la règle de base est de désactiver TLS 1.0 et 1.1, de garder TLS 1.2 et d’activer TLS 1.3. TLS 1.3 n’autorise qu’un petit nombre de suites de chiffrement, ce qui limite les mauvais réglages. Si vous ne gérez pas le serveur, demandez-le à l’hébergeur.

Selon l’hébergement : qui répare quoi ?

Votre marge d’action dépend de l’endroit où le site tourne. Mieux vaut le savoir avant de perdre une heure à chercher un fichier qui n’est pas à vous.

Quand vous écrivez au support, joignez le code d’erreur exact, l’heure de la première apparition et le résultat de la commande openssl. Le dossier avance bien plus vite avec ces trois éléments.

Que faire si le certificat est bon et que l’erreur persiste ?

Procédez par élimination, du plus simple au plus technique.

1. Testez depuis un autre navigateur, un autre appareil et un autre réseau : si l’erreur disparaît, elle est locale (horloge, cache, antivirus qui inspecte le trafic).
2. Videz le cache du site, du CDN s’il y en a un, et du navigateur.
3. Désactivez les extensions de cache et de sécurité, puis réactivez-les une à une.
4. Relisez la chaîne et les domaines couverts avec openssl ou un test en ligne.
5. Si l’erreur est apparue sans changement de votre part, vérifiez que le site n’est pas compromis : notre guide sur le site WordPress piraté détaille les contrôles.

Un site peut aussi être injecté pour rediriger vers des pages au certificat douteux. Dans ce cas, le certificat n’est qu’un symptôme.

Si le navigateur affiche au contraire une page blanche ou un message d’indisponibilité, ce n’est plus le certificat : l’erreur 500 côté serveur suit une autre démarche.

Pour votre connexion à l’administration, activez aussi la double authentification par application, et protégez le compte par un mot de passe solide.

Quatre outils pour tester sans rien installer

Quatre services gratuits couvrent l’essentiel du diagnostic. Ils se complètent plus qu’ils ne se remplacent.

Si crt.sh montre un certificat que vous n’avez jamais demandé, ne le traitez pas comme une simple curiosité technique. Vérifiez les accès à votre domaine et à votre hébergement, et changez les mots de passe concernés.

Éviter la prochaine panne : renouvellement et alerte

Un certificat SSL est devenu une routine, pas un coût : il suffit d’un certificat Let’s Encrypt, d’un renouvellement automatique et d’une alerte qui prévient si le renouvellement échoue. Trois gestes évitent la plupart des pannes.

• Laissez l’hébergeur ou certbot renouveler seul, et vérifiez la date de fin une fois par trimestre.
• Posez une alerte de supervision qui prévient une à deux semaines avant l’expiration.
• Après tout changement d’hébergeur, de CDN ou de domaine, refaites le test de chaîne et de domaine.

Pensez enfin à noter, quelque part hors du site, la date de fin du certificat, le nom de l’hébergeur et la personne qui peut intervenir. Le jour de la panne, cette fiche de quelques lignes évite de chercher des identifiants dans la précipitation.

Pour une boutique, le cadenas ne garantit pas que le vendeur soit honnête : notre page sur le paiement sécurisé en ligne explique ce qu’un certificat prouve, et ce qu’il ne prouve pas. À ne pas confondre non plus avec le VPN SSL, qui est un autre usage du protocole.

Questions fréquentes

Ouvrez votre site maintenant, relevez le code d’erreur s’il y en a un, et lancez la commande openssl sur votre domaine pour noter la date de fin du certificat. Réglez ensuite une alerte vingt jours avant cette date. Si tout est vert, testez une fois sur un téléphone ancien pour vérifier la chaîne.

Yann Deverre

Douze ans de développement web, en agence puis chez un éditeur de logiciels, avant de passer à l'écriture. Il explique le numérique en partant du mécanisme, et teste avant d'affirmer.