ERR_SSL_PROTOCOL_ERROR : ce que ça signifie et comment le corriger

Ce que signifie ERR_SSL_PROTOCOL_ERROR

Une connexion TLS commence par un handshake : le client envoie un ClientHello listant les versions de protocole et les suites de chiffrement qu'il supporte, et le serveur est censé répondre par un ServerHello en choisissant l'une d'elles, suivi de son certificat. ERR_SSL_PROTOCOL_ERROR se déclenche quand cet échange s'effondre avant d'atteindre l'étape du certificat, le plus souvent parce que ce qui a répondu sur le port ne parlait pas TLS du tout, ou parce que les deux côtés n'ont pas pu s'accorder sur la façon de le parler. C'est le terme de recherche pour code d'erreur le plus fréquent chez Chrome, et ce volume reflète combien de causes racines différentes se réduisent au même message générique plutôt qu'une cause commune unique.

Comment l'erreur apparaît

Chrome et Edge affichent ERR_SSL_PROTOCOL_ERROR sans aucun détail de certificat, parce qu'aucun certificat n'a jamais été présenté à montrer. Firefox affiche généralement « Secure Connection Failed » avec un code tel que SSL_ERROR_RX_MALFORMED_HANDSHAKE ou SSL_ERROR_PROTOCOL_VERSION_ALERT selon la façon dont le handshake s'est cassé.

Depuis la ligne de commande, curl et openssl identifient tous deux l'échec avec précision, ce qui est le moyen le plus rapide de dépasser une simple supposition :

curl -v https://example.com/
...
* TLSv1.3 (OUT), TLS handshake, Client hello
* OpenSSL/3.x: error:0A000126:SSL routines::unexpected eof while reading
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL

openssl s_client -connect example.com:443 -servername example.com
...
140... error:1408F10B:SSL routines:ssl3_get_record:wrong version number

« Wrong version number » signifie presque toujours que le port 443 a répondu avec du HTTP simple, pas du TLS, puisque les premiers octets d'une réponse HTTP ressemblent à du charabia pour un analyseur TLS qui attend un ServerHello. Une connexion qui reste bloquée et expire sans aucune erreur, plutôt que d'échouer rapidement, signifie généralement qu'un pare-feu ou un proxy abandonne silencieusement les paquets au lieu que le serveur les refuse activement.

Ce qui provoque ERR_SSL_PROTOCOL_ERROR

• Le port 443 sert du HTTP simple, ou un tout autre service. Un reverse proxy mal configuré, un service qui a planté en laissant un écouteur de repli, ou une règle NAT pointant vers le mauvais backend produisent tous une réponse non-TLS sur le port TLS.
• Incompatibilité de version TLS ou de chiffrement. Un serveur verrouillé sur TLS 1.0 ou 1.1 pour une conformité héritée ne partage aucun protocole commun avec un navigateur qui exige TLS 1.2 ou supérieur, donc le handshake échoue d'emblée.
• Le Server Name Indication (SNI) est manquant ou mal configuré. Sur un serveur hébergeant plusieurs certificats sur une seule IP, une correspondance SNI manquante peut lui faire présenter le mauvais certificat ou refuser le handshake.
• Les expérimentations QUIC et HTTP/3. Chrome essaie parfois QUIC en premier et se replie sur TLS par-dessus TCP ; un réseau qui gère mal le trafic UDP de QUIC peut se manifester par une erreur de protocole lors de la tentative de repli.
• Le scan HTTPS d'un antivirus ou d'un proxy d'entreprise. Un logiciel qui intercepte le TLS pour inspecter le trafic démarre son propre handshake à la place du vrai, et un certificat d'interception cassé casse ce substitut.
• HSTS forçant HTTPS sur un hôte dont le TLS est cassé. Une fois qu'un navigateur a mis en cache une politique HSTS pour un domaine, il ne tentera plus de HTTP simple, donc un hôte qui se repliait gracieusement autrefois échoue désormais net.
• Une chaîne de certificats ancienne ou cassée, sur un vieux client. Des systèmes d'exploitation et navigateurs très anciens antérieurs à une racine ou un intermédiaire plus récent peuvent faire échouer le handshake de façons indiscernables d'une incompatibilité de version.
• L'horloge du client est très fausse. Une horloge suffisamment décalée peut amener un client à refuser de négocier une session du tout, pas seulement rejeter le certificat après coup.

Comment savoir de qui vient la faute

Lancez la même requête depuis un second réseau, par exemple un téléphone en données mobiles au lieu du Wi-Fi du bureau. Si le site se charge sans problème là-bas, le problème est local : un proxy d'entreprise, une interception antivirus, ou un portail captif sur le premier réseau. Si le handshake échoue à l'identique partout où vous essayez, la configuration TLS du serveur est la cause. Une vérification SSL lancée depuis plusieurs emplacements à la fois répond à cela en une seule requête au lieu d'emprunter un second appareil, et elle rapporte le protocole et le chiffrement exacts que le serveur a négociés (ou refusés) depuis chaque point d'observation.

Comment corriger ERR_SSL_PROTOCOL_ERROR

Si vous êtes visiteur

1. Videz l'état TLS de Chrome sur chrome://net-internals/#hsts et chrome://restart, ou videz simplement les données de navigation pour « images et fichiers en cache » plus « cookies et données de sites » pour le site affecté, ce qui vide aussi l'état HSTS et de session SSL mis en cache.
2. Désactivez l'expérimentation QUIC sur chrome://flags/#enable-quic, réglez-la sur Disabled, et redémarrez le navigateur. Si le site se charge ensuite, un réseau ou un proxy peu compatible avec QUIC était la cause.
3. Vérifiez la date et l'heure système et réglez-les pour se synchroniser automatiquement ; une horloge suffisamment décalée peut casser le handshake net, pas seulement la vérification de certificat qui vient après.
4. Désactivez le scan HTTPS dans votre antivirus (généralement sous un réglage « protection web » ou « scan SSL/TLS ») et réessayez. Si cela corrige le problème, mettez à jour l'antivirus ou ajoutez le site à sa liste d'exclusions plutôt que de laisser le scan désactivé entièrement.
5. Essayez un autre réseau, comme les données mobiles. Un proxy d'entreprise ou un équipement réseau défaillant qui n'affecte qu'une seule connexion est une cause courante qui n'a rien à voir avec le site lui-même.

Si vous gérez le site

1. Confirmez que le port 443 est réellement du TLS avec la commande openssl ci-dessus. « Wrong version number » ou une réponse en texte brut signifient que le mauvais service est lié à ce port ; corrigez la configuration du proxy ou de l'écouteur avant de toucher aux certificats du tout.
2. Fixez explicitement les versions de protocole supportées. Sur nginx :

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!MD5;

   Abandonner TLS 1.0 et 1.1 corrige les handshakes des clients modernes mais cassera l'accès depuis de très vieux clients qui en dépendent encore ; décidez ce compromis délibérément plutôt que par accident.
3. Confirmez que le bloc serveur écoute réellement en TLS sur le port attendu : listen 443 ssl; (ou listen 443 ssl http2;) et que les directives certificat et clé pointent vers des fichiers qui existent et correspondent entre eux.
4. Vérifiez l'ordre de la chaîne de certificats. Le certificat feuille doit venir en premier, suivi des intermédiaires dans l'ordre jusqu'à (sans l'inclure) la racine ; une chaîne servie dans le désordre ou à laquelle il manque un intermédiaire cause des échecs de handshake sur certains clients tout en fonctionnant sur d'autres qui mettent en cache l'intermédiaire manquant ailleurs.
5. Si le domaine se trouve derrière Cloudflare, vérifiez le mode SSL/TLS. Le mode Flexible termine le TLS à la bordure et parle en HTTP simple à l'origine, ce qui échoue net si l'origine n'accepte que le HTTPS ; le mode Full exige n'importe quel certificat à l'origine ; Full (strict) exige un certificat d'origine valide et de confiance et produira lui-même des échecs de handshake si le certificat d'origine est autosigné ou expiré.
6. Rechargez, ne vous contentez pas d'éditer, après tout changement de configuration : nginx -t && systemctl reload nginx valide la configuration avant de l'appliquer.

ERR_SSL_PROTOCOL_ERROR face à des erreurs d'apparence similaire

• ERR_CERT_DATE_INVALID se produit après qu'un certificat a été reçu et lu ; le handshake est allé jusque-là puis a échoué à une comparaison de date. ERR_SSL_PROTOCOL_ERROR ne va jamais aussi loin du tout.
• ERR_CERT_AUTHORITY_INVALID se produit aussi après qu'un certificat a été reçu ; le navigateur l'a lu et n'a pas fait confiance à qui l'a signé. Là encore, une erreur de protocole signifie qu'aucun certificat n'a jamais été jugé.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH est le cousin plus spécifique de cette erreur : elle se déclenche quand le handshake a bien progressé assez loin pour comparer les versions et les chiffrements supportés, et n'a trouvé aucun recoupement du tout, typiquement un vieux serveur n'offrant que SSLv3 ou TLS 1.0 face à un navigateur moderne qui les refuse. ERR_SSL_PROTOCOL_ERROR est l'échec plus large et moins spécifique qui couvre tout le reste, y compris une réponse non-TLS sur le port, des données de handshake mal formées, et un logiciel d'interception qui a mal tourné.

Comment prévenir ERR_SSL_PROTOCOL_ERROR

Un échec de handshake introduit par un changement de configuration, une mise à jour de proxy, ou un basculement de mode SSL Cloudflare n'apparaît pas dans une vérification de statut HTTP normale, puisque la connexion ne va jamais assez loin pour en produire un. Une vérification SSL dédiée lit directement le protocole et le chiffrement négociés et, exécutée depuis plus de 300 points de contrôle dans 158 villes, montre si le handshake échoue partout ou seulement depuis un réseau, la même distinction que ce guide détaille à la main. Lancez une vérification de certificat SSL contre le domaine, et mettez en place une surveillance SSL et d'expiration de domaine continue pour qu'un handshake cassé alerte avant que les visiteurs ne le signalent.

Questions fréquentes

ERR_SSL_PROTOCOL_ERROR signifie-t-il que mon certificat est mauvais ?

Pas nécessairement. L'erreur se déclenche avant que le navigateur n'atteigne le certificat, donc le certificat lui-même peut être parfaitement correct tandis que la négociation TLS sous-jacente échoue quand même.

Pourquoi cela ne se produit-il que sur un seul ordinateur ou un seul réseau ?

Un scan HTTPS antivirus, un proxy d'entreprise, ou un chemin QUIC cassé sur ce réseau spécifique sont les raisons habituelles pour lesquelles un handshake échoue à un endroit et réussit partout ailleurs. Tester depuis un second réseau est le moyen le plus rapide de le confirmer.

Je viens de placer mon site derrière Cloudflare et maintenant les visiteurs voient cela. Qu'est-ce qui a changé ?

Vérifiez le mode SSL/TLS dans le tableau de bord. Le mode Flexible attend que l'origine accepte du HTTP simple et échoue si elle ne sert que du HTTPS ; Full (strict) attend un certificat d'origine valide et de confiance et échoue sur un certificat autosigné ou expiré.

Désactiver TLS 1.0 et 1.1 sur mon serveur casse-t-il quelque chose ?

Cela peut arriver, pour les visiteurs sur de très vieux navigateurs qui n'ont jamais reçu de mise à jour vers TLS 1.2. Pour la plupart du trafic actuel, cela corrige plus de handshakes que ça n'en casse, mais vérifiez d'abord votre propre répartition de clients.

Pourquoi curl a-t-il dit « wrong version number » ?

Ce message signifie que curl a envoyé un ClientHello TLS et a reçu en retour des octets qui ne s'analysent pas comme un ServerHello TLS, presque toujours parce que le port sert du HTTP simple ou un autre protocole non-TLS.