Ce que signifie ERR_SSL_PROTOCOL_ERROR, et pourquoi il ne dit pas qui est en faute

Quelqu’un vous dit que votre site ne charge pas et vous envoie un code : ERR_SSL_PROTOCOL_ERROR. Chez vous il fonctionne. Chez tout le monde au bureau il fonctionne. La page que cette personne a devant les yeux est grise, contient deux phrases environ, et ne propose rien d’autre.

Voici la description que Chromium donne de cette erreur, dans le fichier où chaque erreur réseau de Chrome est définie :

An SSL protocol error occurred.

C’est tout le commentaire. Cinq mots, pour l’erreur numéro -107. Ce n’est pas une version abrégée de quelque chose de plus long ; c’est tout ce que le navigateur possède.

C’est le code que Chrome emploie quand il ne peut pas être plus précis

Ce qui rend cela important, c’est ce qui l’entoure dans la même liste.

Quelques lignes plus loin se trouve ERR_SSL_VERSION_OR_CIPHER_MISMATCH, le numéro -113, et sa description est précise : “The client and server don’t support a common SSL protocol version or cipher suite.” Plus loin encore vient toute une plage réservée aux certificats, où ERR_CERT_COMMON_NAME_INVALID, le numéro -200, porte quatre causes nommées, dont celle où la personne se trouve sur un réseau sans fil et est redirigée vers la page de connexion du réseau.

Chrome a donc des codes plus précis pour les échecs qu’il sait attribuer. Recevoir -107 à la place signifie que le handshake a échoué d’une manière à laquelle le navigateur n’a pas su donner de nom.

C’est l’inverse de la façon dont cette erreur est traitée d’habitude. Chaque guide à son sujet est une liste de huit choses à essayer, et la longueur de la liste est l’indice : personne qui en écrit une ne sait laquelle des huit s’applique, parce que l’erreur ne le dit pas.

Ce qui échoue réellement, et le peu qui vous appartient

La page de dépannage de Cloudflare consacrée à cette erreur énumère ce qu’ils voient derrière. Leur résumé est que le handshake a échoué, et les raisons qu’ils nomment sont :

• Un problème de certificat, par exemple un certificat qui n’est pas encore actif, ou un sous-domaine à plusieurs niveaux que le certificat en place ne couvre pas.
• Une suite de chiffrement qui ne correspond pas, où, selon leurs mots, les clients anciens peuvent ne pas prendre en charge les suites modernes.
• HTTP/3 et QUIC bloqués, par un réseau, un pare-feu ou un équipement qui ne transporte pas QUIC sur UDP.
• TLS 1.3 pas entièrement pris en charge par des équipements de sécurité réseau qui font de l’inspection SSL.
• Des interférences réseau : inspection profonde de paquets, proxys qui interceptent, contrôles parentaux, NAT d’opérateur.

C’est le point de vue d’un CDN depuis sa propre file de support et non une taxonomie complète, et cela reste la liste la plus utile disponible, à cause de la façon dont elle se répartit.

Comptez à qui appartient chaque entrée. La première est à vous. La deuxième appartient au navigateur ou au système d’exploitation de la personne qui signale. La troisième, la quatrième et la cinquième appartiennent à des équipements et à des logiciels situés entre elle et vous : son routeur, l’appliance d’inspection de son entreprise, son antivirus, son fournisseur d’accès.

Une sur cinq est de votre côté, et le texte de l’erreur est identique pour toutes.

Et c’est pourquoi le signalement arrive inutilisable

“Votre site est cassé, ERR_SSL_PROTOCOL_ERROR” est une description complète de ce que cette personne peut voir et ne vous apprend presque rien. La question évidente qui suit, savoir si elle est seule concernée, est justement celle à laquelle vous ne pouvez pas répondre de là où vous êtes : votre machine est sur un autre réseau, derrière un autre matériel, avec un autre logiciel de sécurité, et négocie peut-être avec un autre nœud de bordure.

C’est le même problème que distinguer votre bug de la panne d’un autre, et il a la même propriété : la preuve qui trancherait n’existe que sur leur machine, et seulement pendant que cela se produit.

Ce n’est pas l’avertissement de certificat, et l’écart est grand

Si la personne décrit une page rouge l’avertissant que la connexion n’est pas privée, avec un code commençant par ERR_CERT_, c’est une autre erreur et bien plus maniable : ces codes énoncent leur raison, et laquelle des cinq c’est se règle en une minute.

ERR_SSL_PROTOCOL_ERROR n’a ni cette page ni cette raison. Il vaut la peine d’établir laquelle des deux elle a réellement vue avant de passer un après-midi sur la mauvaise, et le plus rapide est de demander la capture plutôt que la description.

Les deux tests qui partagent le terrain

La page de Cloudflare termine son propre conseil en disant de recueillir des données de diagnostic auprès des visiteurs touchés, ce qui est la forme honnête de la réponse. Avant cela, deux choses qu’une personne qui signale peut faire en une minute resserrent le champ plus que tout ce que vous pouvez exécuter vous-même.

Demandez-lui d’essayer en données mobiles, le wifi coupé. Si la page charge, le problème se situe entre son réseau et vous, et aucun changement sur votre serveur ne le réglera pour elle. Si cela échoue encore, son réseau n’est pas la cause.

Demandez-lui d’essayer un autre navigateur sur la même machine. Si la page charge là, la cause est son navigateur : sa prise en charge des protocoles, son propre magasin de certificats, ou une extension placée devant. Si cela échoue dans les deux, la machine ou son réseau est en cause, et non le navigateur.

Ces deux réponses couvrent ensemble quatre des cinq causes ci-dessus et coûtent à cette personne environ quatre-vingt-dix secondes. Ce que vous voulez noté à côté : l’URL complète, si http ou https a été saisi, le code exact, l’heure, et si autre chose tombait en panne à la même minute.

Le cas qui est le vôtre et ressemble au leur

Un schéma mérite d’être connu parce qu’il produit exactement cette erreur de votre côté tout en ressemblant à un problème côté client. Un certificat valide mais pas encore actif, parce que sa date de début est dans le futur, fait échouer le handshake au lieu de produire une page d’avertissement, et il échoue pour tous ceux dont l’horloge est juste. Il en va de même pour un hôte situé un niveau plus bas que ce que couvre le certificat : app.eu.example.com face à un certificat émis pour *.example.com n’est pas couvert, car un joker unique correspond à une étiquette.

Ces deux cas sont de votre ressort, tous deux arrivent sous cette erreur, et aucun ne se distingue d’un problème d’équipement intermédiaire sans vérifier le certificat que votre bordure sert vraiment.

Ce qu’il faut en retenir

ERR_SSL_PROTOCOL_ERROR n’est pas un diagnostic. C’est son absence, et Chromium le dit exactement en cinq mots. Prenez-le comme le navigateur vous disant qu’un handshake a échoué et qu’il n’a pas pu trouver pourquoi, puis mettez votre effort dans les deux questions qui répartissent les causes, plutôt que dans la liste de huit correctifs dont sept n’allaient de toute façon jamais s’appliquer.