Le navigateur et le serveur ne parviennent pas à établir la connexion chiffrée : l’échange échoue avant même la vérification du certificat. Le plus souvent, le serveur répond en http simple sur le port réservé au HTTPS, ou n’a aucun certificat pour ce domaine. Il arrive aussi que les deux côtés ne partagent aucune méthode de chiffrement commune.
Pourquoi cette erreur apparaît
- Le HTTPS n’est pas activé pour ce domaine sur l’hébergement : le serveur répond en http sur le port 443, d’où SSL_ERROR_RX_RECORD_TOO_LONG dans Firefox.
- Après une migration, le domaine pointe vers un serveur où le certificat n’a pas encore été installé.
- WordPress ou une règle du fichier .htaccess force le passage en HTTPS alors qu’aucun certificat n’est actif.
- Un service intermédiaire comme Cloudflare n’a pas de certificat actif pour ce domaine ou ce sous-domaine, cas classique de ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
- Le serveur n’accepte que de vieilles versions du protocole (TLS 1.0 ou 1.1), refusées par les navigateurs actuels.
- Côté visiteur, un antivirus qui inspecte les connexions HTTPS ou un réseau filtré peut aussi provoquer l’erreur.
Comment corriger le problème
Situer le problème : serveur ou poste
Ouvrez le site avec un autre navigateur, puis depuis un téléphone en données mobiles. Si l’erreur ne touche qu’un ordinateur, regardez son antivirus (option d’analyse HTTPS ou d’analyse web) et le réseau utilisé. Si elle apparaît partout, c’est la configuration du serveur qu’il faut revoir.
Essayer l’adresse en http
Tapez http://monsite.fr, sans le s. Si la page s’affiche, le site fonctionne mais le HTTPS n’est pas configuré pour ce domaine. Rendez-vous dans la rubrique SSL ou Certificats de l’espace client de l’hébergement pour l’activer. Si le navigateur repasse de lui-même en https, le site impose le HTTPS : faites le test depuis un autre appareil ou avec la commande curl -I http://monsite.fr.
Activer ou réinstaller le certificat
Vérifiez qu’un certificat est installé et actif pour ce domaine précis, avec et sans www. Après un changement d’hébergeur, assurez-vous d’abord que le DNS pointe vers le nouveau serveur, puis lancez la génération du certificat depuis son interface.
Regarder du côté de Cloudflare ou du CDN
Si le domaine passe par Cloudflare, ouvrez son tableau de bord : le certificat de bordure doit être actif pour l’adresse exacte, sous-domaine compris. Réglez ensuite le mode SSL en cohérence avec l’hébergement, Full (strict) quand celui-ci possède son propre certificat valide.
Retrouver l’administration en attendant
Si WordPress redirige vers https et vous empêche de vous connecter, gardez une copie de wp-config.php et ajoutez ces lignes au-dessus de « C’est tout, ne touchez pas à ce qui suit ». Mettez aussi en commentaire, dans une copie sauvegardée de .htaccess, la règle qui force le HTTPS. Remettez le https dès que le certificat fonctionne.
define( 'WP_HOME', 'http://monsite.fr' );
define( 'WP_SITEURL', 'http://monsite.fr' );Observer la négociation TLS
curl -vI détaille la poignée de main TLS, l’échange initial où client et serveur choisissent leur méthode de chiffrement. Une erreur « wrong version number » révèle un serveur qui parle http sur le port 443. Sur un serveur privé, vérifiez que l’hôte virtuel HTTPS existe pour ce domaine et que TLS 1.2 et 1.3 sont activés.
curl -vI https://monsite.fr
openssl s_client -connect monsite.fr:443 -servername monsite.fr -tls1_2Gardez une copie de wp-config.php et de .htaccess avant toute modification, et notez chaque changement pour pouvoir réactiver le HTTPS ensuite.
Un autre message d'erreur ? Collez-le dans le décodeur : il le reconnaît et vous oriente vers la bonne fiche.
Ouvrir le décodeur