« ERR_SSL_VERSION_OR_CIPHER_MISMATCH » : ce message, affiché côté navigateur, ne précise jamais quel protocole ou quelle suite de chiffrement pose problème. Il indique seulement que le client et le serveur n’ont trouvé aucun terrain d’entente commun pour établir une connexion chiffrée, ce qui laisse l’administrateur sans piste immédiate pour agir.
Ce symptôme apparaît typiquement après un durcissement de la configuration TLS d’un serveur, quand un administrateur retire les anciens protocoles TLS 1.0 et TLS 1.1 devenus obsolètes et jugés insuffisamment sûrs. Le problème survient alors uniquement pour les visiteurs équipés d’un poste ancien, dont le système d’exploitation ou le navigateur ne sait négocier que ces protocoles retirés.
Comprendre ce que le durcissement a changé
Une configuration Nginx durcie limite explicitement les protocoles acceptés à TLS 1.2 et TLS 1.3, en excluant volontairement les versions antérieures :
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
Cette configuration est saine et recommandée pour la grande majorité des visiteurs. Mais un poste équipé d’un système d’exploitation ancien, ou d’un navigateur qui n’a pas reçu de mise à jour depuis plusieurs années, peut ne savoir négocier que du TLS 1.0, protocole que ce serveur refuse désormais catégoriquement.
Simuler la connexion du poste client problématique
Plutôt que de deviner à distance ce que le poste du visiteur peut négocier, la commande openssl s_client permet de simuler précisément une tentative de connexion en forçant un protocole donné, reproduisant ainsi le comportement de l’ancien poste :
openssl s_client -connect exemple.fr:443 -tls1
Si le serveur répond par une erreur de type handshake failure, cela confirme que le protocole TLS 1.0 est bien refusé par la configuration actuelle. Répéter l’essai avec -tls1_1 puis -tls1_2 permet de cartographier précisément quels protocoles restent acceptés, et donc de confirmer sans ambiguïté l’origine du problème signalé.
Identifier le protocole réellement utilisé par le poste concerné
Quand l’accès physique au poste du visiteur est possible, ou via une capture réseau qu’il transmet, l’analyse du paquet Client Hello initial révèle exactement quels protocoles et quelles suites de chiffrement le poste propose. Cette information, croisée avec la configuration du serveur, permet de confirmer sans détour lequel des deux ne veut pas céder.
Dans la grande majorité des cas rencontrés, le poste en cause tourne sous une version ancienne de Windows dont le composant réseau système n’a jamais été mis à jour pour proposer TLS 1.2 par défaut, ou sous un navigateur qui n’a pas reçu de mise à jour de sécurité depuis plusieurs années.
Ce qu’il ne faut pas faire : rouvrir TLS 1.0
La tentation la plus immédiate face à ce blocage est de rouvrir TLS 1.0 côté serveur pour satisfaire ce visiteur précis. C’est rarement la bonne décision : rouvrir un protocole obsolète pour un cas isolé expose l’ensemble des visiteurs du site, y compris ceux dont la connexion aurait pu se faire correctement en TLS 1.2, à des attaques connues contre ce protocole ancien, comme celles exploitant sa faiblesse face au chiffrement par blocs.
Sur nos serveurs, nous préférons systématiquement orienter le visiteur concerné vers une mise à jour de son navigateur ou de son système, plutôt que d’affaiblir la configuration TLS pour l’ensemble des autres visiteurs.
Les alternatives à privilégier consistent à recommander explicitement au visiteur de mettre à jour son navigateur, ou, si le blocage concerne un usage professionnel critique, à isoler cet accès particulier via une passerelle dédiée qui accepte des protocoles anciens sans affaiblir le serveur principal pour tous les autres visiteurs.
Vérifier les autres visiteurs concernés
Avant de conclure qu’il s’agit d’un cas isolé, les journaux d’accès du serveur peuvent être analysés pour repérer d’éventuelles tentatives de connexion échouées provenant d’autres visiteurs, ce qui permet d’évaluer si le problème touche une poignée de personnes ou une part significative de l’audience du site.
- Confirmer le protocole refusé avec
openssl s_client - Analyser le
Client Hellodu poste concerné si possible - Vérifier l’ampleur du problème dans les journaux d’accès
- Privilégier la mise à jour du poste plutôt que l’affaiblissement du serveur
En résumé
« ERR_SSL_VERSION_OR_CIPHER_MISMATCH » signale une négociation TLS impossible, généralement causée par un poste ancien limité à un protocole retiré volontairement de la configuration du serveur. Le diagnostic via openssl s_client permet de confirmer précisément l’origine du blocage, sans qu’il soit nécessaire de rouvrir un protocole obsolète qui exposerait tous les autres visiteurs à des risques connus et documentés.
