ERR_SSL_VERSION_OR_CIPHER_MISMATCH : protocole incompatible

Qu'est-ce que ERR_SSL_VERSION_OR_CIPHER_MISMATCH ?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH signifie que votre navigateur et le site n'ont pas pu s'accorder sur la manière de chiffrer la connexion. Chrome affiche « Ce site ne peut pas fournir de connexion sécurisée » et « example.com utilise un protocole incompatible » ; dans les détails : « Le client et le serveur ne sont pas compatibles avec une version de protocole ou une méthode de chiffrement SSL commune. » Chromium la répertorie sous le code -113 (net_error_list.h).

Elle survient dès la toute première étape de la poignée de main TLS. Votre navigateur envoie les versions TLS et les suites de chiffrement qu'il gère ; le serveur doit en choisir une de chaque. Si le serveur n'a rien en commun avec cette liste, répond avec une version que le navigateur n'accepte plus, ou refuse de continuer faute de certificat pour le nom demandé, la poignée de main s'arrête là.

Comme l'échec se produit avant toute vérification de certificat, un certificat expiré, au mauvais nom ou à la chaîne mal installée affiche une autre erreur (voir le tableau en fin d'article). Firefox affiche SSL_ERROR_NO_CYPHER_OVERLAP en cas de refus portant sur le chiffrement ou le certificat, et SSL_ERROR_UNSUPPORTED_VERSION pour un serveur limité à TLS 1.0/1.1.

À quoi ressemble l'erreur dans chaque navigateur

Tous les navigateurs Chromium (Chrome, Edge, Brave, Opera) affichent le même code. Repérez ces messages :

Quelles sont les causes de ERR_SSL_VERSION_OR_CIPHER_MISMATCH ?

Si l'erreur apparaît sur un seul site, la cause se trouve sur le serveur ou le CDN de ce site. Si elle apparaît sur de nombreux sites, quelque chose sur votre appareil ou votre réseau gêne. Les causes :

• Le serveur ne parle que TLS 1.0 ou 1.1. Chrome, Edge et Firefox ont commencé à bloquer ces deux versions en 2020 (Firefox 78, Chrome et Edge 84) ; depuis Chrome 98 (2022), il n'y a plus moyen de passer outre, et Chromium signale un tel serveur par cette erreur (net_error_list.h).
• Le serveur ne propose que d'anciens chiffrements, comme RC4, 3DES ou les suites de qualité export. Le code TLS de Chrome désactive complètement 3DES : un serveur qui n'offre rien d'autre est inaccessible.
• Aucun certificat pour le nom saisi (sur certains CDN). Chez Cloudflare et CloudFront, un nom d'hôte sans certificat voit sa poignée de main refusée dès la première étape. Chez Cloudflare, c'est la cause habituelle : le certificat est encore en cours d'activation, l'enregistrement n'est pas proxifié, un certificat personnalisé a expiré sans solution de repli, ou le nom est un sous-domaine à plusieurs niveaux (Cloudflare). Un simple serveur nginx ou Apache envoie à la place son certificat par défaut, ce qui provoque un avertissement de nom non concordant.
• Un intermédiaire — l'analyse HTTPS d'un antivirus, un proxy d'entreprise ou un VPN qui rechiffre votre trafic avec d'anciens paramètres TLS.
• Un appareil ou un navigateur très ancien — Windows XP, Android 4.x et les navigateurs non mis à jour depuis des années n'ont pas TLS 1.2 ni les chiffrements que les serveurs exigent désormais.

Nous l'avons testé : anciens serveurs TLS contre un client moderne

Pour montrer ce qui déclenche cette erreur, nous avons connecté un client TLS moderne (OpenSSL 3.6) aux serveurs de test publics de badssl.com le 27 octobre 2026. Les serveurs TLS 1.0 et 1.1 ont répondu avec une version que le client n'accepte plus ; les serveurs RC4 et 3DES ont refusé avec une alerte handshake_failure. Chrome affiche ERR_SSL_VERSION_OR_CIPHER_MISMATCH pour les quatre :

Ouvrez https://tls-v1-0.badssl.com:1010/ dans Chrome et vous verrez exactement cette page d'erreur. Si votre propre site se comporte comme les quatre premières lignes, les solutions pour propriétaires de sites ci-dessous s'appliquent.

Comment corriger ERR_SSL_VERSION_OR_CIPHER_MISMATCH (pour les utilisateurs)

Vous ne pouvez pas modifier le serveur d'un site : commencez donc par vérifier de qui vient le problème. Si un seul site échoue, passez aux solutions pour propriétaires de sites : seul le propriétaire peut le résoudre. Si de nombreux sites échouent, essayez ceci. (Désactiver QUIC, un vieux conseil, n'aide pas ici : les échecs QUIC affichent ERR_QUIC_PROTOCOL_ERROR.)

Correction 1 : vérifier si le problème vient du site

Ouvrez le même site sur un autre appareil ou en données mobiles. S'il échoue aussi, le serveur est en cause.

Pour une réponse sûre, passez le site dans le SSL Checker de DNS Robot : pour la plupart des serveurs, il liste les versions TLS acceptées, et pour un site chez Cloudflare il indique si un certificat a été émis pour ce nom. Un site qui n'accepte que TLS 1.0 ou 1.1 ne s'ouvre ni dans Chrome, ni dans Edge, ni dans Firefox, et il n'y a rien sur quoi cliquer pour passer outre : Chrome ne propose aucun lien pour continuer malgré cette erreur.

Correction 2 : mettre à jour votre navigateur et votre système d'exploitation

Les navigateurs et systèmes très anciens n'ont pas TLS 1.2, TLS 1.3 ni les chiffrements que les serveurs utilisent aujourd'hui. Mettez Chrome à jour sur chrome://settings/help et Edge sur edge://settings/help, puis mettez à jour le système d'exploitation.

Internet Explorer sous Windows XP et Vista, ainsi que le navigateur d'origine d'Android 4.0 à 4.3, n'ont pas TLS 1.2 avec les chiffrements actuels et échouent sur la plupart des sites HTTPS.

Correction 3 : vérifier l'analyse HTTPS de l'antivirus

Les antivirus qui analysent le HTTPS (Avast, Kaspersky, Bitdefender, ESET, Norton) s'interposent dans chaque connexion et établissent leur propre connexion TLS vers le site. Si leurs paramètres TLS sont obsolètes, les sites qui exigent un TLS moderne échouent.

Désactivez uniquement la partie d'analyse HTTPS, que chaque suite nomme différemment (analyse HTTPS du Web Shield d'Avast, filtrage du protocole SSL/TLS d'ESET, analyse du Web chiffré de Bitdefender, analyse des connexions chiffrées de Kaspersky), puis rechargez la page. Si l'erreur disparaît, mettez l'antivirus à jour ou ajoutez le site en exception plutôt que de laisser l'analyse désactivée.

Correction 4 : déconnecter un VPN ou un proxy

Les proxys d'entreprise, et les VPN dotés d'une fonction de protection web ou d'inspection HTTPS, établissent leur propre connexion TLS vers le site (un tunnel VPN ordinaire ne le fait pas). Déconnectez-vous et rechargez la page. Si le site fonctionne, désactivez cette fonction ou demandez au fournisseur (ou à votre service informatique) de mettre à jour ses paramètres TLS.

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

Si des visiteurs signalent cette erreur sur votre site, le serveur ou le CDN qui répond sur le port 443 n'arrive pas à s'accorder sur TLS avec les navigateurs modernes. Vérifiez-le avec le SSL Checker, puis :

Correction 1 : vérifier que chaque nom possède un certificat

Chez Cloudflare, CloudFront et d'autres CDN, un nom d'hôte sans certificat voit sa poignée de main refusée, et les navigateurs affichent cette erreur au lieu d'un avertissement de certificat. Un simple serveur nginx ou Apache envoie généralement son certificat par défaut (ERR_CERT_COMMON_NAME_INVALID) ou, avec ssl_reject_handshake de nginx, une alerte unrecognized_name (ERR_SSL_UNRECOGNIZED_NAME_ALERT). Vérifiez chaque nom utilisé par vos visiteurs : example.com, www.example.com et chaque sous-domaine.

Passez chaque nom dans le SSL Checker ou testez depuis un terminal (OpenSSL 1.1.1 ou plus récent ; si vous voyez « Could not find certificate », le serveur a refusé la poignée de main pour ce nom) :

# Does the server present a certificate for this exact name?
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Which TLS versions and ciphers does it accept?
nmap --script ssl-enum-ciphers -p 443 example.com

Correction 2 : activer TLS 1.2 et TLS 1.3

Tous les navigateurs actuels exigent au minimum TLS 1.2. Activez TLS 1.2 et TLS 1.3, et rien d'ancien :

# nginx (site config or nginx.conf)
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (ssl.conf)
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Then check the config and reload
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

Après le rechargement, testez à nouveau avec le SSL Checker ou Qualys SSL Labs pour confirmer que seuls TLS 1.2 et 1.3 sont proposés.

Correction 3 : proposer des suites de chiffrement modernes

Une fois TLS 1.2 activé, le serveur doit proposer un chiffrement que les navigateurs acceptent encore. Offrez ECDHE avec AES-GCM ou ChaCha20-Poly1305 (la sélection de Mozilla) ; les chiffrements RC4, 3DES, export et NULL sont refusés.

# nginx (TLS 1.2 ciphers; TLS 1.3 ciphers are always on)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

# Apache
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

Correction 4 : solutions spécifiques à Cloudflare

Le guide de Cloudflare sur cette erreur indique qu'elle se produit lorsque le nom d'hôte n'est couvert par aucun certificat (Cloudflare). Vérifiez, dans l'ordre :

• Le certificat est-il actif ? Un nouveau domaine reçoit son certificat Universal SSL en 15 minutes à 24 heures. Consultez SSL/TLS → Edge Certificates : il doit indiquer Active.
• L'enregistrement DNS est-il proxifié ? Le certificat n'est présenté que pour les enregistrements proxifiés (nuage orange). Un DNS Lookup d'un nom proxifié renvoie les adresses de Cloudflare, pas celles de votre serveur.
• Un certificat personnalisé a-t-il expiré ? Cloudflare le supprime après expiration ; si aucun autre certificat actif (comme Universal SSL) ne couvre le nom, les visiteurs obtiennent cette erreur au lieu d'un avertissement de certificat.
• S'agit-il d'un sous-domaine à plusieurs niveaux ? Dans une configuration complète, Universal SSL ne couvre que example.com et *.example.com, pas test.dev.example.com. Utilisez un certificat Advanced ou personnalisé, ou Total TLS (qui nécessite Advanced Certificate Manager).

Correction 5 : vérifier les autres CDN et répartiteurs de charge

Si un CDN ou un répartiteur de charge (CloudFront, Fastly, Akamai, répartiteur d'un cloud) termine la connexion TLS, ce sont ses paramètres qui comptent, pas ceux de votre serveur :

• Un certificat pour chaque nom d'hôte, rattaché à la bonne distribution ou au bon listener
• TLS 1.2 au minimum dans sa politique de sécurité, avec des chiffrements modernes
• La prise en charge de SNI si plusieurs domaines partagent une même adresse IP

Comment tester votre configuration SSL

Après vos modifications, vérifiez que votre configuration SSL est correcte. Ces outils vous aident à repérer les problèmes avant vos visiteurs.

• SSL Checker de DNS Robot — Vérification rapide de l'état du certificat, de son expiration, de la complétude de la chaîne et de l'émetteur. Résultats en quelques secondes.
• Qualys SSL Labs — Analyse approfondie des versions TLS, des suites de chiffrement, de la prise en charge des protocoles et des vulnérabilités connues. Attribue une note (visez A ou A+).
• OpenSSL en ligne de commande — Testez depuis le terminal avec openssl s_client -connect domain.com:443 pour voir la poignée de main brute, la chaîne de certificats et le chiffrement négocié.
• Chrome DevTools — sur une page qui se charge, le panneau Sécurité (ou « Privacy and security ») affiche la version TLS et le chiffrement utilisés.

# Quick check: protocol, cipher and certificate in a few lines
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief </dev/null

# Does it accept TLS 1.2? TLS 1.3?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_2 -brief </dev/null
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -brief </dev/null

Erreurs SSL/TLS associées

Chrome affiche plusieurs erreurs TLS et de certificat, chacune issue d'une étape différente :

Les guides des erreurs voisines : ERR_SSL_PROTOCOL_ERROR, ERR_CERT_AUTHORITY_INVALID et Votre connexion n'est pas privée.