Le navigateur n'affiche plus votre site. À la place, un écran d'avertissement, une phrase qui parle de connexion non privée, et un bouton qui ne mène nulle part. Vos visiteurs voient exactement la même chose. Les formulaires de paiement, les applications et les services qui appellent votre site en arrière-plan refusent la connexion eux aussi, sans avertissement et sans bouton pour passer outre.
La cause tient le plus souvent en une phrase : le certificat a expiré parce que son renouvellement automatique s'est arrêté il y a plusieurs semaines, et rien ne l'a signalé. Ce guide explique ce qui l'arrête, comment le vérifier chez vous en une requête, et comment relancer la machine selon les accès dont vous disposez.
Ce que vous voyez, et ce que ça désigne
Trois avertissements ressemblants recouvrent trois pannes différentes. C'est la première raison pour laquelle on passe une demi-heure dans la mauvaise section.
Le certificat a expiré. Chrome affiche « Votre connexion n'est pas privée », et sous le bouton Paramètres avancés, le code NET::ERR_CERT_DATE_INVALID. Firefox parle d'échec de la connexion sécurisée, Safari d'une connexion impossible à établir. C'est le sujet de ce guide.
Le certificat est valide mais ne couvre pas l'adresse demandée. Écran très voisin, code différent : NET::ERR_CERT_COMMON_NAME_INVALID. Le cas classique est le certificat émis pour ledomaine.fr sans www.ledomaine.fr, ou l'inverse. Une visite sur deux passe, l'autre non. Traité plus bas.
Le cadenas est barré, mais le site s'affiche normalement. Ici, le certificat est bon. Ce qui gêne le navigateur, ce sont des images, des scripts ou des feuilles de style encore appelés en http dans une page servie en https. Rien de ce guide ne s'applique à votre cas, la réparation se trouve dans le guide du site WordPress affiché comme non sécurisé.
Un mot sur ERR_SSL_PROTOCOL_ERROR, beaucoup recherché et très ambigu. Il apparaît sur un certificat mort, mais aussi quand le navigateur et le serveur ne s'accordent sur aucune version de TLS, et surtout sur les environnements de développement locaux. Si l'adresse en cause est localhost ou se termine par .local, vous n'êtes pas sur la bonne panne.
En trente secondes
1. Vérifiez depuis un autre appareil et un autre réseau. Votre téléphone en données mobiles, wifi coupé, suffit. Si le site s'affiche là et pas au bureau, le problème n'est pas votre certificat : c'est le réseau depuis lequel vous regardez. Les réseaux d'entreprise qui inspectent le trafic chiffré déclenchent exactement le même avertissement, et une extension de navigateur y arrive aussi. Un fil de forum long de trente-trois réponses s'est terminé sur ce diagnostic, après qu'un support d'hébergeur eut proposé à la demandeuse un abonnement de sécurité dont elle n'avait aucun besoin.
2. Lisez la date d'expiration avant de conclure. Depuis un terminal :
openssl s_client -connect votre-domaine.fr:443 \
-servername votre-domaine.fr </dev/null 2>/dev/null \
| openssl x509 -noout -dates
Deux lignes s'affichent, notBefore et notAfter. La seconde est la date de fin. Sans terminal, cliquez sur l'icône à gauche de l'adresse, puis sur les détails du certificat : le navigateur affiche la même information. Tant que vous n'avez pas lu cette date, vous ne savez pas si votre certificat est vraiment expiré.
3. Un certificat expiré n'est pas un piratage. Le message de Chrome parle d'intercepteurs et de vol d'informations, ce qui affole beaucoup de propriétaires. Il décrit un risque théorique, pas un événement. Personne n'est entré chez vous. Et ne reculez pas l'horloge de votre ordinateur pour retrouver l'accès à votre administration : cette manipulation, racontée telle quelle sur un forum officiel, ne répare strictement rien, vos visiteurs continuent de voir l'avertissement, et elle fait perdre des jours.
Pourquoi le renouvellement s'est arrêté alors que vous n'avez rien fait
Un certificat Let's Encrypt vit quatre-vingt-dix jours. Il se renouvelle tout seul, et il le fait très bien, jusqu'au jour où quelque chose l'en empêche. Ce quelque chose est souvent en place depuis des années.
Pour délivrer un certificat, l'autorité vérifie d'abord que vous contrôlez le domaine. Elle demande un fichier déposé par votre serveur sous /.well-known/acme-challenge/, et elle le demande en clair, sur le port 80. Pas en https. Si cette requête ne reçoit pas le fichier, la validation échoue et le renouvellement n'a pas lieu. Rien ne casse ce jour-là : le certificat en place fonctionne encore pendant des semaines. Le site tombe bien plus tard, un matin, sans que personne n'ait touché à quoi que ce soit. C'est ce décalage qui rend la panne incompréhensible.
Nous avons mesuré les trois configurations sur notre banc d'essai, avec un fichier de test déposé au bon endroit.
Ce que contient le .htaccess |
Réponse sur le chemin de validation |
|---|---|
| aucune redirection | 200, le jeton est rendu |
| redirection https sans exclusion | 301 vers https, le jeton n'est jamais rendu |
| redirection https avec exclusion du chemin | 200, et le reste du site redirige bien |
La ligne du milieu est celle qui nous occupe, parce que c'est le bloc que le web entier recopie depuis dix ans :
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Il fait exactement ce qu'on lui demande. Il force le https sur tout le site, il fonctionne parfaitement le jour où on le pose, et il casse le renouvellement suivant, trois mois plus tard. Une vidéo de 2017 qui le diffuse compte aujourd'hui plus de vingt mille vues, et le bloc y est donné sans la ligne qui manque.
Cette ligne, la voici, à placer avant la condition sur HTTPS :
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Vérifié au banc d'essai : avec cette ligne, le chemin de validation répond 200 et une page normale du site redirige toujours vers https. Les deux comportements coexistent, il n'y a rien à sacrifier.
Comment le tester chez vous, sans rien casser. Créez à la racine du site un dossier .well-known, un sous-dossier acme-challenge, et déposez-y un fichier test.txt contenant un mot quelconque. Le point du premier dossier compte, et beaucoup de clients FTP masquent les dossiers qui commencent par un point : activez l'affichage des fichiers cachés. Appelez ensuite l'adresse en http, pas en https :
curl -I http://votre-domaine.fr/.well-known/acme-challenge/test.txt
Un 200 signifie que le chemin est libre et que la cause est ailleurs. Un 301 ou un 302 signifie qu'une redirection intercepte la validation, et vous venez de trouver votre panne. Un 404 mérite la section suivante. Pensez à retirer le fichier de test ensuite.
Le 404 d'Apache et celui de WordPress ne disent pas la même chose
Quand le jeton n'est pas là, deux acteurs peuvent répondre 404, et ce sont deux pannes différentes. Les en-têtes de la réponse les séparent proprement, ce que personne ne dit nulle part.
| Qui a répondu | Ce qu'on lit dans les en-têtes |
|---|---|
| Apache | Content-Type: text/html; charset=iso-8859-1 |
| WordPress | Expires: Wed, 11 Jan 1984 05:00:00 GMT et Cache-Control: no-store, private |
Ajoutez -i ou -I à votre commande curl pour les voir, ou ouvrez l'onglet Réseau des outils de développement du navigateur et cliquez sur la requête.
Un 404 d'Apache veut dire que le fichier n'a pas été écrit. Le serveur a bien regardé dans le bon dossier, il n'y a rien trouvé. L'outil de renouvellement n'a pas tourné, ou il n'a pas le droit d'écrire à cet endroit.
Un 404 de WordPress veut dire tout autre chose. La requête a traversé la réécriture d'URL au lieu d'être servie comme un simple fichier, ce qui signifie que le dossier où l'outil de renouvellement écrit n'est pas celui que le serveur publie. Avec un accès SSH, le chemin attendu se lit dans /etc/letsencrypt/renewal/votre-domaine.fr.conf, à la ligne webroot_path. Sans SSH, c'est la question exacte à poser à votre hébergeur, et elle vaut mieux qu'un « mon site ne marche plus ».
Et si la réponse n'est ni un 200 ni un 404 mais une redirection, cherchez dans les en-têtes une ligne X-Redirect-By. Quand elle porte la valeur WordPress, la redirection ne vient pas de votre .htaccess mais du cœur de WordPress lui-même, à partir de l'adresse enregistrée en base, et vider le .htaccess ne changera rien. La communauté anglophone documente ce cas, avec un demandeur qui avait supprimé son .htaccess avant de comprendre. Notre banc d'essai ne l'a pas reproduit : sans .htaccess, la requête a répondu 200 quand le jeton existait et 404 quand il manquait, jamais 301. Nous ne l'affirmons donc pas, mais l'en-tête est là pour trancher chez vous.
Trois autres coupables, documentés ailleurs, vérifiables chez vous
Un enregistrement AAAA qui ne répond pas. Quand un domaine porte un enregistrement AAAA, la validation tente l'IPv6 en premier. Si le port 80 n'est pas joignable par ce chemin, elle échoue, alors que le site s'affiche parfaitement en IPv4. Deux fils indépendants, l'un sur la communauté Let's Encrypt en français, l'autre sur le forum de Plesk, se concluent par la même chose : le retrait de l'enregistrement AAAA a débloqué le renouvellement. Testez avec curl -6 -I http://votre-domaine.fr/, ou passez le domaine dans letsdebug.net, qui est fait pour ça et que le corpus professionnel ne cite jamais.
Le nuage Cloudflare en orange. Quand le proxy est actif, c'est Cloudflare qui reçoit la requête de validation, pas votre serveur. Selon ce que Cloudflare a en cache et selon la façon dont il traite le port 80, le jeton peut ne jamais atteindre l'origine. La présence du proxy se lit dans les en-têtes de n'importe quelle réponse du site, aux lignes commençant par cf-.
Le mode Full (Strict) sur un certificat déjà expiré. Celui-là est une boucle qui se referme sur elle-même. Cloudflare, dans ce mode, vérifie le certificat de votre serveur d'origine avant de lui parler. Si ce certificat est expiré, il refuse la connexion, donc la requête de validation n'atteint jamais l'origine, donc le renouvellement ne peut pas aboutir, donc le certificat reste expiré. Un fil de la communauté Let's Encrypt de novembre 2024 en sort en basculant temporairement en mode Full, le temps du renouvellement, avant de revenir en Full (Strict).
Relancer le renouvellement, selon ce à quoi vous avez accès
Une règle vaut avant tout le reste, et elle règle la moitié des malentendus : le certificat se renouvelle là où il a été installé. Installé par Plesk, il se renouvelle par Plesk. Posé par l'AutoSSL de cPanel, il se renouvelle par cPanel. Obtenu en ligne de commande avec Certbot, il se renouvelle par Certbot. WordPress n'a rien à voir dans l'affaire, et aucune extension ne fabrique de certificat, quoi qu'en dise son nom.
Avec un panneau d'hébergement, sans terminal
Le bouton se trouve dans la section SSL ou TLS de votre panneau, ou dans l'espace client pour les hébergeurs qui gèrent le certificat au niveau du compte. Chez les mutualisés à base de cPanel, la fonction s'appelle AutoSSL.
Libérez le chemin de validation avant de cliquer, sinon le bouton échouera à nouveau, et très souvent sans message. C'est le scénario documenté sur un forum d'hébergeur francophone : le demandeur relance l'AutoSSL en boucle sur un bouton qui ne fait rien, sans jamais savoir pourquoi.
Deux chemins de validation supplémentaires méritent d'être exclus de votre redirection si votre hébergeur les utilise, /.well-known/cpanel-dcv/ pour l'AutoSSL de cPanel et /.well-known/pki-validation/ pour les certificats commerciaux. La construction est la même que celle donnée plus haut, une condition par chemin.
Avec un accès SSH
Commencez toujours par l'essai à blanc :
certbot renew --dry-run
Cette précaution n'est pas de la coquetterie. Let's Encrypt limite le nombre de demandes par domaine et par semaine, et quelqu'un qui relance en boucle pendant une panne se retrouve bloqué plusieurs jours, au pire moment. L'essai à blanc ne consomme pas ce quota et il reproduit exactement la validation.
Quand l'essai passe, lancez le vrai renouvellement, puis rechargez le serveur web. Ce dernier point est le piège de la section : un certificat renouvelé mais non rechargé reste invisible, le serveur continue de servir l'ancien, et le site reste en panne alors que le nouveau certificat existe déjà sur le disque.
certbot renew --post-hook "systemctl reload apache2"
Pour que le rechargement se fasse à chaque renouvellement futur, la forme durable est une ligne renew_hook dans le fichier de configuration du domaine, sous /etc/letsencrypt/renewal/. Vérifiez aussi ce qui déclenche le renouvellement : sur un système récent, ce n'est plus une tâche cron mais un minuteur, que systemctl list-timers affiche. Une tâche cron ajoutée à la main sur un tel système ne sert à rien, et la plupart des tutoriels vidéo ne le disent pas.
Vérifier que c'est vraiment reparti
Relancez la commande openssl de la section « En trente secondes ». La date notAfter doit avoir bougé. Si elle n'a pas bougé alors que le renouvellement s'est déclaré réussi, le serveur sert encore l'ancien fichier, et c'est le rechargement qui manque.
Cloudflare, ses trois modes, et ce que chacun provoque
| Mode | Ce que fait Cloudflare | Le symptôme quand ça tourne mal |
|---|---|---|
| Flexible | chiffre avec le visiteur, appelle votre serveur en clair | boucle de redirection sans fin |
| Full | chiffre aussi jusqu'à votre serveur, sans vérifier son certificat | un certificat d'origine expiré passe inaperçu pendant des mois |
| Full (Strict) | vérifie en plus le certificat de votre serveur | erreur 526 chez le visiteur, et la boucle décrite plus haut |
Le mode Flexible produit la panne la plus déroutante : votre serveur redirige vers https, Cloudflare redemande la page en clair, et le trafic tourne en rond jusqu'à ERR_TOO_MANY_REDIRECTS. Le certificat n'y est pour rien. Cette panne a son propre traitement, dans le guide de l'administration WordPress inaccessible, qui donne le bloc à poser dans wp-config.php.
Un avertissement, tiré des commentaires laissés sous une vidéo qui compte près de soixante-dix mille vues : le remède le plus montré consiste à faire redescendre le mode SSL jusqu'à ce que le message d'erreur disparaisse. Il disparaît, en effet. Le chiffrement entre Cloudflare et votre serveur disparaît avec lui, et la boucle de redirection arrive dans la foulée. Sous cette vidéo, un spectateur demande s'il doit laisser le réglage en Flexible ou revenir en Full (Strict), et personne ne lui répond.
Les fausses pistes qui coûtent le plus cher
Passer l'adresse du site en https dans Réglages puis Général alors que https ne répond pas encore. La vidéo la plus vue de tout le sujet, près d'un demi-million de vues, montre ce geste en trois minutes. Sous elle, onze commentaires distincts de propriétaires enfermés hors de leur propre administration. Le mécanisme est simple : WordPress redirige alors tout vers https, et https ne répond pas. Il n'y a plus de porte d'entrée. Vérifiez d'abord que https://votre-domaine.fr charge, et gardez la sortie de secours sous la main, deux constantes à écrire dans wp-config.php :
define( 'WP_HOME', 'http://votre-domaine.fr' );
define( 'WP_SITEURL', 'http://votre-domaine.fr' );
Elles prennent le pas sur la base de données et grisent les deux champs dans l'administration. Retirez-les une fois le certificat valide et l'adresse corrigée.
Modifier siteurl et home directement dans phpMyAdmin. Un fil d'hébergeur francophone se conclut par une perte d'accès complète au site après cette manipulation, et par le rappel d'un habitué : ce n'était pas nécessaire. Passez par les constantes ci-dessus, elles se retirent en deux clics.
Croire qu'une extension SSL fournit le certificat. Cette confusion revient dans quatre fils sur les vingt-deux que nous avons lus. Les extensions de ce type forcent le https dans WordPress et corrigent des URL, ce qui est utile, mais le certificat lui-même est installé sur le serveur. Une extension qui annonce « certificat déjà généré » alors que l'hébergeur en sert un expiré ne ment pas, elle se trompe d'endroit : dans un cas documenté, le site était servi depuis un lien symbolique et l'extension déposait ses fichiers dans un dossier qui n'était pas la vraie racine.
Confondre le certificat que le site sert et celui que WordPress utilise. Si le message cURL error 60: SSL certificate problem: certificate has expired apparaît au moment de mettre à jour une extension, alors que votre site s'affiche avec son cadenas, il ne s'agit pas du tout du même certificat. WordPress embarque sa propre liste d'autorités pour ses requêtes sortantes, dans wp-includes/certificates/ca-bundle.crt, et une installation restée sur une vieille version traîne une liste périmée. La réparation documentée est la mise à jour de WordPress. Sur un serveur ancien, le même message peut aussi venir du magasin de certificats du système, ce qui est une autre réparation, côté serveur.
L'adresse technique de l'hébergeur restée enregistrée comme adresse du site. Cas classique des installations en un clic sur mutualisé : WordPress a mémorisé une adresse du type xxxxxxx.cluster0xx.hosting.ovh.net au lieu de votre nom de domaine. Le certificat, émis pour le domaine, ne couvre évidemment pas cette adresse. Les deux champs de Réglages puis Général doivent porter votre domaine, en https, sans barre oblique finale.
Le certificat qui ne couvre pas le www. Signature nette, NET::ERR_CERT_COMMON_NAME_INVALID, et un site qui marche pour certains visiteurs et pas pour d'autres selon la façon dont ils ont tapé l'adresse. Réémettez le certificat en incluant les deux noms, puis vérifiez que la redirection de l'un vers l'autre est bien en place.
Si rien n'a marché
L'avertissement n'apparaît que chez vous. Testez un autre site en https depuis le même poste. Si lui aussi déclenche un avertissement, c'est le réseau ou le navigateur, pas votre site.
Vous n'avez pas accès à l'hébergement. C'est plus fréquent qu'on ne croit, et deux fils de forums officiels racontent la même histoire, celle d'un prestataire parti avec les accès. Aucune manipulation depuis WordPress ne remplacera cet accès. Il faut le récupérer, ou déménager le site.
Votre hébergeur affirme que le certificat est bon et referme le ticket. Rouvrez avec des éléments qu'il ne peut pas écarter : la date notAfter lue par openssl, le code de réponse sur le chemin de validation en http, et les en-têtes de cette réponse. Un demandeur bloqué avec trente visiteurs dans le même cas s'est vu répondre que le problème venait de son réseau.
Ce que notre forfait couvre. La panne : remettre le site en ligne, avec un certificat valide et un renouvellement qui repart. Il ne couvre pas la reconstruction d'une mise en page abîmée dans un constructeur, ni la refonte d'un thème.
Si vous préférez ne pas passer la soirée dans un .htaccess, c'est exactement le genre d'intervention qu'on fait au quotidien : remettre un site WordPress en ligne, prix unique, 149 € HT, remis en ligne ou remboursé.
Comment éviter que ça recommence
Posez la ligne d'exclusion maintenant, à froid. Une fois le site reparti, ajoutez la condition sur /.well-known/acme-challenge/ dans votre .htaccess, même si le renouvellement fonctionne aujourd'hui. Elle ne coûte rien et elle vous évite la panne d'ici trois mois.
Retestez le chemin de validation après chaque changement d'infrastructure. Quatre choses le cassent : une modification de la zone DNS, une réécriture ajoutée dans le .htaccess, l'activation d'un proxy devant le site, un changement de mode SSL. Après l'une d'elles, la commande curl de ce guide prend dix secondes et vaut une soirée.
Surveillez la date d'expiration au lieu d'attendre l'avertissement. La commande openssl donnée plus haut se met dans une tâche planifiée qui vous écrit trois semaines avant l'échéance. C'est trois semaines pour comprendre, au lieu d'un matin de panique.
Ne laissez pas une seule personne détenir les accès à l'hébergement. Les fils les plus douloureux du sujet ne sont pas techniques : ce sont ceux où le certificat est mort et où plus personne dans l'entreprise ne peut se connecter au serveur.
Questions fréquentes
Comment renouveler un certificat expiré ?
Là où il a été installé, jamais depuis WordPress. Sur un hébergement mutualisé, dans la section SSL du panneau ou dans l'espace client. Avec un accès SSH et Certbot, par certbot renew, précédé d'un certbot renew --dry-run. Avant de relancer quoi que ce soit, vérifiez que le chemin /.well-known/acme-challenge/ répond bien en http, sinon la demande échouera de la même façon que les précédentes.
Pourquoi on me dit votre connexion n'est pas privée ?
Parce que le navigateur n'a pas pu valider le certificat du site. Trois raisons couvrent presque tous les cas : le certificat a expiré, il ne couvre pas l'adresse demandée, ou il n'est pas signé par une autorité reconnue. Le code affiché sous le bouton des paramètres avancés dit laquelle des trois. L'horloge de votre ordinateur peut aussi être en cause, mais uniquement si tous les sites en https déclenchent le même message.
Est-il sûr de visiter un site web avec un certificat expiré ?
Le chiffrement fonctionne toujours, ce qui n'est plus garanti est l'identité du site. En pratique, sur un site que vous connaissez et dont vous venez de constater que le certificat a expiré, le risque est faible. Ne saisissez ni mot de passe ni coordonnées bancaires tant que la situation n'est pas rétablie, et ne prenez pas l'habitude de cliquer sur « Continuer quand même » : c'est ce réflexe que les avertissements cherchent à empêcher.
Comment vérifier la validité d'un certificat ?
Depuis un terminal, openssl s_client -connect votre-domaine.fr:443 \
-servername votre-domaine.fr </dev/null 2>/dev/null \
| openssl x509 -noout -dates affiche les dates de début et de fin. Sans terminal, cliquez sur l'icône à gauche de l'adresse dans le navigateur, puis sur les détails du certificat. Vérifiez aussi le nom pour lequel il a été émis : un certificat valide pour ledomaine.fr ne couvre pas www.ledomaine.fr s'il n'a pas été demandé pour les deux.
Pourquoi le renouvellement automatique s'arrête-t-il tout seul ?
Il ne s'arrête pas tout seul, quelque chose l'empêche de valider le domaine. La validation passe par une requête en clair sur le port 80, vers /.well-known/acme-challenge/. Une redirection https qui n'exclut pas ce chemin, un enregistrement DNS AAAA qui ne répond pas, un proxy activé devant le site, un dossier de dépôt qui n'est pas celui que le serveur publie : chacun suffit. La panne ne se voit pas le jour où elle apparaît, seulement à l'expiration suivante.