Passer au contenu principal
Certains réseaux d’entreprise et réseaux internes effectuent une interception TLS (« inspection SSL ») sur le trafic HTTPS sortant (généralement via Zscaler ou des passerelles de sécurité similaires). Windsurf Editor doit établir des connexions TLS sortantes vers des services externes (pour la connexion et les fonctionnalités reposant sur le cloud). Si le trafic inspecté est signé à nouveau par une autorité de certification d’inspection de l’entreprise qui n’est pas approuvée par votre machine / environnement d’exécution (ou si la chaîne est incomplète), Windsurf peut ne pas parvenir à se connecter et afficher des erreurs SSL/de certificat ou de négociation. En particulier, un diagnostic des problèmes d’inspection SSL/TLS peut être nécessaire si :
  • Vous voyez « Failed to connect » ou des erreurs réseau similaires
  • L’éditeur ou le panneau Cascade affiche un écran vide qui ne se charge jamais
  • Cascade ou d’autres fonctionnalités reposant sur le cloud ne peuvent pas se charger ou se connecter
  • Les flux de connexion ou d’activation échouent de manière inattendue
  • Les fonctionnalités sont opérationnelles sur un réseau domestique/partage de connexion mais échouent sur le réseau de l’entreprise
  • Vous voyez des erreurs de certificat ou de négociation TLS (handshake) dans les logs/outils de développement
Si vous rencontrez également des problèmes liés au proxy, consultez la page Configuration du proxy.

​
1. Vérifiez si votre réseau utilise l’inspection SSL

Avant de modifier quoi que ce soit dans l’éditeur, demandez à votre équipe IT / sécurité / réseau :
  • Réalisons-nous une interception TLS / inspection SSL sur le trafic HTTPS sortant ?
  • L’inspection SSL est-elle activée pour les stations de travail des développeurs et les outils de développement (pas seulement les navigateurs) ?
  • Quelle chaîne d’AC racine / d’AC intermédiaire est utilisée pour signer le trafic inspecté ?
  • Cette chaîne d’AC est-elle déployée sur les endpoints et approuvée par les applications/runtimes utilisés pour le développement ?
Si votre organisation n’utilise pas l’inspection SSL, vous n’avez généralement pas besoin de suivre ce guide. Si votre organisation utilise l’inspection SSL, continuez ci-dessous.

​
2. Capturer l’erreur sous-jacente dans Windsurf (Outils de développement → Console)

Windsurf Editor (basé sur VS Code) expose des Outils de développement qui peuvent afficher les échecs TLS/de certificat réels.
  1. Ouvrez Help → Dev Tools / Developer Tools
  2. Sélectionnez l’onglet Console
  3. Recherchez les erreurs affichées en rouge
  4. Déployez chaque entrée d’erreur pour voir tous les détails (champs d’erreur imbriqués / traces de pile)
Les types d’erreurs courants incluent : Échecs de validation de certificat (autorité de certification non approuvée) :
  • certificate signed by unknown authority
  • unable to verify the first certificate
  • self signed certificate in certificate chain
  • UNABLE_TO_VERIFY_LEAF_SIGNATURE
Échecs de chaînage (certificat intermédiaire manquant) :
  • unable to get local issuer certificate
  • unable to get issuer certificate
Échecs de négociation TLS :
  • handshake_failure
  • wrong version number
  • protocol negotiation failed
  • ERR_SSL_PROTOCOL_ERROR
Si vous pouvez fournir le texte détaillé de l’erreur de console à l’équipe informatique/sécurité, cela réduit généralement de manière significative le temps de résolution.

​
3. Ce qui provoque cela dans les environnements avec inspection SSL

Lorsque l’inspection SSL est activée, la passerelle termine puis rétablit les connexions TLS. Un certificat serveur synthétique, signé par une autorité de certification d’inspection de l’entreprise (AC racine et parfois certificats d’autorité de certification intermédiaire), est alors présenté au client. Les échecs de connectivité Windsurf se produisent généralement lorsque :
  • L’AC racine d’inspection de l’entreprise n’est pas approuvée sur le poste client et/ou
  • La chaîne de certificats d’inspection est incomplète (autorité de certification intermédiaire manquante) et/ou
  • L’IDE ou l’environnement d’exécution utilise un magasin de certificats de confiance distinct de celui du système d’exploitation, qui n’inclut pas la chaîne d’AC d’inspection de l’entreprise, et/ou
  • La politique de l’entreprise impose des contraintes TLS qui rompent la négociation (version minimale de TLS/suites de chiffrement, blocage du trafic qui ne peut pas être déchiffré, etc.)
Il s’agit généralement d’un problème de configuration des certificats/de la chaîne de confiance/de la politique de l’entreprise, et non d’un problème de mise en œuvre spécifique à Windsurf.

​
4. Collaborez avec votre équipe informatique/sécurité pour résoudre le problème

Étant donné que l’inspection SSL et le déploiement des certificats sont contrôlés par votre organisation, la résolution du problème implique généralement des modifications au niveau de l’équipe informatique/sécurité.

​
A) Valider la politique d’inspection SSL pour le trafic Windsurf

Demandez à l’équipe informatique/sécurité de confirmer :
  • Si l’inspection SSL s’applique au trafic HTTPS sortant lié à Windsurf
  • Si des blocages/refus d’accès se produisent en raison de la validation des certificats, de règles de sécurité, ou de contraintes de négociation TLS

​
B) Vérifier que la chaîne d’autorités de certification utilisée pour l’inspection de l’entreprise est correctement déployée et approuvée

Demandez à l’équipe IT/sécurité de :
  • Déployer l’autorité de certification racine (Root CA) utilisée pour l’inspection SSL de l’entreprise sur les postes des développeurs
  • Vérifier que tous les certificats d’autorité de certification intermédiaire requis sont présents et que la chaîne est correcte
  • Vérifier la chaîne de confiance en utilisant le même magasin de certificats que celui utilisé par l’IDE/le runtime (magasin du système d’exploitation vs magasin spécifique au runtime)

​
C) Configurer une exclusion d’inspection SSL ciblée (solution de repli)

Si l’alignement de confiance n’est pas réalisable, demandez à l’équipe informatique/sécurité de :
  • Créer une exclusion d’inspection SSL pour les points de terminaison de service Windsurf requis (conformément au processus de gestion de la liste d’autorisation et des exigences réseau de votre organisation)
  • Limiter strictement la portée de ce contournement et l’aligner sur votre politique de sécurité

​
5. Que transmettre à l’équipe IT / sécurité (copier/coller)

Problème : Windsurf Editor ne parvient pas à se connecter sur le réseau d’entreprise ; il s’agit probablement d’un problème de confiance ou de chaîne de certification lié à l’inspection SSL / l’interception TLS. Éléments de preuve : Aide → Outils de développement → Console affiche des erreurs TLS/de certificat ou de handshake (détails complets disponibles en développant les erreurs rouges dans la console). Demande :
  1. Confirmer si l’inspection SSL est activée pour le trafic HTTPS sortant lié à Windsurf.
  2. Confirmer que l’autorité de certification racine d’inspection SSL de l’entreprise et tous les certificats intermédiaires sont déployés et approuvés sur ce poste (et dans tout magasin de certificats de confiance spécifique au runtime utilisé par l’IDE).
  3. Si l’alignement de confiance n’est pas possible, configurer une exception ciblée d’inspection SSL pour les points de terminaison de service Windsurf requis.
À inclure :
  • Horodatage(s) de l’échec
  • Version du système d’exploitation
  • Préciser si Zscaler Client Connector (ou un agent similaire) est installé/activé
  • Texte détaillé de l’erreur de console depuis Outils de développement → Console
  • Préciser si cela fonctionne sur un hotspot/un réseau domestique mais échoue sur le réseau d’entreprise

​
6. Quand utiliser quelle option

Utilisez des correctifs de déploiement/de confiance de certificats si :
  • Les erreurs indiquent « unknown authority », « unable to verify », « issuer not found » ou des certificats intermédiaires manquants
  • Vous voulez la solution la plus pérenne tout en conservant l’inspection SSL activée
Utilisez un contournement d’inspection SSL limité à un périmètre donné si :
  • L’IDE/runtime ne peut pas, en pratique, consommer la chaîne d’AC de l’entreprise
  • L’alignement des magasins de confiance n’est pas fiable dans votre environnement
  • L’équipe IT/sécurité confirme que l’inspection est à l’origine des échecs et approuve une exception ciblée
Si vous ne savez pas ce qui s’applique, votre équipe IT/sécurité est la source de vérité : elle peut confirmer si l’inspection SSL est activée, quelle chaîne d’AC est utilisée, comment les points de terminaison sont gérés, et si des règles de contournement sont appropriées.