Chrome 66 : corrections d’erreurs SSL

Chrome 66 a introduit des contrôles SSL/TLS nettement plus stricts, transformant des configurations serveur autrefois tolérées en erreurs bloquantes pour des millions d’utilisateurs. Comprendre ce que ce changement implique concrètement, identifier la cause réelle d’une erreur en quelques vérifications ciblées et appliquer la bonne correction — côté navigateur ou côté serveur — évite de perdre du temps sur des pistes sans issue.

Ce que Chrome 66 a changé et pourquoi des erreurs SSL apparaissent

Lorsque Google a déployé Chrome 66 au printemps 2018, la mise à jour n’a pas modifié l’interface du navigateur de façon spectaculaire. Elle a en revanche durci silencieusement les règles d’acceptation des connexions HTTPS, en refusant des configurations TLS qui étaient jusqu’alors tolérées. Pour comprendre pourquoi des erreurs SSL ont soudainement émergé, il faut revenir sur ce que fait réellement TLS lors d’une connexion.

TLS (Transport Layer Security) est le protocole qui sécurise les échanges entre un navigateur et un serveur web. Lors de chaque connexion HTTPS, un handshake s’effectue : le serveur présente son certificat, le navigateur vérifie l’identité de l’autorité de certification qui l’a signé, puis les deux parties négocient une suite de chiffrement compatible. Si l’une de ces étapes échoue, la connexion est bloquée et un code d’erreur s’affiche.

Chrome 66 a introduit plusieurs ruptures importantes dans cette chaîne :

• Abandon des certificats Symantec : Chrome 66 a commencé à rejeter les certificats émis par l’infrastructure Symantec avant une certaine date, considérés comme non conformes aux exigences de transparence des certificats (Certificate Transparency). Des sites correctement configurés se sont retrouvés bloqués du jour au lendemain.
• Renforcement des contrôles sur TLS 1.0 et TLS 1.1 : ces versions, publiées respectivement en 1999 et 2006, présentent des vulnérabilités connues (POODLE, BEAST). Chrome 66 a commencé à afficher des avertissements pour les connexions qui s’appuyaient encore sur ces protocoles, avant de les bloquer dans les versions suivantes.
• Exigences strictes sur les suites de chiffrement : certaines suites jugées faibles ou obsolètes ont été retirées de la liste des algorithmes acceptés par le navigateur, provoquant des erreurs ERR_SSL_VERSION_OR_CIPHER_MISMATCH sur des serveurs qui ne proposaient que ces algorithmes.

Ce que Chrome 66 a rendu visible, c’est donc moins un bug qu’une incompatibilité préexistante. Un serveur configuré avec TLS 1.0 uniquement fonctionnait encore avec Chrome 65 parce que le navigateur acceptait de négocier vers le bas. Chrome 66 a refusé cette négociation dégradée. L’erreur « erreur SSL version » signifie précisément cela : le navigateur et le serveur n’ont pas trouvé de version de protocole ou de suite de chiffrement commune acceptable selon les critères actuels.

SSL/TLS est présenté comme un protocole indispensable pour sécuriser les échanges sur le web, fondé sur HTTP, avec échange de certificats et chiffrement des flux de données. Quand Chrome durcit ses critères, il ne crée pas le problème — il le révèle. Cette distinction est essentielle pour orienter le diagnostic dans la bonne direction.

Cartographier précisément les codes d’erreur que Chrome affiche est la prochaine étape logique : chaque code correspond à une famille de causes, et confondre ERR_SSL_PROTOCOL_ERROR avec NET::ERR_CERT_DATE_INVALID conduit à des corrections inutiles.

Reconnaître les principaux codes d’erreur SSL dans Chrome

Chrome ne se contente pas d’afficher un message générique « connexion non sécurisée ». Il produit des codes d’erreur précis, chacun pointant vers une catégorie de problème distincte. Savoir lire ces codes évite de chercher une solution au mauvais endroit.

ERR_SSL_PROTOCOL_ERROR

Ce code signale que l’établissement d’une connexion HTTPS sécurisée a échoué à cause d’un problème empêchant l’échange de certificat SSL/TLS requis. Le message affiché par Chrome est explicite : « Impossible d’établir une connexion sécurisée avec le serveur. Le serveur a peut-être rencontré un problème ou exige un certificat d’authentification du client dont vous ne disposez pas. »

L’origine peut être côté serveur ou côté client. Côté serveur, les causes typiques incluent une configuration TLS corrompue, un certificat mal installé ou un serveur qui ne répond pas correctement au handshake. Côté client, un antivirus qui intercepte les connexions HTTPS, un proxy mal configuré ou une version de Chrome obsolète peuvent provoquer exactement le même code.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Ce code est plus spécifique : il indique que le navigateur et le serveur n’ont pas trouvé de version de protocole ou de suite de chiffrement commune. C’est l’erreur directement liée aux changements de Chrome 66. Elle apparaît typiquement dans ces situations :

• Le serveur ne supporte que TLS 1.0 ou TLS 1.1, versions que Chrome refuse désormais.
• Le serveur propose uniquement des suites de chiffrement jugées faibles (RC4, DES, export-grade).
• Le certificat utilise une clé RSA inférieure à 2048 bits.
• Une incompatibilité de SNI (Server Name Indication) empêche le serveur de présenter le bon certificat lors d’un hébergement mutualisé.

NET::ERR_CERT_DATE_INVALID

Cette erreur signifie que le navigateur ne peut pas valider la période de validité du certificat SSL/TLS présenté par le serveur. La connexion est bloquée automatiquement. Contrairement à ce que l’on pourrait croire, cette erreur n’implique pas nécessairement qu’un site est compromis — elle indique qu’une vérification de confiance n’a pas pu être confirmée.

Les causes sont multiples et ne viennent pas toutes du serveur :

• Certificat expiré : les certificats Let’s Encrypt ont une durée de validité de 90 jours ; un renouvellement automatique mal configuré suffit à provoquer cette erreur.
• Chaîne intermédiaire manquante : si le serveur ne fournit pas les certificats intermédiaires de l’autorité de certification, Chrome ne peut pas remonter jusqu’à une racine de confiance.
• Horloge système incorrecte côté client : si la date système du poste utilisateur est décalée, Chrome considère le certificat comme expiré ou pas encore valide.
• Antivirus avec inspection HTTPS : certains antivirus substituent leur propre certificat pour inspecter le trafic chiffré ; si ce certificat n’est pas reconnu, Chrome bloque la connexion.

Depuis 2025, les exigences sur la signature et la transparence des certificats se sont renforcées, au point qu’un certificat techniquement valide peut être rejeté s’il ne respecte pas les nouvelles règles de Certificate Transparency. TLS 1.2 et TLS 1.3 constituent désormais la base du chiffrement web moderne ; tout serveur encore limité à TLS 1.0 ou 1.1 est exposé à des erreurs bloquantes dans Chrome.

Cette cartographie posée, la logique de diagnostic impose de commencer par les vérifications côté utilisateur, car elles sont rapides, gratuites et résolvent une proportion non négligeable des cas sans nécessiter d’intervention sur le serveur.

Diagnostic express côté utilisateur : les vérifications qui résolvent le plus souvent

Avant de contacter l’hébergeur ou de modifier la configuration serveur, plusieurs vérifications côté client peuvent résoudre l’erreur en quelques minutes. L’ordre proposé ici suit une logique de probabilité décroissante : commencer par ce qui provoque le plus souvent le problème.

1. Vérifier l’horloge système

Une horloge système décalée est l’une des causes les plus fréquentes de NET::ERR_CERT_DATE_INVALID, et l’une des plus facilement oubliées. Chrome utilise la date et l’heure locales pour vérifier la période de validité du certificat. Si l’horloge affiche une date antérieure à l’émission du certificat ou postérieure à son expiration, la connexion est bloquée.

• Sur Windows : clic droit sur l’horloge → « Ajuster la date/l’heure » → activer « Définir l’heure automatiquement ».
• Sur macOS : Préférences Système → Date et heure → cocher « Régler la date et l’heure automatiquement ».
• Sur Android : Paramètres → Gestion générale → Date et heure → activer la date et l’heure automatiques.

2. Mettre à jour Google Chrome

Une version obsolète de Chrome peut manquer des mises à jour de la liste des autorités de certification de confiance, ou présenter des bugs dans la gestion du HSTS (HTTP Strict Transport Security). La mise à jour se fait via le menu → Aide → À propos de Google Chrome. Chrome vérifie et installe automatiquement les mises à jour disponibles.

3. Désactiver temporairement le proxy ou le VPN

Un proxy d’entreprise ou un VPN peut intercepter les connexions HTTPS et présenter son propre certificat. Si ce certificat n’est pas reconnu par Chrome, l’erreur ERR_SSL_PROTOCOL_ERROR apparaît. Désactiver temporairement le proxy ou le VPN permet de confirmer ou d’infirmer cette hypothèse en quelques secondes.

4. Désactiver l’inspection HTTPS de l’antivirus

Les antivirus modernes (Kaspersky, Avast, ESET, Bitdefender…) intègrent une fonction d’inspection du trafic HTTPS. Pour analyser le contenu chiffré, ils substituent leur propre certificat racine. Si ce certificat n’est pas correctement installé dans le magasin de certificats du système, Chrome le rejette. La procédure de désactivation varie selon l’éditeur, mais se trouve généralement dans les paramètres « Protection web » ou « Bouclier web » de l’antivirus.

5. Tester en navigation privée et désactiver les extensions

Certaines extensions Chrome modifient les requêtes réseau et peuvent interférer avec le handshake TLS. Ouvrir une fenêtre de navigation privée (Ctrl+Maj+N) désactive les extensions par défaut. Si l’erreur disparaît en navigation privée, l’isolation de l’extension responsable se fait en les désactivant une par une.

6. Tester sur un autre réseau

Un pare-feu d’entreprise ou un routeur domestique avec des règles de filtrage peut bloquer certaines connexions TLS. Tester depuis un réseau mobile (en désactivant le Wi-Fi) ou depuis un autre réseau permet de confirmer si le problème est lié à l’infrastructure réseau locale.

Ces vérifications côté client ne règlent pas les problèmes d’origine serveur, mais elles évitent de mobiliser inutilement un développeur ou un hébergeur. Quand elles ne suffisent pas, une étape intermédiaire reste souvent négligée : purger l’état SSL et les certificats dans Chrome, une opération distincte du simple vidage du cache navigateur.

Effacer l’état SSL et les certificats : quand et comment le faire dans Chrome

Il existe une confusion fréquente entre trois choses distinctes : le cache navigateur, le cache SSL (ou état SSL) et les certificats stockés dans le magasin du système d’exploitation. Ces trois éléments se gèrent différemment et répondent à des problèmes différents.

Le cache navigateur stocke les ressources statiques (images, scripts, feuilles de style). Le vider n’a aucun effet sur les erreurs SSL. L’état SSL, lui, conserve les résultats de négociations TLS passées et les informations OCSP (validation de révocation des certificats via l’OCSP stapling). Si Chrome a mémorisé une session avec un certificat désormais invalide ou révoqué, purger l’état SSL force une renégociation complète. Les certificats stockés dans le magasin système sont les certificats racines et intermédiaires des autorités de certification, ainsi que les certificats ajoutés manuellement (notamment par des antivirus ou des proxys d’entreprise).

Purger l’état SSL dans Chrome

Chrome ne propose pas de bouton direct pour purger l’état SSL depuis son interface. L’opération se fait via les paramètres réseau du système d’exploitation :

• Windows : Panneau de configuration → Options Internet → onglet « Contenu » → bouton « Effacer l’état SSL ». Cette action purge le cache de sessions TLS partagé entre Internet Explorer, Edge (legacy) et Chrome.
• macOS : l’état SSL est géré différemment ; redémarrer Chrome ou vider le cache DNS (sudo dscacheutil -flushcache) produit un effet similaire.

Gérer les certificats problématiques

Si un certificat d’antivirus ou de proxy est la source du problème, il peut être nécessaire de le localiser et de le supprimer du magasin de certificats :

• Windows : taper certmgr.msc dans la barre de recherche pour ouvrir le gestionnaire de certificats. Les certificats suspects se trouvent généralement dans « Autorités de certification racines de confiance ». Attention : supprimer un certificat racine légitime peut bloquer d’autres connexions.
• macOS : ouvrir le Trousseau d’accès (Applications → Utilitaires), sélectionner « Système » ou « Racines système », identifier le certificat problématique et le supprimer ou le marquer comme non approuvé.
• Chrome (paramètres internes) : chrome://settings/security → « Gérer les certificats » renvoie vers le gestionnaire de certificats du système.

Précaution importante : ne supprimer que les certificats clairement identifiés comme problématiques (certificat d’un antivirus désinstallé, certificat d’un proxy d’entreprise non utilisé). Supprimer un certificat racine d’une autorité de certification reconnue (Let’s Encrypt, Sectigo, DigiCert) rendrait de nombreux sites inaccessibles.

Ces opérations côté client couvrent les cas où le problème vient de l’environnement de l’utilisateur. Quand l’erreur persiste après ces vérifications, et qu’elle est reproductible sur plusieurs appareils et réseaux différents, la cause se trouve côté serveur.

Côté site : les causes fréquentes d’incompatibilité avec Chrome 66

Un site qui déclenche des erreurs SSL dans Chrome sur plusieurs appareils et réseaux différents présente presque certainement un problème de configuration serveur. Les causes sont souvent cumulatives : un serveur peut simultanément avoir un certificat expiré, une chaîne incomplète et des versions TLS obsolètes.

Versions TLS obsolètes

TLS 1.0 et TLS 1.1 sont officiellement dépréciés. Chrome 66 a commencé à signaler leur usage, et les versions ultérieures les ont définitivement bloqués. Un serveur qui n’accepte pas TLS 1.2 (et idéalement TLS 1.3) provoque systématiquement une erreur ERR_SSL_VERSION_OR_CIPHER_MISMATCH dans les navigateurs modernes.

Certificat expiré

La durée de validité des certificats est limitée : 90 jours pour les certificats Let’s Encrypt, un an pour la plupart des certificats commerciaux. Un certificat non renouvelé à temps déclenche immédiatement NET::ERR_CERT_DATE_INVALID. C’est l’une des causes les plus fréquentes et les plus évitables d’erreur SSL.

Chaîne de certificats incomplète

Un certificat SSL n’est pas seul : il s’inscrit dans une chaîne de certificats qui remonte jusqu’à une autorité de certification racine reconnue par les navigateurs. Si le serveur ne fournit pas les certificats intermédiaires, Chrome ne peut pas valider la chaîne de confiance, même si le certificat final est valide. Cette erreur est particulièrement insidieuse car elle fonctionne parfois sur certains navigateurs (qui ont mis en cache les intermédiaires) mais pas sur d’autres.

Mauvaise configuration SNI

SNI (Server Name Indication) permet à un serveur d’héberger plusieurs sites HTTPS sur une même adresse IP en présentant le bon certificat selon le nom de domaine demandé. Une configuration SNI incorrecte entraîne la présentation d’un certificat ne correspondant pas au domaine demandé, provoquant une erreur de certificat dans Chrome.

Contenu mixte

Une page chargée en HTTPS qui inclut des ressources (images, scripts, iframes) en HTTP constitue du contenu mixte. Chrome bloque le contenu mixte actif (scripts, iframes) et affiche des avertissements pour le contenu mixte passif (images). Ce problème survient fréquemment lors de la migration d’un site de HTTP vers HTTPS sans mise à jour complète des URLs internes.

HSTS mal configuré

HSTS (HTTP Strict Transport Security) est un en-tête qui force le navigateur à toujours utiliser HTTPS pour un domaine donné. Une fois mémorisé par Chrome, cet en-tête ne peut pas être contourné par l’utilisateur. Si un site configure HSTS puis revient à HTTP ou change de certificat sans respecter les conditions, Chrome bloque l’accès de manière persistante, même après correction du problème initial.

Suites de chiffrement obsolètes

Certains serveurs anciens proposent uniquement des suites de chiffrement jugées faibles par Chrome 66 : RC4, DES, 3DES, ou des suites d’exportation. Chrome refuse de négocier avec ces algorithmes, produisant une erreur ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Identifier laquelle de ces causes est active sur un site donné nécessite des outils de test appropriés — mais surtout, un ordre de correction logique pour ne pas multiplier les interventions inutiles.

Correctifs prioritaires sur le serveur : TLS, certificat et chaîne de confiance

Une fois la cause identifiée côté serveur, l’ordre des corrections importe autant que les corrections elles-mêmes. Agir dans le désordre peut masquer temporairement un problème sans le résoudre, ou créer de nouvelles incompatibilités.

Étape 1 : Renouveler et installer correctement le certificat

Si le certificat est expiré, le renouvellement est la priorité absolue. Pour un certificat Let’s Encrypt, la commande certbot renew suffit si l’automatisation est en place. Pour un certificat commercial, la procédure de renouvellement dépend de l’autorité de certification (Sectigo, DigiCert, etc.). L’installation doit inclure le certificat du domaine et les certificats intermédiaires dans le bon ordre.

Pour vérifier que la chaîne est complète après installation, des outils comme SSL Labs permettent d’analyser la configuration TLS d’un serveur et d’identifier les maillons manquants dans la chaîne de certification.

Étape 2 : Activer TLS 1.2 et TLS 1.3

La configuration dépend du serveur web utilisé :

• Apache : dans ssl.conf ou le VirtualHost, modifier la directive SSLProtocol pour inclure TLSv1.2 TLSv1.3 et exclure explicitement SSLv3 TLSv1 TLSv1.1.
• Nginx : modifier ssl_protocols TLSv1.2 TLSv1.3; dans le bloc server.
• IIS (Windows Server) : utiliser l’outil IIS Crypto ou modifier le registre Windows pour désactiver TLS 1.0 et 1.1.

Étape 3 : Corriger les suites de chiffrement

Les suites recommandées pour TLS 1.2 incluent les variantes AES-GCM avec ECDHE (Perfect Forward Secrecy). Pour TLS 1.3, les suites sont standardisées et n’ont pas besoin d’être configurées manuellement sur les serveurs modernes. L’outil Mozilla SSL Configuration Generator produit des configurations prêtes à l’emploi pour Apache, Nginx et HAProxy, adaptées au niveau de compatibilité souhaité.

Étape 4 : Vérifier la configuration SNI et le load balancer/CDN

Si le site passe par un CDN ou un load balancer, la terminaison TLS peut se faire à ce niveau. Il faut s’assurer que le certificat est correctement configuré sur le CDN, que le SNI est activé, et que les certificats intermédiaires sont bien fournis. Un CDN qui présente un certificat générique pour un sous-domaine non couvert peut provoquer des erreurs dans Chrome.

Étape 5 : Tester après chaque correction

Après chaque modification, tester depuis un appareil externe (ou en mode navigation privée pour éviter le cache) est indispensable. Un test via SSL Labs fournit un rapport détaillé incluant la version TLS négociée, les suites de chiffrement proposées, la complétude de la chaîne et la présence de l’OCSP stapling.

Ces corrections résolvent les erreurs existantes. Mais une configuration saine aujourd’hui peut devenir problématique demain si aucune surveillance n’est en place — notamment lors des prochaines mises à jour de Chrome ou d’autres navigateurs.

Prévenir les erreurs SSL lors des mises à jour : surveillance et bonnes pratiques

Les erreurs SSL ne surviennent pas uniquement lors de la mise en production initiale d’un site. Elles apparaissent aussi lors de mises à jour de navigateurs (comme Chrome 66), de changements d’hébergeur, de migrations CDN ou simplement parce qu’un certificat a expiré sans que personne ne l’ait remarqué. Une stratégie de prévention repose sur trois piliers : la surveillance, les tests automatiques et la documentation.

Monitoring d’expiration des certificats

Les certificats Let’s Encrypt expirent tous les 90 jours. Même avec un renouvellement automatique, une défaillance du processus (erreur de configuration, changement d’hébergeur, problème de permissions) peut passer inaperçue. Des outils de monitoring envoient des alertes par e-mail ou SMS lorsqu’un certificat approche de son expiration (typiquement à 30, 14 et 7 jours). Certains services de monitoring proposent également de vérifier en continu la validité de la chaîne de certification et la disponibilité de l’OCSP stapling.

Tests automatiques de configuration TLS

Intégrer un test de configuration TLS dans le pipeline de déploiement permet de détecter une régression avant qu’elle n’affecte les utilisateurs. Des outils en ligne de commande comme testssl.sh peuvent être exécutés automatiquement après chaque déploiement pour vérifier les versions TLS supportées, les suites de chiffrement actives et la complétude de la chaîne.

Politique de déploiement et gestion des changements

Tout changement d’hébergeur, de CDN ou de configuration serveur doit inclure une vérification explicite de la configuration SSL/TLS. Une checklist de déploiement doit couvrir :

• Installation complète du certificat et des intermédiaires.
• Activation de TLS 1.2 et TLS 1.3, désactivation de TLS 1.0 et 1.1.
• Vérification du SNI sur les hébergements mutualisés.
• Test de la configuration HSTS (valeur max-age, périmètre includeSubDomains).
• Vérification de l’absence de contenu mixte.

Documentation interne

Documenter l’autorité de certification utilisée, la date d’expiration du certificat, le processus de renouvellement et les contacts responsables évite les situations où un certificat expire parce que la personne qui gérait le renouvellement a quitté l’entreprise. Cette documentation doit être maintenue à jour à chaque changement de prestataire ou de configuration.

La surveillance proactive transforme la gestion SSL d’une réaction aux incidents en une maintenance planifiée. C’est la différence entre découvrir une erreur SSL quand un client se plaint et la corriger avant que quiconque ne la rencontre.

FAQ

Comment corriger l’erreur SSL sur Google Chrome ?

La correction dépend de l’origine. Côté utilisateur : vérifier l’horloge système, mettre à jour Chrome, désactiver le proxy ou l’antivirus avec inspection HTTPS, tester en navigation privée. Côté serveur : renouveler le certificat expiré, installer les certificats intermédiaires, activer TLS 1.2 et TLS 1.3, corriger les suites de chiffrement obsolètes et vérifier la configuration SNI.

Comment puis-je effacer l’état SSL dans Chrome ?

Sur Windows, l’état SSL se purge via le Panneau de configuration → Options Internet → onglet « Contenu » → bouton « Effacer l’état SSL ». Cette opération force Chrome à renégocier les sessions TLS sans s’appuyer sur les données mises en cache. Sur macOS, redémarrer Chrome ou vider le cache DNS produit un effet équivalent.

Que signifie l’erreur « erreur SSL version » ?

Elle correspond généralement au code ERR_SSL_VERSION_OR_CIPHER_MISMATCH : le navigateur et le serveur n’ont pas trouvé de version de protocole TLS ou de suite de chiffrement commune acceptable. Cela survient quand le serveur ne supporte que TLS 1.0 ou TLS 1.1 (désormais rejetés par Chrome), ou propose uniquement des suites de chiffrement jugées trop faibles.

Comment effacer le certificat SSL dans Google Chrome ?

Chrome délègue la gestion des certificats au système d’exploitation. Sur Windows, ouvrir certmgr.msc pour accéder au gestionnaire de certificats et supprimer les certificats problématiques (notamment ceux installés par des antivirus ou proxys). Sur macOS, utiliser le Trousseau d’accès pour localiser et supprimer ou désapprouver le certificat concerné. Dans Chrome, le chemin chrome://settings/security → « Gérer les certificats » renvoie vers ces mêmes outils système.

Les erreurs SSL dans Chrome ne sont pas une fatalité : elles suivent une logique précise, répondent à un diagnostic structuré et se corrigent avec des actions ciblées. Distinguer ce qui relève du navigateur, du système client et du serveur est la compétence clé qui transforme une page d’erreur bloquante en incident résolu en quelques minutes.