Dépannage de l'Inspection TLS

Introduction

Cet article couvre des scénarios de dépannage avancés pour l'Inspection TLS. Avant de continuer, il est recommandé de revoir la configuration de l'Inspection TLS et le comportement pour comprendre comment le trafic est traité et appliqué.

Dans des conditions normales, l'Inspection TLS n'est pas visible pour les utilisateurs finaux. Pour vérifier si le trafic est inspecté, vérifiez le champ Inspection TLS dans Événements de Compte (1 = inspecté, 0 = contourné), passez en revue l'émetteur du certificat dans le navigateur (Cato Networks), ou utilisez les rapports d'Inspection TLS.

Cato inclut un ensemble de règles de contournement par défaut pour les applications, appareils, et domaines bien connus. Ces règles gérées par le système ne sont pas éditables et doivent toujours être revues avant de créer des règles personnalisées. Pour plus de détails, voir Règles de contournement par défaut

Symptômes

Causes possibles

La plupart des problèmes d'Inspection TLS sont liés à quelques conditions courantes.

  • Certaines applications ne sont pas compatibles avec l'Inspection TLS. Les applications utilisant le verrouillage de certificats, la validation TLS stricte, ou le TLS mutualisé rejetteront l'interception et échoueront à se connecter.

  • Les problèmes de confiance des certificats sur le client sont une autre cause fréquente. Si le certificat racine Cato est manquant, non fiable ou déployé de façon incohérente, le trafic inspecté échouera même si la politique est correcte.

  • Dans d'autres cas, le problème provient du serveur de destination. Les problèmes tels que les certificats expirés, chaînes incomplètes, discordances de nom d'hôte, ou autorités de certification inconnues peuvent ne pas toujours être visibles dans le navigateur lorsque l'Inspection TLS est activée, mais sont toujours appliqués par le PoP.

  • Les systèmes hérités peuvent échouer en raison d'incohérences de protocole ou de chiffrement TLS. Les applications utilisant des versions TLS obsolètes ou des suites de chiffrement faibles peuvent ne pas répondre aux exigences définies dans la politique d'Inspection TLS.

  • Les sites Web modernes peuvent également introduire des problèmes en raison de multiples domaines dépendants. Si seul le domaine principal est autorisé ou contourné tandis que les domaines support sont bloqués ou inspectés différemment, les utilisateurs peuvent rencontrer un chargement lent ou du contenu manquant.

  • Enfin, le comportement spécifique à la plateforme joue un rôle. Les appareils mobiles, les points d'extrémité BYOD et les systèmes Linux peuvent se comporter différemment en raison de limitations de confiance des certificats, validation spécifique à l'application, ou règles de contournement par défaut.

Dépannage initial

Lors de l'investigation des problèmes liés au TLS, le principal objectif est de déterminer si le problème provient du client, du réseau (Inspection TLS), ou du serveur de destination.

1. Isoler la portée

Commencez par valider si le problème est spécifique au client. Testez la même URL :

  • Depuis un navigateur différent
  • Depuis un autre appareil sur le même réseau
  • Depuis le même appareil sur un réseau différent (par exemple, point d'accès)

Si le problème est limité à un navigateur ou un appareil spécifique, cela indique typiquement un problème de confiance locale ou de configuration. Si cela fonctionne à l'extérieur du réseau, le problème est probablement lié à l'Inspection TLS ou l'application de la politique.

2. Vérifier l'Inspection TLS / Emetteur du certificat

Depuis le navigateur :

  • Ouvrir DevTools → onglet Sécurité ou cliquer sur l’icône de verrouillage
  • Inspecter la chaîne de certificats

Vérifiez l'Émetteur :

  • Proxy / CA entreprise (par ex., Cato) → L'Inspection TLS est active
  • CA publique (par exemple, DigiCert, Let's Encrypt) → session TLS directe

3. Valider la confiance des certificats sur le client

  • Assurez-vous que le certificat racine Cato est correctement installé sur le point d'extrémité.

  • Vérifiez que le certificat racine est dans la base de confiance du système d'exploitation :
    • Sur Windows, ouvrez le Gestionnaire de certificats pour l'ordinateur en tapant certlm.msc et recherchez le certificat racine sous Autorités de certification racine de confiance
    • Sur Mac, ouvrez Accès au trousseau et cherchez le certificat racine sous le Trousseau système
  • Vérifiez l'heure et la date du système
  • Si le certificat racine Cato est manquant sur le point d'extrémité, téléchargez-le et installez-le comme expliqué dans Installation du Certificat Cato sur les appareils

  • Une configuration de confiance manquante ou incorrecte entraînera des échecs TLS immédiats.

4. Tester la connexion TLS depuis le client

Utilisez des outils côté client pour simuler une connexion TLS et identifier exactement où et pourquoi l'échange échoue. Ces outils révèlent des erreurs souvent cachées derrière des messages génériques du navigateur.

Exécutez ce qui suit ou similaire depuis le point d'extrémité affecté :

curl.exe -v https://<domaine>

Si OpenSSL est disponible :

openssl s_client -connect <domaine>:443 -servername <domaine>

Sortie attendue (Succès)

* Connexion SSL utilisant TLS1.2 / TLS1.3 
* Certificat serveur :
* sujet : CN=www.google.com 
* émetteur : CN=GTS CA 1C3 
> GET / HTTP/1.1 
< HTTP/1.1 200 OK

Il est important de déterminer d'abord si le problème est lié au client, au serveur de destination ou à la configuration de l'Inspection TLS elle-même. 

Dépannage des problèmes courants

Note :
Les problèmes listés ci-dessous représentent des scénarios courants observés dans les déploiements d'Inspection TLS. Beaucoup de ces erreurs sont génériques et peuvent ou non s'appliquer directement à votre environnement spécifique.
Si les symptômes ou les résolutions décrits ne correspondent pas à votre cas, il est recommandé de collecter des données de diagnostic (par exemple, SSS, HAR, et PCAP) depuis la machine cliente et de soumettre un ticket de support pour une analyse approfondie.

Dépannage des applications échouées 

Problème : Certaines applications échouent à établir des connexions sécurisées ou cessent de fonctionner après l'activation de l'Inspection TLS.

Attente comportementale : Les applications avec des contrôles de sécurité stricts (par exemple, applications bancaires, outils de sécurité pour terminaux) peuvent échouer immédiatement les connexions, se bloquer silencieusement, ou réessayer les connexions à plusieurs reprises. Cela se produit parce que l'Inspection TLS introduit un certificat intermédiaire, que ces applications sont spécifiquement conçues pour détecter et rejeter.

Résolution :
Validez en contournant l'Inspection TLS pour un seul utilisateur ou IP source en utilisant une règle en haut de la politique. Si l'application fonctionne lorsqu'elle est contournée, créez une exclusion ciblée (basée sur le domaine/FQDN) et évitez les règles larges. De plus, l'Assistant de configuration d'Inspection TLS de Cato peut être utilisé pour contourner les domaines sensibles avec une configuration minimale. 

Si l'application ou le serveur appliquent le verrouillage de certificats ou des exigences strictes TLS, l'Inspection TLS ne peut pas être appliquée. Dans ce cas, l'approche correcte est de contourner définitivement ce trafic.

Exemple :
Si une application financière échoue à se connecter et fonctionne immédiatement après le contournement de l'Inspection TLS pour cet utilisateur, cela confirme l'incompatibilité - ajoutez le domaine de l'application à la liste de contournement. 

Dépannage des avertissements de certificats du navigateur

Problème : Les utilisateurs voient des avertissements de certificats ou des applications échouent après l'activation de l'Inspection TLS.

Attente comportementale : Les utilisateurs peuvent rencontrer des avertissements de navigateur (par exemple, « connexion non sécurisée ») ou des échecs de connexion. Le comportement peut varier selon les appareils en fonction de la bonne installation du certificat Cato.

Résolution : Assurez-vous que le certificat racine d'Inspection TLS de Cato est installé et fiable sur tous les points d'extrémité. Déployez en utilisant GPO/MDM et vérifiez la chaîne complète de certificats sur le client.

Si des certificats privés/internes sont utilisés, assurez-vous qu'ils sont correctement fiables ou suivez les procédures de gestion de certificats TLS Inspection pertinentes.

Si le comportement est incohérent, validez en contournant l'Inspection TLS pour un seul utilisateur ou appareil afin de confirmer l'impact lié aux certificats.

Référez-vous à Sécuriser le trafic avec Inspection TLS en utilisant des certificats privés si vous utilisez des certificats privés dans votre organisation. 

Dépannage des discordances de noms d'hôte

Problème : Les utilisateurs rencontrent des erreurs de certificats ou des connexions bloquées en raison de discordances de noms d'hôte lorsqu'ils accèdent à certains sites Web, surtout lorsque l'Inspection TLS est activée.

Attente comportementale : Lorsque le serveur présente un certificat dont le Nom Commun (CN) ou SAN ne correspond pas au nom d'hôte demandé, la connexion est considérée comme invalide.

Sans Inspection TLS, le navigateur détecte directement cette discordance et affiche un avertissement de certificat.

Avec l'Inspection TLS activée, le navigateur établit la session TLS avec le PoP de Cato au lieu du serveur d'origine. Le PoP signe de nouveau le certificat en utilisant le CA racine de Cato, ce qui le fait apparaître valide pour le client. Ainsi, aucune discordance n'est affichée dans le navigateur, bien que le problème existe toujours en arrière-plan.

Résolution : Validez le comportement en contournant l'Inspection TLS pour un utilisateur ou une IP source spécifique. Si le navigateur montre alors une erreur de discordance de noms d'hôte, cela confirme que le problème provient du serveur de destination.

Étant donné que la discordance est causée par la configuration des certificats du serveur, elle ne peut pas être corrigée par l'Inspection TLS. L'action appropriée est de :

  • Autoriser l'accès en contournant l'Inspection TLS pour le domaine spécifique, ou
  • Bloquer le trafic selon la politique si la discordance est considérée comme un risque de sécurité

Évitez les règles de contournement larges et préférez des exclusions ciblées de domaine/FQDN où nécessaire.

Exemple : En accédant à https://www.testingmcafeesites.com/, le serveur présente un certificat pour platformsplat1.mcafee.com.

Sans Inspection TLS, le navigateur signale immédiatement une discordance de noms d'hôte.

Avec l'Inspection TLS activée, le navigateur voit un certificat valide délivré par le CA racine de Cato pour www.testingmcafeesites.com, donc aucune erreur n'est affichée. Cependant, le PoP de Cato détecte la discordance en arrière-plan et applique la politique configurée (blocage ou avertissement).

Dépannage des problèmes de chargement des sites Web ou des applications

Problème : Les sites Web échouent à charger, se rendent partiellement, ou se comportent de manière inattendue lorsque l'Inspection TLS est activée.

Attente comportementale :

  • Les pages peuvent se figer, charger indéfiniment, ou se rendre partiellement
  • Les flux de connexion/authentification peuvent échouer ou tourner en boucle
  • Certains sites peuvent sembler lents en raison de l'impact de déchiffrement/réchiffrement TLS
  • Le comportement peut être incohérent (par ex. fonctionne sur un réseau, échoue via Cato)

Cela est typiquement observé avec des applications web modernes utilisant des contrôles de sécurité stricts ou des dépendances TLS complexes.

Résolution :
Valider en contournant l'Inspection TLS pour un utilisateur spécifique ou une IP source. Si le site fonctionne lorsqu'il est contourné, créez une exclusion de domaine/FQDN ciblée.

Évitez les règles de contournement générales — limitez les exclusions aux domaines requis uniquement.

Si l'application repose sur des mécanismes de sécurité stricts (par exemple, certificats épinglés ou gestion avancée de TLS), l'inspection peut ne pas être prise en charge, et le contournement est l'approche correcte.

Scénario – Applications Web Modernes (SaaS) :
Certaines plateformes SaaS (par exemple, des applications avec plusieurs domaines backend/CDNs) peuvent se charger partiellement (interface utilisateur fonctionne, API échouent). Dans ces cas, identifiez tous les domaines requis via HAR/DevTools et assurez une couverture complète dans la règle de contournement.

Dépannage des erreurs de validation de certificat Cato

Problème : Les erreurs liées à TLS de Cato apparaissent lors de la navigation ou de l'utilisation d'applications.

Comportement Attendu :

Les utilisateurs peuvent rencontrer des erreurs génériques telles que : 

  • "Connexion sécurisée échouée"
  • "Certificat non approuvé"
  • Réinitialisations ou coupures de connexion inattendues

Ces erreurs sont généralement non spécifiques et n'indiquent pas clairement si le problème provient du client, du serveur ou du processus d'Inspection TLS.

Résolution :
Validez le comportement en contournant temporairement l'Inspection TLS pour un utilisateur unique ou une adresse IP source.

  • Si le problème est résolu lorsqu'il est contourné, cela confirme un échec de validation de certificat durant l'inspection.
  • Dans les cas où les CA intermédiaires ou émetteurs ne sont pas reconnus, cela peut être dû à un certificat n'étant pas encore inclus dans le bundle de certificats approuvé de Cato.

Comme solution temporaire, il est recommandé de contourner l'Inspection TLS pour le domaine/application affecté tout en ouvrant un dossier de support.

Cato met continuellement à jour son bundle de certificats approuvés conformément aux normes de l'industrie et aux autorités de certification les plus couramment utilisées. Si le certificat est valide et largement approuvé, il est probable qu'il soit ajouté lors d'une mise à jour future.

La correction permanente devrait se concentrer sur :

  • S'assurer que le serveur présente une chaîne de certificats complète et valide.
  • Utilisation de certificats émis par des CA bien connus et approuvés.

Si le serveur présente une chaîne de certificats invalide ou incomplète, l'Inspection TLS bloquera correctement la connexion. La correction devrait être effectuée du côté serveur, ou contourner l'Inspection TLS si nécessaire.

Domaines nouvellement approuvés / récemment publiés

Les domaines qui sont nouvellement publiés, récemment mis à jour ou reclassifiés sur Internet peuvent ne pas encore être reconnus de manière cohérente par tous les moteurs de réputation, autorités de certification ou magasins de confiance.

Cela peut conduire à des scénarios où le trafic est bloqué ou signalé — non pas à cause d'un échec TLS seul, mais en raison de l'application des règles de sécurité par les politiques de pare-feu Internet ou d'une confiance de certificat incomplète.

Comportement Attendu :
Ces domaines peuvent :

  • Être mal classifiés ou catégorisés de manière incohérente par les moteurs de sécurité
  • Présenter des certificats qui ne sont pas complètement propagés ou approuvés mondialement
  • Déclencher des erreurs TLS lors de l'inspection en raison de chaînes de confiance incomplètes
  • Être bloqués en fonction de la politique plutôt que d'un problème de connectivité réel.

Ce comportement est courant peu après qu'un domaine devienne actif ou subisse des modifications.

Résolution :

  • Valider directement le certificat depuis le point de terminaison pour confirmer sa légitimité.
  • Si le domaine est vérifié comme sûr :
    • Re-catégorisez-le dans une catégorie autorisée selon les exigences politiques, ou
    • Créez une règle ciblée d'autorisation/de contournement (évitez les exclusions générales)
  • Traitez les règles de contournement comme temporaires lorsque cela est possible.
  • Réévaluez le domaine après un certain temps, une fois que sa réputation et sa confiance de certificat sont pleinement établies mondialement.

Note Clé :
Même si un domaine est légitime, une propagation de certificat incomplète peut toujours causer des erreurs liées à TLS. Dans ces cas, le comportement est attendu et doit être traité via des ajustements politiques contrôlés plutôt que d'assumer une mauvaise configuration.

Scénario – Chaîne de Certificat Incomplète :
Un site peut fonctionner directement dans un navigateur (en raison d'intermédiaires en cache) mais échouer sous Inspection TLS. Cela indique que le serveur ne présente pas la chaîne de certificats complète. La résolution consiste à corriger la configuration du serveur ou contourner le domaine.

Protocoles Non Supportés et Systèmes Legacy

Problème :
Les connexions échouent pour les applications ou systèmes utilisant des versions TLS obsolètes ou des suites de chiffrement faibles qui ne sont pas prises en charge sous Inspection TLS.

Comportement Attendu :
Les défaillances se produisent généralement pendant la poignée de main TLS et sont visibles directement dans le navigateur ou le client.

Les erreurs courantes du navigateur incluent :

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 Mauvaise Requête
Aucun certificat SSL requis n'a été envoyé

Dans certains cas :

  • La page peut échouer à se charger entièrement.
  • La connexion peut se réinitialiser immédiatement.
  • Les clients lourds ou applications legacy peuvent échouer silencieusement ou afficher des erreurs de connexion génériques.

Cela se produit parce que le client ou le serveur ne peut pas négocier une version TLS compatible ou une suite de chiffrement avec le PoP Cato agissant comme le MITM.

Dans les événements, vous remarquerez aussi que le champ Description d'erreur TLS est rempli avec des informations spécifiques. 

Pour en savoir plus sur les erreurs, visitez Comprendre les erreurs TLS. 

Résolution :

  • Contournez temporairement l'Inspection TLS pour un utilisateur spécifique ou une IP source pour valider le comportement.
  • Si l'application fonctionne lorsqu'elle est contournée → confirme un décalage de négociation TLS durant l'inspection.

Ensuite, validez les capacités TLS en utilisant des outils externes comme https://www.ssllabs.com/ssltest/.

Comparez les résultats avec votre politique d'Inspection TLS :

  • Version TLS minimale autorisée
  • Niveau d'application de la suite de chiffrement

Si confirmé :

  • Mettez à jour ou améliorez l'application ou le serveur pour supporter les versions TLS modernes et des suites de chiffrement fortes.
  • Si les mises à niveau ne sont pas réalisables, configurez un contournement ciblé d'Inspection TLS pour l'application ou le domaine affecté.

Note :
Par défaut, Cato autorise une large gamme de versions TLS et de suites de chiffrement. Cependant, les administrateurs peuvent appliquer des contrôles plus stricts dans la politique d'Inspection TLS (par exemple, version TLS minimale ou force du chiffrement), ce qui peut causer l'échec des applications legacy. Pour plus d'informations, lisez ici.

 

Scénario – Application Interne Legacy :
Une application interne ou tierce legacy peut échouer uniquement lorsqu'elle est routée via Cato avec l'Inspection TLS activée mais fonctionner lorsqu'elle est contournée. Cela indique généralement une dépendance sur versions TLS obsolètes, nécessitant soit une mise à niveau de l'application ou un contournement permanent.

Dépannage des problèmes TLS spécifiques au système d'exploitation (limitations attendues)

Problème : Problèmes de connectivité, comportement incohérent, ou manque de visibilité d'Inspection TLS sur certains systèmes d'exploitation et types d'appareils (par ex. mobile, BYOD, Linux).

Comportement Attendu :

Le comportement varie significativement selon le système d'exploitation et la conception de l'application.

Pour les appareils Android et Linux, l'Inspection TLS est contournée par défaut en raison des limitations de confiance de certificat et du comportement des applications. Cependant, les configurations plus récentes (via Paramètres Avancés dans CMA) permettent aux administrateurs de imposer l'Inspection TLS sur ces plateformes, à condition que la confiance de certificat puisse être correctement établie.

Pour les appareils iOS, l'Inspection TLS est prise en charge, mais plusieurs applications (par ex., plateformes de médias sociaux telles que Instagram, Facebook, et applications similaires) sont contournées par défaut en raison de l'épinglage de certificat et des incompatibilités connues. D'autres applications qui imposent une validation stricte peuvent échouer et nécessiter une configuration de contournement manuel.

En général :

  • Les navigateurs peuvent fonctionner comme prévu une fois que le certificat Cato est installé.
  • Les applications natives/mobiles peuvent échouer immédiatement en raison de l'épinglage de certificat ou de magasins de confiance restreints.
  • Le comportement peut différer par application, même sur le même appareil.

Résolution :

Ces comportements sont généralement attendus et liés à la plateforme, non indicatifs d'une mauvaise configuration.

  • Appliquez l'Inspection TLS principalement sur les appareils gérés où le déploiement de certificats est contrôlé.
  • Utilisez des solutions MDM pour installer le certificat Cato au niveau système (là où c'est possible).
  • Soyez conscient des règles de contournement par défaut pour les applications et plateformes bien connues.
  • Pour les applications qui échouent en raison de l'épinglage de certificat ou d'une validation stricte, configurez un contournement ciblé d'Inspection TLS.
  • Lors de l'imposition de l'Inspection TLS sur des plateformes comme Android ou Linux, validez soigneusement la compatibilité avant un déploiement général.

Scénario – Échec d'Application Mobile :
Une application mobile (par ex., application bancaire ou de sécurité) échoue à se connecter via Cato alors que le navigateur fonctionne. L'application impose l'épinglage de certificat et ne fait pas confiance au certificat Cato. C'est attendu — l'action correcte est de contourner l'Inspection TLS pour cette application ou ce service.

Ouverture de dossiers auprès de Cato Support

Dans le cas où l'inspection TLS est obligatoire pour une application en raison de raisons de conformité ou réglementaires ou si vous estimez que le blocage TLS est inattendu, veuillez soumettre un ticket de support avec les résultats des étapes de dépannage ci-dessus. Veuillez inclure les informations suivantes dans le ticket :

  • Détails du problème rencontré et impact global sur les utilisateurs. Horodatage/Fuseau Horaire de l'utilisateur éprouvant le problème. 
  • Événements liés et configuration des règles de pare-feu/TLS.
  • Reproduisez le problème et exécutez le Support en Libre-Service. Inclure le numéro de ticket généré par l'outil.

 

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0

0 commentaire