ERR_SSL_VERSION_OR_CIPHER_MISMATCH : causes et corrections

Ce que signifie ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Pendant un handshake TLS, le ClientHello du client liste chaque version TLS et suite de chiffrement qu'il est disposé à utiliser, et le serveur en choisit une dans cette liste qu'il supporte aussi. Cette erreur apparaît quand la liste du serveur et celle du client ne partagent rien du tout, le plus souvent parce que le serveur n'offre que d'anciennes options obsolètes (TLS 1.0, TLS 1.1, ou des chiffrements comme RC4 ou 3DES) que les navigateurs actuels refusent de négocier pour des raisons de sécurité. Les navigateurs modernes abandonnent le support de ces options plus anciennes depuis des années, donc un serveur qui n'a jamais mis à jour sa configuration TLS échoue de plus en plus de cette façon face à des visiteurs ordinaires et à jour.

Comment l'erreur apparaît

Chrome et Edge affichent « This page isn't working - example.com sent an invalid response » ou, plus précisément, « ERR_SSL_VERSION_OR_CIPHER_MISMATCH ». Firefox affiche généralement « Secure Connection Failed » avec le code SSL_ERROR_NO_CYPHER_OVERLAP, qui nomme directement le problème.

openssl s_client en forçant une version TLS spécifique montre exactement quelles versions le serveur accepte et rejette :

openssl s_client -connect example.com:443 -tls1_2
CONNECTED(00000003)
...
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Verify return code: 0 (ok)

openssl s_client -connect example.com:443 -tls1
CONNECTED(00000003)
140... error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

Une alerte « protocol version » ou « handshake failure » sur une version et une connexion propre sur une autre indique précisément quelles versions le serveur supporte. Le script SSL de nmap va plus loin et liste tous les chiffrements que le serveur offre en une fois :

nmap --script ssl-enum-ciphers -p 443 example.com
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_SHA - C
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - A

Ce qui provoque ERR_SSL_VERSION_OR_CIPHER_MISMATCH

• Le serveur n'offre que TLS 1.0 ou 1.1. Les principaux navigateurs ont abandonné le support par défaut de ces deux versions il y a des années ; un serveur qui n'a jamais mis à jour sa configuration ne partage plus aucun protocole commun avec un navigateur actuel.
• Le serveur n'offre que des chiffrements faibles ou obsolètes, comme RC4 ou 3DES, que les navigateurs refusent de négocier quelle que soit la version TLS offerte à côté.
• Une incompatibilité de certificat ou de SNI sur un hébergement partagé. Quand plusieurs sites partagent une seule adresse IP et que le serveur ne peut pas faire correspondre le nom d'hôte demandé (Server Name Indication) au bon certificat et à la bonne configuration de chiffrement, il peut faire échouer le handshake au lieu de se replier correctement.
• L'état Cloudflare « no SSL certificate for this hostname yet », qui apparaît quand un domaine a été ajouté à Cloudflare et que le DNS a été pointé là avant que l'émission du certificat ne se termine ; la bordure n'a encore rien de valide avec quoi négocier pour ce nom d'hôte.
• Un vieux système d'exploitation ou navigateur qui ne supporte lui-même que d'anciennes versions TLS ou chiffrements, tombant sur un serveur moderne qui les a (correctement) désactivés.

Comment savoir de qui vient la faute

Testez d'abord depuis un autre appareil ou un autre réseau ; si le site se charge là-bas, le propre système d'exploitation ou navigateur du visiteur est obsolète. S'il échoue partout, y compris depuis un navigateur actuel et entièrement à jour, la configuration TLS du serveur en est la cause. Une vérification SSL lancée depuis plusieurs emplacements rapporte les versions de protocole et chiffrements exacts que le serveur offre depuis chaque point d'observation en une seule passe, ce qui est plus rapide que de répéter les commandes openssl manuellement depuis différents réseaux.

Comment corriger ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Si vous êtes visiteur

1. Mettez à jour votre navigateur vers la dernière version ; cela résout immédiatement la variante côté client de l'incompatibilité.
2. Mettez à jour votre système d'exploitation, en particulier sur Windows 7 ou plus ancien, ou de très vieilles versions Android et iOS, où la bibliothèque TLS système elle-même peut être obsolète indépendamment du navigateur.
3. Essayez un autre appareil ou réseau pour confirmer si le problème vous suit ou reste avec le site.
4. Contactez le propriétaire du site si l'échec est constant partout où vous testez ; une configuration serveur obsolète doit être corrigée de ce côté-là, pas contournée depuis le navigateur.

Si vous gérez le site

1. Fixez explicitement des versions de protocole et des chiffrements modernes. Sur nginx :

   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_cipher off;

   Retirez entièrement TLS 1.0, TLS 1.1, et toute entrée de chiffrement RC4 ou 3DES plutôt que de simplement les déprioriser.
2. Si un client hérité a vraiment encore besoin de TLS 1.0 ou 1.1 (certains anciens terminaux de paiement ou appareils embarqués en ont besoin), servez-le depuis un nom d'hôte ou un écouteur séparé avec son propre risque accepté, plutôt que d'affaiblir la configuration du site principal pour chaque visiteur.
3. Vérifiez la configuration SNI sur un hébergement partagé ou un reverse proxy gérant plusieurs certificats, en confirmant que chaque bloc server_name correspond au bon certificat et que le proxy ne se replie pas sur un certificat par défaut qui offre un ensemble de chiffrements différent et incompatible.
4. Si vous utilisez Cloudflare et que cela vient juste de commencer après l'ajout du domaine, vérifiez SSL/TLS > Edge Certificates dans le tableau de bord pour le statut d'émission du certificat ; l'état « no SSL certificate for this hostname yet » se résout de lui-même une fois l'émission terminée, généralement en quelques minutes à quelques heures.
5. Rechargez après tout changement, et re-vérifiez : nginx -t && systemctl reload nginx, puis relancez les commandes nmap ou openssl ci-dessus pour confirmer que les anciennes versions et chiffrements ont réellement disparu, pas seulement reclassés.

Erreurs associées

• ERR_SSL_PROTOCOL_ERROR est l'échec de handshake plus large et moins spécifique : une réponse non-TLS sur le port, des données de handshake mal formées, ou un logiciel d'interception, plutôt qu'une comparaison propre de version/chiffrement qui n'a simplement trouvé aucun recoupement.
• ERR_CERT_DATE_INVALID se produit après qu'un certificat a été réellement reçu et lu, une étape plus tard que cette erreur, qui ne va jamais aussi loin.

Comment prévenir ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Les éditeurs de navigateurs retirent périodiquement le support d'anciennes versions TLS et de chiffrements selon leur propre calendrier, ce qui signifie qu'une configuration serveur qui fonctionnait bien l'année dernière peut commencer à échouer pour une part croissante de visiteurs sans aucun changement côté serveur. Une vérification de certificat et SSL rapporte le protocole et le chiffrement négociés à chaque exécution, depuis plus de 300 points de contrôle dans 158 villes, détectant un serveur qui a dérivé vers une configuration obsolète avant que cela n'affecte du vrai trafic. HostTracker alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus dès qu'une vérification échoue.

Questions fréquentes

Est-ce la même chose qu'une erreur de certificat expiré ?

Non. Cette erreur se produit pendant la négociation du protocole et du chiffrement, avant même que le certificat lui-même ne soit évalué. Un certificat expiré serait une erreur distincte qui se produit une étape plus tard dans le handshake.

Pourquoi cela n'affecte-t-il que les visiteurs sur de vieux ordinateurs ?

Parce qu'un système d'exploitation ou un navigateur obsolète peut ne supporter que TLS 1.0, TLS 1.1, ou d'anciens chiffrements, qu'un serveur moderne correctement durci n'offre plus, produisant une incompatibilité propre de version/chiffrement spécifique à ce client obsolète.

Devrais-je réactiver TLS 1.0 pour corriger cela pour les anciens visiteurs ?

Généralement non. TLS 1.0 et 1.1 ont des faiblesses connues et la plupart des navigateurs actuels ne les utiliseront de toute façon pas, donc les réactiver ajoute surtout un risque sans restaurer la compatibilité pour la majorité des visiteurs affectés, dont le vrai problème est un navigateur ou un système d'exploitation obsolète.

Que signifie précisément le message Cloudflare « no SSL certificate for this hostname yet » ?

Cela signifie que le DNS du domaine pointe déjà vers Cloudflare mais que l'émission du certificat pour ce nom d'hôte ne s'est pas terminée, donc il n'y a encore rien de valide à présenter par la bordure de Cloudflare pendant le handshake. Cela se résout généralement de soi-même une fois l'émission terminée.

Comment savoir quels chiffrements mon serveur offre actuellement sans deviner ?

Lancez nmap --script ssl-enum-ciphers -p 443 yourdomain.com, qui liste chaque version de protocole et chiffrement que le serveur accepte avec une note pour chacun, plutôt que de tester les versions une par une.