« Ce site ne peut pas fournir de connexion sécurisée » : que faire ?ERR_SSL_PROTOCOL_ERROR : savoir si c'est le site ou l'appareil, puis réparer.

1. Testez sur un autre appareil, en 4G : erreur partout, c'est le serveur ; sur un seul appareil, c'est lui ou son réseau.
2. Faites tester l'adresse par SSL Labs : il dit si le serveur sait établir une connexion chiffrée, et pour quelles adresses.
3. Activez le certificat de chaque adresse chez l'hébergeur, avec et sans www : Let's Encrypt est gratuit.
4. Après un changement d'hébergeur, vérifiez que les enregistrements A et AAAA pointent vers le nouveau serveur.
5. Derrière Cloudflare, attendez que le certificat soit Active, et gardez un seul niveau de sous-domaine.
6. Sur un seul appareil : navigation privée, antivirus, VPN ou autre réseau, puis navigateur à jour.

Dans ce guide

• Les messages, et les erreurs voisines
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• Ce que nous ferions à votre place
• Questions fréquentes

• Chrome, sur ordinateur comme sur téléphone : « Ce site ne peut pas fournir de connexion sécurisée », puis « votresite.fr a envoyé une réponse incorrecte », avec le code ERR_SSL_PROTOCOL_ERROR en dessous. La page ne propose que de recharger : contrairement à « Votre connexion n'est pas privée », aucun lien ne permet de continuer vers le site, car aucune connexion n'a pu être établie.
• Edge, construit sur la même base que Chrome : une page d'erreur semblable, avec le même code ERR_SSL_PROTOCOL_ERROR.
• Firefox : une page d'échec de la connexion sécurisée, avec le code PR_END_OF_FILE_ERROR, ou SSL_ERROR_RX_RECORD_TOO_LONG quand le serveur répond en clair là où il devrait chiffrer.
• Safari, sur Mac, iPhone et iPad : Safari ne peut pas ouvrir la page, faute d'avoir pu établir une connexion sécurisée avec le serveur.

Le nom d'origine, SSL, est resté dans le code, mais la connexion chiffrée des sites s'appelle aujourd'hui TLS : c'est elle que désigne le « s » de https://. Avant d'échanger la moindre page, le navigateur et le serveur se mettent d'accord sur la version de TLS et la méthode de chiffrement, puis le serveur présente son certificat, que le navigateur vérifie. ERR_SSL_PROTOCOL_ERROR veut dire que cet accord a échoué en route. Plusieurs messages se ressemblent, et ne se réparent pas au même endroit :

Si tous les visiteurs la voient : le serveur

1. Une adresse sans certificat actif. Un domaine tout juste ajouté ou pointé vers l'hébergement, le www ou un sous-domaine oublié, un certificat pas encore délivré : le serveur n'a rien de prêt pour chiffrer cette adresse. Selon sa configuration, le navigateur affiche alors cette erreur, ou « Votre connexion n'est pas privée » si le serveur présente le certificat d'une autre adresse.
2. Derrière Cloudflare, un certificat pas encore actif ou une adresse non couverte. Le certificat universel de Cloudflare arrive de 15 minutes à 24 heures après l'activation du domaine, et ne couvre que le domaine et un seul niveau de sous-domaine. Cloudflare cite ces deux points en premier pour cette erreur ; Chrome affiche aussi, dans ces cas, sa voisine ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
3. Un changement d'hébergeur pas terminé : une partie des visiteurs arrive encore sur l'ancien serveur, qui ne sert plus votre domaine en HTTPS, le temps que le DNS se mette à jour, ou pour toujours si un enregistrement AAAA (l'adresse IPv6) y pointe encore.
4. Le port du HTTPS qui répond en clair. Sur un serveur configuré à la main, le port 443, celui du HTTPS, est ouvert sans que le chiffrement y soit activé : le serveur y renvoie une page en http, que le navigateur ne peut pas lire. C'est le cas le plus littéral de « a envoyé une réponse incorrecte ».
5. Plus rarement, une configuration TLS trop ancienne ou cassée : un serveur resté sur TLS 1.0 ou 1.1, versions abandonnées que les navigateurs refusent (Chrome affiche alors plutôt ERR_SSL_VERSION_OR_CIPHER_MISMATCH), un module de chiffrement mal mis à jour, ou un pare-feu placé devant le serveur qui coupe la négociation.

Si un seul appareil la voit : l'appareil ou son réseau

1. Un antivirus qui analyse les connexions chiffrées. Pour lire le trafic HTTPS, il s'interpose entre le navigateur et le site, et certains gèrent mal TLS 1.3, la version actuelle.
2. Le réseau : un réseau d'entreprise ou d'école qui inspecte les connexions, un contrôle parental, un VPN ou un proxy, un Wi-Fi public qui attend encore qu'on accepte ses conditions.
3. Un réseau qui gère mal HTTP/3, la dernière version du protocole du web, qui passe par QUIC : l'erreur va et vient, disparaît après un rechargement ou avec un VPN, et ne touche que certains réseaux. Cloudflare le signale pour les sites qui passent par lui.
4. Une extension du navigateur qui se place entre vous et les sites : VPN, bloqueur, outil de sécurité.
5. Un navigateur ou un système trop ancien, qui ne connaît pas les méthodes de chiffrement actuelles.

La date et l'heure de l'appareil, souvent citées, provoquent plutôt une alerte de certificat (NET::ERR_CERT_DATE_INVALID) que cette erreur. Les vérifier ne coûte rien, mais ce n'est presque jamais la cause.

1. Le site, ou seulement votre appareil ?

Ouvrez le site sur un autre appareil, par exemple un téléphone en 4G, Wi-Fi coupé, puis dans un autre navigateur. Si l'erreur apparaît partout, la cause est sur le serveur : continuez à l'étape 2. Si elle n'apparaît que sur un ordinateur ou sur un réseau, passez à l'étape 7. Un cas trompeur : si l'erreur n'apparaît qu'en 4G, ou seulement chez certains visiteurs, pensez à l'étape 4. Beaucoup de réseaux mobiles passent par IPv6, et un enregistrement AAAA resté sur un ancien serveur ne touche que les visiteurs en IPv6.

2. Faites passer le test de SSL Labs

Ouvrez le test gratuit de SSL Labs, tapez votresite.fr et lancez-le ; une case permet de ne pas faire figurer le résultat dans les listes publiques du site. Au bout de quelques minutes, deux cas. Le test n'arrive pas à se connecter en HTTPS, ou ne trouve pas de certificat pour cette adresse : le serveur n'est pas prêt, et les étapes 3 à 5 diront pourquoi. Le test donne une note, avec TLS 1.2 et TLS 1.3 dans la liste des protocoles : le serveur sait faire, la cause est plutôt du côté des visiteurs (étape 7). Testez aussi l'adresse avec www. Et ouvrez le site en http://, sans le s : s'il s'affiche, le serveur répond, seul le HTTPS est en cause. Si le site passe par Cloudflare (enregistrement en nuage orange dans sa zone DNS), commencez par l'étape 6 : c'est alors Cloudflare, et non votre hébergeur, qui présente le certificat à vos visiteurs, et c'est lui que SSL Labs teste.

3. Activez le certificat de chaque adresse chez l'hébergeur

Le certificat doit couvrir chaque adresse que l'on tape : votresite.fr, www.votresite.fr, et chaque sous-domaine. Sous cPanel, ouvrez l'outil SSL/TLS Status de la section Sécurité (État ou Statut SSL/TLS selon la traduction) : chaque adresse y a son état, et le bouton Exécuter AutoSSL (Run AutoSSL) relance la demande ; chez o2switch, c'est l'outil Let's Encrypt SSL de cPanel qui délivre le certificat. Sous Plesk, ouvrez Certificats SSL/TLS dans la fiche du domaine. Chez OVHcloud, ouvrez l'hébergement, l'onglet « Certificats SSL », choisissez le domaine, puis « Activer SSL Let's Encrypt » ; OVHcloud prévient que la mise en place peut prendre plusieurs heures. Chez les autres hébergeurs, cherchez SSL dans la gestion du domaine. Une condition partout : le domaine doit déjà pointer vers ce serveur, sinon le certificat ne peut pas être délivré. Un certificat Let's Encrypt est gratuit, et chiffre exactement comme un certificat payant.

4. Après un changement d'hébergeur, vérifiez le DNS

Dans la zone DNS du domaine, chez le registraire ou chez Cloudflare, comparez l'enregistrement A du domaine et celui du www avec l'adresse IP que donne le nouvel hébergeur (sous cPanel, dans le bloc Informations générales). Un enregistrement AAAA, l'adresse IPv6, qui pointe encore vers l'ancien serveur envoie une partie des visiteurs au mauvais endroit : notez d'abord sa valeur (une capture d'écran de la zone suffit), puis corrigez-le, ou supprimez-le si le nouveau serveur n'a pas d'adresse IPv6. Après une modification, comptez de quelques minutes à quelques heures, le temps que les anciennes réponses expirent. Une fois le domaine bien pointé, relancez le certificat (étape 3).

5. Si vous gérez votre propre serveur : le port 443 doit chiffrer

Sur un serveur privé virtuel ou dédié, l'erreur vient souvent d'un site qui écoute sur le port 443 sans y activer le chiffrement. Avant de modifier quoi que ce soit, copiez le fichier de configuration du site dans votre dossier personnel, pas à côté de l'original : certaines installations de nginx chargent tous les fichiers du dossier, copies comprises. Avec Apache, le bloc <VirtualHost *:443> du site doit contenir SSLEngine on et les chemins du certificat et de sa clé (SSLCertificateFile, SSLCertificateKeyFile). Avec nginx, la ligne listen doit porter le paramètre ssl, listen 443 ssl;, avec ssl_certificate et ssl_certificate_key. N'autorisez que TLS 1.2 et TLS 1.3 : c'est le réglage par défaut des versions récentes de nginx ; avec Apache, dont le réglage par défaut peut encore accepter TLS 1.0 et 1.1, ajoutez au bloc du site la ligne SSLProtocol -all +TLSv1.2 +TLSv1.3. Vérifiez la configuration (apachectl configtest ou nginx -t), rechargez le service, puis refaites le test de l'étape 2. Si c'est un prestataire qui gère le serveur, transmettez-lui ces points avec le résultat de SSL Labs.

6. Si le site passe par Cloudflare

Quand l'enregistrement du site est en Proxied (nuage orange), c'est Cloudflare qui établit la connexion chiffrée avec vos visiteurs. Dans le tableau de bord, ouvrez SSL/TLS, puis Edge Certificates : le certificat de type Universal doit être Active. Cloudflare annonce de 15 minutes à 24 heures après l'activation du domaine. En attendant, sa documentation propose de mettre le domaine en pause, à condition que le serveur ait son propre certificat : dans la vue d'ensemble (Overview) du domaine, choisissez Advanced Actions, puis Pause Cloudflare on Site. Les visiteurs vont alors directement au serveur, sans la protection de Cloudflare : réactivez Cloudflare dès que le certificat est Active. Regardez ensuite l'adresse : le certificat universel couvre votresite.fr et un seul niveau de sous-domaine, comme boutique.votresite.fr, mais pas fr.boutique.votresite.fr. Pour une adresse à deux niveaux, il faut l'option Total TLS ou un certificat avancé, qui demandent tous deux l'option payante Advanced Certificate Manager, ou plus simplement un nom à un seul niveau, comme boutique-fr.votresite.fr.

Le mode de chiffrement, dans SSL/TLS, puis la vue d'ensemble (Overview), règle la liaison entre Cloudflare et votre serveur, pas celle du visiteur : un mauvais choix y donne plutôt une erreur 525 ou 526, ou des redirections en boucle. Gardez Full (strict), avec un certificat valide sur le serveur. Si seuls certains visiteurs ont l'erreur, souvent sur un réseau d'entreprise ou chez un même opérateur, Cloudflare conseille deux tests de quelques minutes : couper HTTP/3 (with QUIC), dans Speed, puis Settings, partie Protocol Optimization ; puis couper TLS 1.3, dans SSL/TLS, puis Edge Certificates. Si l'un des deux règle le problème, c'est le réseau ou l'antivirus du visiteur qui gère mal ce protocole. Réactivez-les aussitôt : couper TLS 1.3 baisse la sécurité de tous vos visiteurs.

7. Si un seul appareil a l'erreur

• Ouvrez le site en navigation privée : les extensions y sont en général désactivées. Si le site s'ouvre, désactivez vos extensions une à une (VPN, bloqueur, sécurité) pour trouver la fautive.
• Coupez un moment l'analyse des connexions chiffrées de l'antivirus, souvent appelée analyse HTTPS ou protection web, rechargez, puis réactivez-la. Si c'était elle, mettez l'antivirus à jour, ou ajoutez le site à ses exceptions.
• Changez de réseau : coupez le VPN ou le proxy, passez en 4G. Un réseau d'entreprise, d'école ou un Wi-Fi public peut filtrer les connexions chiffrées, et un Wi-Fi d'hôtel attend parfois que vous acceptiez ses conditions sur sa page de connexion. Au bureau, le service informatique peut autoriser le site.
• Mettez le navigateur et le système à jour, puis fermez complètement le navigateur et rouvrez-le. Le conseil, souvent lu, d'effacer l'état SSL dans les options Internet de Windows ne vide que la mémoire de Windows : Chrome, Edge et Firefox gèrent leurs connexions chiffrées eux-mêmes.
• Vérifiez la date et l'heure, en réglage automatique : dix secondes, pour écarter cette piste.

8. Une fois la connexion rétablie

Ouvrez les quatre adresses, avec et sans www, en http:// et en https:// : toutes doivent mener à la même adresse en https://. Dans WordPress, vérifiez que les deux adresses de Réglages, puis Général, commencent par https://. Videz le cache du site et, s'il y a lieu, celui de Cloudflare. Si la page se met à tourner en boucle, suivez notre guide ERR_TOO_MANY_REDIRECTS ; si c'est « Votre connexion n'est pas privée » qui s'affiche maintenant, le certificat lui-même est en cause : voyez le guide du certificat SSL expiré ou invalide.

• Certificat de sécurité expiré ou invalide (SSL). « Votre connexion n'est pas privée », NET::ERR_CERT_DATE_INVALID et les autres alertes du navigateur.
• ERR_TOO_MANY_REDIRECTS, redirections en boucle. Le site renvoie le navigateur en boucle : mode SSL de Cloudflare, http et https, avec ou sans www.
• Erreur 520, 521 ou 522 de Cloudflare. Le serveur qui héberge le site refuse la connexion, tarde trop ou répond de façon inattendue.
• Erreur 403 Forbidden, accès refusé. Droits des fichiers, règle du .htaccess, extension de sécurité, pare-feu de l'hébergeur ou de Cloudflare.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 30 octobre 2026. Manipulations et documentations vérifiées le 30 octobre 2026 ; les réglages de WordPress cités valent pour WordPress 6 et 7.

• Cloudflare, dépanner ERR_SSL_PROTOCOL_ERROR (certificat pas encore actif, sous-domaines à plusieurs niveaux, tests de HTTP/3 et de TLS 1.3, antivirus et réseaux qui s'interposent) et le réglage de HTTP/3 (Speed, puis Settings, partie Protocol Optimization).
• Cloudflare, dépanner ERR_SSL_VERSION_OR_CIPHER_MISMATCH (certificat universel délivré de 15 minutes à 24 heures après l'activation, présenté seulement aux adresses en Proxied ; pause de Cloudflare en attendant), mettre Cloudflare en pause (Overview, Advanced Actions, Pause Cloudflare on Site ; plus de certificats ni de pare-feu de Cloudflare pendant la pause) et ce que couvre le certificat universel (domaine et premier niveau de sous-domaine ; Total TLS et certificats avancés avec Advanced Certificate Manager).
• MDN, Transport Layer Security (la négociation, TLS 1.3, TLS 1.0 et 1.1 à ne plus utiliser).
• nginx, configurer un serveur HTTPS (paramètre ssl de listen, TLS 1.2 et 1.3 par défaut) ; Apache, configurer mod_ssl (SSLEngine on, certificat et clé) et la directive SSLProtocol (réglage par défaut all -SSLv3, qui comprend TLS 1.0 et 1.1).
• OVHcloud, activer le certificat Let's Encrypt d'un hébergement web (onglet Certificats SSL, mise en place en plusieurs heures).
• Google, erreurs de réseau et de DNS (traitées comme les erreurs de serveur ; pages injoignables retirées de l'index en quelques jours).

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.