Partager via

Résoudre les erreurs SSL qui se produisent pendant le processus de connexion

  • Article

Note

  • Cet article concerne Uniquement Windows.
  • Les erreurs d’authentification cohérentes sont généralement dues à des paramètres incorrects, tandis que les échecs intermittents sont généralement dus à une connexion abandonnée, à des performances médiocres ou à des problèmes de délai d’attente.
  • Nous vous recommandons d’activer les extensions de fichier dans Windows Explorateur de fichiers.

Symptômes

Vous pouvez rencontrer certaines des erreurs suivantes lors de l’utilisation de TLS/SSL :

Canaux nommés

Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus de connexion. (fournisseur : Fournisseur SSL, erreur : 0 - Aucun processus à l’autre extrémité du canal) Microsoft SQL Server, Erreur : 233.

TCP

Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus de connexion. (fournisseur : Fournisseur SSL, erreur : 0 - La connexion a été fermée de force par l’hôte distant 10054) Microsoft SQL Server, Erreur : 233.

Résolution

Pour résoudre ces erreurs SSL, procédez comme suit :

  1. Mettez à jour votre certificat expiré ou incorrect.
  2. Activez les protocoles TLS.
  3. Vérifiez qu’il existe des suites de chiffrement correspondantes sur le client et le serveur.

Pour plus d’informations sur ces étapes, consultez les erreurs SSL signalées après la mise à niveau vers TLS 1.2.

Si cette résolution ne fonctionne pas, suivez les étapes décrites dans la section suivante pour collecter des journaux plus détaillés pour obtenir des informations sur la cause racine de ces erreurs.

Capture de données SSL avancée

Capturer les paramètres Windows à l’aide de SQLCHECK

Exécutez SQLCHECK sur les ordinateurs clients, les ordinateurs serveur et tous les autres systèmes associés, tels qu’un serveur web ou une machine intermédiaire de serveur lié SQL Server.

  1. Téléchargez la dernière version de SQLCHECK et décompressez-la dans un dossier, tel que C :\MSDATA.
  2. Double-cliquez sur le fichier exécutable dans Windows Explorateur de fichiers. Un rapport est écrit dans le dossier où se trouve SQLCheck.exe .

Configurer la trace de diagnostic intégré du pilote (BID)

  1. Téléchargez la dernière version de SQLTRACE et extrayez-la dans un dossier, tel que C :\MSDATA.

    Il y aura deux fichiers, SQLTrace.ps1 et SQLTrace.ini. Le fichier INI est utilisé pour configurer les éléments à capturer.

  2. Ouvrez SQLTrace.ini dans le Bloc-notes et accédez à la section Trace BID .

  3. Assurez-vous que cela BIDTrace=yes est défini.

  4. Assurez-vous que BIDProviderList la conformité au pilote utilisé par votre application est conforme.

    Les pilotes System.Data.SqlClient .NET intégrés sont automatiquement activés. Si ce ne sont pas les pilotes que votre application utilise, commentez cette ligne à l’aide du # caractère et supprimez les marques de commentaire de l’un des autres, comme la section ODBC ou la section OLEDB . Si vous n’êtes pas sûr, demandez à l’administrateur de base de données (DBA) ou au développeur d’applications, ou utilisez le quatrième BIDProviderList, qui contient tous les pilotes actuellement en cours d’utilisation.

  5. Enregistrez le fichier.

Configurer la trace réseau

La section réseau est automatiquement configurée avec Network=yes et NETSH=yes. Ces paramètres ne doivent pas être modifiés sans bonne raison.

Si vous effectuez le suivi d’une connexion locale, vérifiez que l’application utilise TCP/IP plutôt que la mémoire partagée ou les canaux nommés. Installez et utilisez WireShark pour la capture réseau, car il prend en charge les captures LoopBack. WireShark capture également bien le trafic VPN.

Configurer la trace d’authentification

La section Authentification est automatiquement configurée avec Auth=yes et de nombreux autres paramètres.

Vous devrez peut-être également définir FlushTickets=yes dans la section MISC . Il videra les tickets Kerberos pour tous les utilisateurs et services sur l’ordinateur.

Activer les traces BID

Une fois que toutes les modifications apportées au fichier SQLTrace.ini ont été enregistrées, les traces BID doivent être activées avant que le suivi puisse commencer.

  1. Ouvrez PowerShell en tant qu’administrateur.

  2. Remplacez le répertoire par le dossier contenant SQLTrace.ps1.

    CD C:\MSDATA

  3. Initialisez le registre de suivi BID.

    .\SQLTrace.ps1 -setup

  4. Redémarrez le service ou l’application que vous souhaitez suivre. Sinon, l’application ne sera pas tracée.

Collecter les données de trace

Note

Vérifiez que les étapes précédentes ont été effectuées sur tous les ordinateurs avant de continuer.

  1. Ouvrez PowerShell sur tous les ordinateurs suivis en tant qu’administrateur. Effectuez les étapes de démarrage sur tous les ordinateurs avant de reproduire le problème.

  2. Remplacez le répertoire par le dossier contenant SQLTrace.ps1.

    CD C:\MSDATA

  3. Démarrez la collection de traces.

    .\SQLTrace.ps1 -start

  4. Reproduire le problème lorsque l’invite de commandes s’affiche.

  5. Arrêtez le suivi.

    .\SQLTrace.ps1 -stop

Un dossier de sortie est généré dans le répertoire actif et vous pouvez l’utiliser pour une analyse plus approfondie.

La trace peut prendre une minute ou deux pour s’arrêter complètement, car le téléchargement des journaux d’événements peut prendre un certain temps.

Vous pouvez démarrer et arrêter la trace plusieurs fois sans rétablir les étapes de configuration. Chaque fois qu’il est pris, un nouveau dossier est créé avec un horodatage dans le cadre du nom du dossier. Cette heure correspond à l’heure à laquelle la trace démarre.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.