ERR_SSL_PROTOCOL_ERROR : le corriger sur Chrome et Android

Qu'est-ce que ERR_SSL_PROTOCOL_ERROR ?

ERR_SSL_PROTOCOL_ERROR signifie que la connexion sécurisée s'est interrompue pendant sa poignée de main TLS, avant que votre navigateur ait pu charger quoi que ce soit. Chrome et Edge l'affichent ainsi : « Ce site ne peut pas fournir de connexion sécurisée. example.com a envoyé une réponse incorrecte. » Si l'adresse est localhost, votre serveur de développement parle presque sûrement en HTTP simple : ouvrez http://localhost à la place (voir la section pour les développeurs plus bas).

Chaque connexion HTTPS commence par une poignée de main TLS, au cours de laquelle le navigateur et le serveur s'accordent sur une version du protocole (TLS 1.2 ou 1.3) et sur des chiffrements, et échangent des certificats. ERR_SSL_PROTOCOL_ERROR signifie que cette négociation a échoué : l'autre côté a répondu par quelque chose qui n'est pas du TLS valide, ou a rejeté la poignée de main d'une manière que le navigateur n'a pas su classer.

L'erreur survient avant l'envoi de toute requête HTTP : ce n'est donc pas un code de statut HTTP. La liste d'erreurs de Chromium la définit comme l'erreur -107, en une ligne, « An SSL protocol error occurred » : le fourre-tout d'une poignée de main cassée, à la différence de l'erreur -113, plus précise, « aucune version de protocole ni méthode de chiffrement en commun ».

À quoi ressemble ERR_SSL_PROTOCOL_ERROR

Chrome et les autres navigateurs basés sur Chromium affichent cette erreur sous forme d'un avertissement en pleine page avec le message « Ce site ne peut pas fournir de connexion sécurisée. » En dessous, vous verrez le code d'erreur précis. Voici les variantes courantes que vous pouvez rencontrer.

• localhost a envoyé une réponse incorrecte — la version que voient les développeurs : un https:// ouvert sur un serveur local qui parle en HTTP simple
• ERR_SSL_PROTOCOL_ERROR — le code d'erreur que Chrome affiche en petits caractères sous le message
• net::ERR_SSL_PROTOCOL_ERROR — le code d'erreur interne complet affiché dans la console des DevTools de Chrome
• Ce site ne peut pas fournir de connexion sécurisée — le titre du message tel que l'utilisateur le voit dans Chrome
• [domaine] a envoyé une réponse incorrecte — le texte d'erreur détaillé que Chrome affiche sous le titre
• ERR_SSL_PROTOCOL_ERROR sur tous les navigateurs — lorsque l'erreur apparaît en même temps dans Chrome, Edge, Brave et Opera (le problème vient alors du serveur ou de tout le système, pas d'un bug propre à un navigateur)

Quelles sont les causes de ERR_SSL_PROTOCOL_ERROR ?

Cette erreur a des causes côté client (votre appareil) et côté serveur (le site web). Savoir de quel côté vient le problème est la première étape pour le résoudre. Si l'erreur apparaît sur tous les sites, le problème est de votre côté. Si elle n'apparaît que sur un seul site, il vient probablement du serveur.

• HTTPS envoyé à un serveur qui parle HTTP — le cas le plus recherché : https://localhost sur un serveur de développement, ou un site dont le port 443 n'est pas configuré pour TLS. Le navigateur lance une poignée de main et reçoit du texte brut, ce que Chrome signale par « a envoyé une réponse incorrecte ».
• Analyse SSL/HTTPS de l'antivirus — les logiciels de sécurité qui interceptent le HTTPS (Avast, Kaspersky, Bitdefender, ESET) s'insèrent dans la poignée de main et peuvent la casser, sur tous les sites à la fois.
• Interférence d'un VPN ou d'un proxy — les VPN et les proxys d'entreprise qui inspectent le trafic HTTPS peuvent corrompre la poignée de main, surtout juste après un changement de réseau.
• Un réseau qui filtre le site — les filtres des fournisseurs d'accès, des écoles, des entreprises et des États, ainsi que les bloqueurs basés sur le DNS, cassent volontairement la poignée de main pour les sites qu'ils bloquent. Le signe qui ne trompe pas : le site se charge en données mobiles ou sur un autre Wi-Fi.
• Une configuration TLS défaillante sur le serveur — le port 443 répond en HTTP simple (un bloc serveur sur 443 sans TLS activé), ou un autre programme écoute sur le port 443.
• Extensions du navigateur — les extensions de confidentialité, les bloqueurs de publicités et les modules de sécurité qui réécrivent les requêtes HTTPS peuvent perturber la poignée de main.
• État périmé du navigateur — des données de session en cache qui ne correspondent plus au serveur.
• Souvent confondues avec elle — un serveur resté sur TLS 1.0 ou 1.1 affiche ERR_SSL_VERSION_OR_CIPHER_MISMATCH (« utilise un protocole incompatible ») ; un certificat expiré, au mauvais nom ou auto-signé, ou une horloge fausse, affiche une erreur de certificat (NET::ERR_CERT_…) ; un problème de QUIC (HTTP/3) affiche ERR_QUIC_PROTOCOL_ERROR. Voir ERR_SSL_VERSION_OR_CIPHER_MISMATCH et « Votre connexion n'est pas privée ».

ERR_SSL_PROTOCOL_ERROR sur localhost (développeurs)

localhost a envoyé une réponse incorrecte. ERR_SSL_PROTOCOL_ERROR signifie presque toujours que vous avez ouvert https://localhost sur un serveur de développement qui ne parle qu'en HTTP simple. Le navigateur lance une poignée de main TLS, le serveur répond par du texte HTTP ordinaire, et Chrome juge cette réponse incorrecte. Firefox signale la même erreur par SSL_ERROR_RX_RECORD_TOO_LONG.

• Utilisez l'adresse affichée par le serveur — remplacez https://localhost:3000 par http://localhost:3000. Les serveurs de développement Next.js, Vite, React, Django, Rails et Flask servent du HTTP tant que vous n'activez pas HTTPS
• Vérifiez le port — https://localhost sans port, c'est le port 443. Si votre application tourne sur le 3000 ou le 5173, la requête atteint un autre programme, ou rien du tout
• Chrome repasse toujours en https:// — une redirection mise en cache par une ancienne application sur le même port peut en être la cause : supprimez les images et fichiers en cache, ou testez dans une fenêtre de navigation privée. (Avant la version 132, Chrome pouvait aussi garder une entrée HSTS pour localhost, que vous supprimez sous Delete domain security policies dans chrome://net-internals/#hsts)
• Il vous faut HTTPS en local (rappels OAuth, cookies sécurisés) — next dev --experimental-https crée un certificat de confiance locale avec mkcert ; Vite accepte des options de certificat dans server.https, ou @vitejs/plugin-basic-ssl pour un certificat auto-signé rapide ; ailleurs, mkcert -install && mkcert localhost 127.0.0.1 produit des fichiers que votre serveur peut charger
• Un certificat auto-signé donne une autre erreur — NET::ERR_CERT_AUTHORITY_INVALID, pas celle-ci. Cliquez sur Paramètres avancés → Continuer vers localhost (dangereux), ou mieux, utilisez un certificat mkcert (l'ancien flag allow-insecure-localhost a expiré)

Comment corriger ERR_SSL_PROTOCOL_ERROR (pour les utilisateurs)

Commencez par la correction 1 : en deux minutes, elle vous dit si le problème vient de votre navigateur, de votre appareil ou de votre réseau, ou du site. Descendez ensuite la liste.

Correction 1 : essayer la navigation privée et un autre réseau

La navigation privée démarre sans cookies, sans cache et sans extensions (sauf si vous les y avez autorisées). Ouvrez le site dans une fenêtre de navigation privée (Ctrl+Shift+N dans Chrome et Edge, Ctrl+Shift+P dans Firefox), puis sur un autre réseau, par exemple les données mobiles de votre téléphone.

S'il se charge en navigation privée, la cause est dans votre navigateur : une extension ou des données périmées (corrections 4 et 5). S'il ne se charge que sur un autre réseau, c'est votre réseau, un VPN ou un proxy qui le filtre ou l'intercepte (correction 3). S'il échoue partout, testez le site avec un vérificateur SSL : si celui-ci échoue aussi, seul le propriétaire du site peut corriger.

Correction 2 : désactiver l'analyse SSL/HTTPS de l'antivirus

De nombreux antivirus (Avast, Kaspersky, Bitdefender, ESET, Norton) incluent une fonction d'« analyse HTTPS » ou d'« inspection SSL » qui intercepte les connexions chiffrées en jouant le rôle de proxy intermédiaire. Quand elle gère mal la poignée de main d'un site, tous les navigateurs de l'ordinateur échouent sur ce site.

Cherchez dans votre antivirus les réglages nommés Bouclier Web, Analyse HTTPS, Analyse SSL ou Analyse des connexions chiffrées, et désactivez-les temporairement. Si l'erreur disparaît, vous pouvez ajouter le domaine concerné à la liste d'exclusion de l'antivirus.

Correction 3 : désactiver le VPN ou le proxy

Les VPN et les proxys HTTP se placent entre votre navigateur et le serveur web. Certains VPN inspectent le trafic HTTPS ou font passer les connexions par des serveurs dont le TLS est défaillant. Les proxys d'entreprise utilisent souvent l'interception SSL (comme l'analyse HTTPS d'un antivirus), qui peut casser les poignées de main TLS.

Déconnectez temporairement votre VPN et essayez de charger le site. S'il fonctionne sans le VPN, le problème vient de la façon dont votre VPN gère les connexions SSL. Essayez un autre serveur VPN ou contactez votre fournisseur.

Correction 4 : désactiver les extensions du navigateur

Les extensions qui filtrent ou redirigent le trafic, comme les extensions VPN et proxy et les modules de sécurité, peuvent casser les connexions sécurisées.

Allez dans chrome://extensions/, désactivez toutes les extensions et rechargez la page. Si l'erreur disparaît, réactivez-les une par une pour trouver la coupable.

Correction 5 : vider le cache et les cookies du navigateur

Des cookies ou des données en cache périmés gênent parfois la connexion, et les supprimer prend une minute.

• Étape 1 : Appuyez sur Ctrl+Shift+Delete (Mac : Cmd+Shift+Delete) pour ouvrir Supprimer les données de navigation
• Étape 2 : Choisissez Plus → Tout comme période
• Étape 3 : Cochez Cookies et autres données des sites et Images et fichiers en cache
• Étape 4 : Cliquez sur Supprimer les données (le bouton porte un autre nom si vous n'êtes pas connecté à Chrome) et redémarrez Chrome

Pour un seul site, allez dans chrome://settings/content/all, cherchez le domaine et supprimez ses données.

Correction 6 : écarter QUIC (HTTP/3)

Chrome essaie QUIC (HTTP/3 sur UDP) en parallèle d'une connexion TCP normale et retombe sur TCP quand QUIC échoue : QUIC est donc rarement la cause de ERR_SSL_PROTOCOL_ERROR. Si la page ou les DevTools affichent plutôt ERR_QUIC_PROTOCOL_ERROR, la solution est de désactiver QUIC (voir ERR_QUIC_PROTOCOL_ERROR) :

• Étape 1 : Tapez chrome://flags/#enable-quic dans la barre d'adresse
• Étape 2 : Trouvez Experimental QUIC protocol
• Étape 3 : Passez de Default à Disabled
• Étape 4 : Cliquez sur Relaunch pour redémarrer Chrome

Les pages se chargent quand même sans QUIC, en HTTP/2 sur TCP ; réactivez-le une fois le réseau ou le site réparé.

Correction 7 : mettre à jour votre navigateur

Les anciennes versions du navigateur peuvent ne pas avoir les fonctions TLS et les chiffrements qu'attendent les sites modernes, et les mises à jour corrigent des bogues TLS.

Pour mettre à jour Chrome : allez dans chrome://settings/help ou Menu → Aide → À propos de Google Chrome. Chrome télécharge les mises à jour automatiquement mais exige un redémarrage pour les appliquer. Pour Edge : edge://settings/help. Pour Firefox : Menu → Aide → À propos de Firefox.

Correction 8 : vider le cache DNS

Un DNS périmé peut envoyer votre navigateur vers un ancien serveur qui ne sert plus le site en TLS. Vider le cache DNS force une nouvelle résolution.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

Après le vidage, vérifiez que le domaine pointe vers la bonne adresse IP avec l'outil Recherche DNS de DNS Robot. Si l'adresse IP semble incorrecte, le site a peut-être changé d'hébergeur et la propagation DNS n'est pas terminée.

Correction 9 : vérifier la date et l'heure du système

Une horloge fausse affiche normalement une autre erreur, NET::ERR_CERT_DATE_INVALID (« Votre horloge est en avance » ou « Votre horloge est en retard »), car un certificat n'est valide qu'entre deux dates. Dix secondes suffisent pourtant pour l'écarter :

• Windows : Paramètres → Heure et langue → Date et heure → activez « Régler l'heure automatiquement » et « Définir le fuseau horaire automatiquement »
• Mac : Réglages Système → Général → Date et heure → activez « Régler la date et l'heure automatiquement »
• Linux : exécutez sudo timedatectl set-ntp true pour activer la synchronisation NTP

Correction 10 : effacer l'état SSL (Windows)

De nombreux guides conseillent Effacer l'état SSL dans les Options Internet de Windows (inetcpl.cpl → Contenu → Effacer l'état SSL). Cette action vide le cache de sessions de la bibliothèque TLS propre à Windows, utilisée par les applications qui s'appuient sur le réseau de Windows. Chrome et Edge utilisent leur propre bibliothèque TLS : cela change donc rarement quelque chose pour eux.

L'équivalent pour le navigateur est plus simple : fermez toutes les fenêtres du navigateur (vérifiez dans la zone de notification qu'aucun Chrome ne tourne en arrière-plan) puis rouvrez-le. Toutes les sessions TLS en cache sont alors abandonnées. Si l'erreur survit à un redémarrage complet, passez aux corrections suivantes.

Correction 11 : réinitialiser les paramètres réseau (dernier recours)

Si rien d'autre ne fonctionne, réinitialisez votre pile réseau. Sous Windows, ces commandes réinitialisent Winsock et TCP/IP, y compris les adresses IP statiques et les serveurs DNS que vous avez saisis à la main ; sous macOS et Linux, elles se limitent à vider le cache DNS ou à redémarrer le service réseau.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

Comment corriger ERR_SSL_PROTOCOL_ERROR (pour les propriétaires de sites)

Si de nombreux visiteurs signalent ERR_SSL_PROTOCOL_ERROR, le problème est sur le serveur : le plus souvent, le port 443 répond en HTTP simple, ou un autre programme occupe ce port. Les problèmes de certificat affichent leurs propres erreurs, mais vérifiez-les en passant. (Un certificat et une clé qui ne correspondent pas empêchent le serveur de charger la nouvelle configuration : vérifiez avec nginx -t ou apachectl configtest après chaque modification.)

Vérifier votre certificat SSL

La première étape consiste à vérifier que votre certificat SSL est valide, correctement installé et non expiré. Utilisez le Vérificateur de certificat SSL de DNS Robot pour vérifier instantanément l'état du certificat, sa date d'expiration, l'émetteur et la chaîne de certificats.

Ces problèmes de certificat affichent leurs propres erreurs plutôt que ERR_SSL_PROTOCOL_ERROR, mais corrigez-les en passant :

• Certificat expiré (NET::ERR_CERT_DATE_INVALID) — les certificats Let's Encrypt durent 90 jours (64 jours à partir de février 2027) : le renouvellement doit donc être automatique ; s'il a échoué (minuteur certbot arrêté, challenge DNS défaillant), le certificat expire sans bruit.
• Mauvais domaine (NET::ERR_CERT_COMMON_NAME_INVALID) — le certificat a été émis pour example.com mais le site est servi sur www.example.com (ou l'inverse). Le certificat doit correspondre exactement au domaine ou inclure un caractère générique (*.example.com).
• Certificat auto-signé (NET::ERR_CERT_AUTHORITY_INVALID) — parfait en développement, jamais approuvé par les navigateurs en production.
• Certificat révoqué (NET::ERR_CERT_REVOKED) — l'autorité de certification l'a révoqué après une compromission de clé ou une émission erronée.
• Mauvais certificat pour le nom (NET::ERR_CERT_COMMON_NAME_INVALID) — plusieurs sites partagent une même adresse IP et le serveur n'utilise pas SNI (Server Name Indication) pour choisir le certificat de chacun.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

Activer TLS 1.2 et TLS 1.3

Tous les navigateurs modernes exigent au minimum TLS 1.2 : TLS 1.0 et 1.1 ont été officiellement abandonnés par la RFC 8996 en 2021. Un côté qui refuse la version de l'autre met fin à la poignée de main par l'alerte TLS 70, protocol_version (RFC 8446 §6.2). Un serveur qui ne gère que TLS 1.0 ou 1.1 affiche ERR_SSL_VERSION_OR_CIPHER_MISMATCH plutôt que cette erreur, mais la connexion échoue de toute façon. TLS 1.3 se connecte en un aller-retour au lieu des deux de TLS 1.2 : activez les deux.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

Après avoir modifié votre configuration TLS, redémarrez votre serveur web (sudo systemctl restart nginx ou sudo systemctl restart apache2) et testez avec le Vérificateur de certificat SSL de DNS Robot pour vérifier que les protocoles sont actifs.

Installer la chaîne de certificats complète

Une chaîne incomplète s'affiche comme une erreur de certificat (NET::ERR_CERT_AUTHORITY_INVALID) sur les navigateurs et applications qui ne savent pas retrouver l'intermédiaire manquant : installez donc la chaîne complète pendant que vous vérifiez. Votre serveur doit envoyer votre certificat ainsi que les certificats intermédiaires qui le relient à une racine de confiance.

La plupart des autorités de certification fournissent un fichier « CA bundle » ou « full chain ». Pour Let's Encrypt, utilisez fullchain.pem (et pas seulement cert.pem). Pour les autres autorités, téléchargez le certificat intermédiaire depuis leur documentation et concaténez-le avec votre certificat.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Vérifier la configuration HSTS

HSTS (HTTP Strict Transport Security) indique aux navigateurs de toujours utiliser HTTPS pour votre domaine. Si votre politique HSTS a un max-age long et que votre configuration TLS se casse ensuite, les navigateurs ne peuvent pas revenir à HTTP : les visiteurs voient une page d'erreur sans possibilité de passer outre.

Vérifiez votre en-tête HSTS avec l'outil Vérificateur d'en-têtes HTTP de DNS Robot. Si vous avez défini un max-age très long (2 ans, par exemple) et que votre certificat a expiré, les visiteurs qui sont déjà venus sont enfermés en HTTPS sans repli. Pour corriger cela, réparez d'abord votre certificat SSL : les navigateurs se connecteront ensuite normalement.

Vérifier la configuration du serveur

Cette erreur de serveur casse la poignée de main même avec un certificat valide, et une autre affiche une erreur différente :

• Port 443 qui sert du HTTP simple — la cause classique côté propriétaire : dans nginx, listen 443; sans ssl (il faut listen 443 ssl;), ou un autre service lié au port 443.
• Incompatibilité des suites de chiffrement — un serveur qui ne propose que des chiffrements refusés par les navigateurs affiche ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Utilisez des chiffrements AEAD modernes (AES-GCM, ChaCha20).

Testez depuis l'extérieur avec openssl s_client -connect example.com:443 -servername example.com </dev/null : « wrong version number » (OpenSSL) ou « tlsv1 alert protocol version » (openssl intégré à macOS) signifie que le port 443 ne parle pas TLS, et l'affichage d'un certificat signifie que la poignée de main fonctionne.

ERR_SSL_PROTOCOL_ERROR sur Android

Les utilisateurs d'Android rencontrent ERR_SSL_PROTOCOL_ERROR dans Chrome pour Android comme dans les applications basées sur WebView. Les solutions diffèrent un peu de celles de l'ordinateur, car Android gère autrement les certificats et les paramètres réseau.

• Changez de réseau — coupez le Wi-Fi et essayez les données mobiles (ou l'inverse). Si le site se charge, le réseau le filtre ou l'intercepte
• Désactivez le DNS privé pour tester — Paramètres → Réseau et Internet → DNS privé → Désactivé (et dans Chrome : Paramètres → Confidentialité et sécurité → Utiliser un DNS sécurisé). Un service DNS filtrant (blocage de publicités, contrôle parental) envoie les sites qu'il bloque vers un serveur qui ne peut pas terminer la poignée de main
• Videz les données de Chrome — Paramètres → Applications → Chrome → Stockage → Vider le cache (puis l'option de gestion de l'espace si cela ne suffit pas)
• Mettez Chrome à jour — Play Store → votre photo de profil → Gérer les applications et l'appareil → mettez Chrome à jour
• Effacez les identifiants réseau — Paramètres → Sécurité (sur les téléphones récents : Autres paramètres de sécurité → Chiffrement et identifiants) → Effacer les identifiants. Cela supprime tous les certificats installés par l'utilisateur
• Vérifiez la date et l'heure — Paramètres → Système → Date et heure → réglage automatique. Une horloge fausse affiche une erreur de certificat, mais c'est rapide à écarter
• Réinitialisez les paramètres réseau — Paramètres → Système → Options de réinitialisation, puis la réinitialisation du Wi-Fi et du réseau mobile (son nom varie selon la version d'Android)

ERR_SSL_PROTOCOL_ERROR sur iPhone et iPad

Sur iPhone, Chrome affiche ERR_SSL_PROTOCOL_ERROR et Safari indique qu'il ne peut pas établir de connexion sécurisée avec le serveur. Les causes sont les mêmes que sur ordinateur ; seuls les interrupteurs sont ailleurs :

• Changez de réseau — coupez le Wi-Fi et essayez les données mobiles. Si le site se charge, le réseau Wi-Fi le filtre ou l'intercepte
• Supprimez les VPN et profils que vous ne reconnaissez pas — Réglages → Général → VPN et gestion de l'appareil. Un profil qui installe son propre certificat ou son propre VPN peut intercepter le HTTPS
• Testez sans le relais privé iCloud — Réglages → [votre nom] → iCloud → Relais privé → désactivé, puis réessayez
• Vérifiez les limites de Temps d'écran — Réglages → Temps d'écran → Contenu et confidentialité, puis le réglage du contenu web. Un site bloqué échoue au lieu de se charger
• Réglez l'horloge en automatique — Réglages → Général → Date et heure → Réglage automatique

ERR_SSL_PROTOCOL_ERROR dans les autres navigateurs

ERR_SSL_PROTOCOL_ERROR est un code d'erreur propre à Chromium. Les autres navigateurs affichent d'autres messages pour le même échec de poignée de main SSL.

Si l'erreur apparaît dans tous les navigateurs à la fois, le problème vient soit de votre système (analyse HTTPS de l'antivirus, VPN ou proxy, votre réseau), soit du serveur (le port 443 ne sert pas correctement TLS). Si un seul navigateur échoue, vérifiez ses extensions et ses données en cache.

Codes d'erreur SSL/TLS associés

Chrome possède plusieurs codes d'erreur liés à SSL. Ils indiquent tous des problèmes différents de poignée de main TLS ou de certificat.

Pour toutes les erreurs SSL, vous pouvez diagnostiquer rapidement le problème avec le Vérificateur de certificat SSL de DNS Robot : il affiche l'état du certificat, la complétude de la chaîne, les versions de TLS prises en charge et la date d'expiration en une seule analyse.

Si votre page indique que le site « utilise un protocole incompatible », vous avez ERR_SSL_VERSION_OR_CIPHER_MISMATCH, pas cette erreur : voir comment corriger ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Si la page indique plutôt « example.com a mis fin à la connexion de manière inattendue » (ERR_CONNECTION_CLOSED), la connexion a été coupée plutôt que cassée. Voir ERR_CONNECTION_CLOSED pour ce cas.