Sécurité et confidentialité

Diagnostic et correction de l'erreur ERR_SSL_PROTOCOL_ERROR pour les services auto-hébergés

Un guide technique explique les causes de l'erreur de protocole SSL de Chrome, proposant des étapes de dépannage pour les visiteurs et les administrateurs de serveurs confrontés à des échecs d'établissement de liaison TLS.

Baies de serveurs sous une coupole en verre avec des voyants d'avertissement ambre indiquant des problèmes SSL.
Illustration créée pour cet article

Traduit automatiquement depuis l’original en anglais.

Lorsqu'un navigateur affiche ERR_SSL_PROTOCOL_ERROR, la connexion sécurisée échoue avant tout transfert de données. Cet article de DEV Community, publié le 28 octobre 2026, détaille pourquoi cet échec d'établissement de liaison se produit et fournit des mesures correctives spécifiques pour les utilisateurs finaux comme pour les administrateurs système gérant leur propre infrastructure.

Ce qui s'est passé

L'auteur, Romail Shah, explique que HTTPS repose sur un processus de négociation strict où le client et le serveur s'accordent sur une version TLS et une suite de chiffrement avant d'échanger du contenu. Lorsque cette négociation échoue, Chrome renvoie le code d'erreur -107, indiquant une réponse invalide. L'article distingue cette erreur de ERR_SSL_VERSION_OR_CIPHER_MISMATCH, qui pointe généralement vers des configurations serveur obsolètes, tandis que l'erreur de protocole provient souvent de certificats mal configurés ou d'une interférence réseau.

Pour les propriétaires de sites, le guide identifie cinq causes principales de ces échecs. Celles-ci incluent des certificats manquants après des migrations de serveur, des serveurs configurés pour ne prendre en charge que des versions TLS dépréciées comme 1.0 ou 1.1, des pare-feu bloquant le port 443, des modes de chiffrement Cloudflare incorrects ou des chaînes de certificats incomplètes. Le texte souligne que les certificats ne sont pas automatiquement transférés avec les fichiers du site lors d'une migration, une négligence courante qui laisse les nouveaux serveurs sans identifiants valides pour leurs noms d'hôte.

Détails clés

  • Chrome définit ERR_SSL_PROTOCOL_ERROR comme l'erreur -107, signifiant que le serveur a envoyé une réponse invalide lors de l'établissement de liaison TLS.
  • Les visiteurs doivent d'abord vérifier l'horloge de leur système, désactiver l'analyse HTTPS de leur antivirus et tester différents réseaux pour écarter les problèmes locaux.
  • Les administrateurs de serveurs doivent s'assurer que leur configuration prend en charge TLS 1.2 et 1.3, car la RFC 8996 impose l'abandon des protocoles plus anciens.
  • Des certificats intermédiaires manquants dans la chaîne peuvent provoquer des échecs intermittents, nécessitant la présence de la chaîne complète dans le fichier de configuration du serveur.
  • Les utilisateurs de Cloudflare doivent faire correspondre leur mode SSL (Full, Full Strict ou Flexible) aux capacités réelles de leur serveur d'origine pour éviter les erreurs d'établissement de liaison.
  • La commande openssl s_client -connect example.com:443 -servername example.com permet de vérifier quel certificat le serveur présente réellement aux clients.

Contexte

Secure Sockets Layer (SSL) et son successeur, Transport Layer Security (TLS), chiffrent les communications entre les navigateurs et les serveurs. L'établissement de liaison est la phase initiale où les deux parties s'authentifient mutuellement et établissent les clés de chiffrement. Server Name Indication (SNI) permet à plusieurs sites web dotés de certificats différents de résider sur une seule adresse IP en spécifiant le nom d'hôte lors de l'établissement de liaison. Si le serveur ne dispose pas d'un certificat correspondant à ce nom d'hôte, il peut présenter un certificat par défaut ou aucun, ce qui amène le navigateur à rejeter immédiatement la connexion.

Les autorités de certification délivrent des certificats numériques qui valident l'identité d'un serveur. Ces certificats ont des périodes de validité et doivent être chaînés correctement depuis le certificat feuille jusqu'à une autorité racine de confiance. Les navigateurs modernes appliquent des normes de sécurité strictes, rejetant les connexions utilisant des protocoles obsolètes ou des chaînes incomplètes. Comprendre ces mécanismes est essentiel pour toute personne exécutant des applications auto-hébergées, car les erreurs de configuration manuelle sont la cause la plus fréquente des temps d'arrêt.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés, les erreurs SSL représentent des risques immédiats pour la disponibilité. Contrairement aux bugs applicatifs qui pourraient dégrader les performances, un échec d'établissement de liaison TLS bloque tout accès au service. Cela est particulièrement critique lors des migrations ou des mises à jour d'infrastructure, où les modifications DNS et la provision de certificats doivent être synchronisées. Une incompatibilité ici peut rendre un service inaccessible pendant des heures tandis que les administrateurs diagnostiquent si le problème réside dans le réseau, la configuration du serveur web ou le certificat lui-même.

De plus, compter sur des proxys externes comme Cloudflare introduit une complexité supplémentaire. Si le mode de chiffrement entre le proxy et le serveur d'origine n'est pas aligné, les utilisateurs rencontrent des erreurs même si le serveur d'origine est techniquement fonctionnel. Les administrateurs doivent comprendre comment ces couches interagissent pour dépanner efficacement. Ignorer ces détails peut entraîner des pannes prolongées, surtout lorsque les processus de renouvellement automatique échouent silencieusement en raison de dérives de configuration ou de règles de pare-feu bloquant les défis de validation.

Ce que vous pouvez faire

  • Vérifiez la configuration TLS de votre serveur à l'aide d'OpenSSL pour vous assurer qu'il présente le bon certificat pour le nom d'hôte demandé.
  • Mettez à jour les configurations de votre serveur web pour activer explicitement TLS 1.2 et 1.3 tout en désactivant les versions de protocoles plus anciennes et non sécurisées.
  • Vérifiez que votre pare-feu autorise le trafic entrant sur le port 443 et que votre serveur web écoute activement sur ce port avec SSL activé.
  • Si vous utilisez un CDN ou un proxy, confirmez que le mode SSL correspond à la configuration de votre serveur d'origine, en testant directement contre l'IP d'origine si nécessaire.
  • Assurez-vous que votre chaîne de certificats inclut tous les certificats intermédiaires, ordonnés correctement avec le certificat feuille en premier, pour prévenir les échecs de validation chez certains clients.
  • Surveillez proactivement les dates d'expiration des certificats pour éviter les lacunes qui déclenchent des échecs d'établissement de liaison, surtout après avoir déplacé des services vers une nouvelle infrastructure.

Autres actualités

Toutes les actualités