Problème: j'obtiens cette exception "LA CONNEXION SOUS-JACENTE A ÉTÉ FERMÉE: UNE ERREUR INATTENDUE SURVENUE SUR UN ENVOI" dans mes journaux et cela rompt notre intégration OEM avec notre système de marketing par e-mail à des moments aléatoires variant de [1heure à 4 heures]

Mon site Web est hébergé sur un serveur Windows 2008 R2 avec IIS 7.5.7600. Ce site Web contient un grand nombre de composants OEM et un tableau de bord complet. Tout fonctionne bien avec tous les autres éléments du site Web, à l'exception de l'un de nos composants de marketing par e-mail que nous utilisons comme solution iframe dans notre tableau de bord. La façon dont cela fonctionne est, j'envoie un httpWebRequestobject avec toutes les informations d'identification et je récupère une URL que j'ai mise dans un iframe et cela fonctionne. Mais cela ne fonctionne que pendant un certain temps [1 heure - 4 heures], puis j'obtiens l'exception ci-dessous "LA CONNEXION SOUS-JACENTE A ÉTÉ FERMEE: UNE ERREUR INATTENDUE SURVENUE SUR UN ENVOI" et même si le système essaie d'obtenir l'URL du httpWebRequest it échoue avec la même exception. La seule façon de le faire fonctionner à nouveau est de recycler le pool d'applications ou quoi que ce soit est modifié dans web.config.

Option essayée

Explicitement ajouté, keep-alive = false

keep-alive = true

Augmentation du temps mort: <httpRuntime maxRequestLength="2097151" executionTimeout="9999999" enable="true" requestValidationMode="2.0" />

J'ai téléchargé cette page sur un site Web non SSL pour vérifier si le certificat SSL sur notre serveur de production établit la connexion pour supprimer une certaine façon.

Toute direction vers la résolution est grandement appréciée.

Code:

Public Function CreateHttpRequestJson(ByVal url) As String
    Try
        Dim result As String = String.Empty
        Dim httpWebRequest = DirectCast(WebRequest.Create("https://api.xxxxxxxxxxx.com/api/v3/externalsession.json"), HttpWebRequest)
        httpWebRequest.ContentType = "text/json"
        httpWebRequest.Method = "PUT"
        httpWebRequest.ContentType = "application/x-www-form-urlencoded"
        httpWebRequest.KeepAlive = False
        'ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3

        'TODO change the integratorID to the serviceproviders account Id, useremail 
        Using streamWriter = New StreamWriter(httpWebRequest.GetRequestStream())
            Dim json As String = New JavaScriptSerializer().Serialize(New With { _
            Key .Email = useremail, _
            Key .Chrome = "None", _
            Key .Url = url, _
            Key .IntegratorID = userIntegratorID, _
            Key .ClientID = clientIdGlobal _
            })

            'TODO move it to the web.config, Following API Key is holonis accounts API Key
            SetBasicAuthHeader(httpWebRequest, holonisApiKey, "")
            streamWriter.Write(json)
            streamWriter.Flush()
            streamWriter.Close()

            Dim httpResponse = DirectCast(httpWebRequest.GetResponse(), HttpWebResponse)
            Using streamReader = New StreamReader(httpResponse.GetResponseStream())
                result = streamReader.ReadToEnd()
                result = result.Split(New [Char]() {":"})(2)
                result = "https:" & result.Substring(0, result.Length - 2)
            End Using
        End Using
        Me.midFrame.Attributes("src") = result
    Catch ex As Exception
        objLog.WriteLog("Error:" & ex.Message)
        If (ex.Message.ToString().Contains("Invalid Email")) Then
            'TODO Show message on UI
        ElseIf (ex.Message.ToString().Contains("Email Taken")) Then
            'TODO Show message on UI
        ElseIf (ex.Message.ToString().Contains("Invalid Access Level")) Then
            'TODO Show message on UI
        ElseIf (ex.Message.ToString().Contains("Unsafe Password")) Then
            'TODO Show message on UI
        ElseIf (ex.Message.ToString().Contains("Invalid Password")) Then
            'TODO Show message on UI
        ElseIf (ex.Message.ToString().Contains("Empty Person Name")) Then
            'TODO Show message on UI
        End If
    End Try
End Function


Public Sub SetBasicAuthHeader(ByVal request As WebRequest, ByVal userName As [String], ByVal userPassword As [String])
    Dim authInfo As String = Convert.ToString(userName) & ":" & Convert.ToString(userPassword)
    authInfo = Convert.ToBase64String(Encoding.[Default].GetBytes(authInfo))
    request.Headers("Authorization") = "Basic " & authInfo
End Sub`

Pour moi, c'était tls12:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Si vous êtes bloqué avec .Net 4.0 et que le site cible utilise TLS 1.2, vous avez besoin de la ligne suivante à la place. ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

source: Prise en charge de TLS 1.2 et .NET: comment éviter les erreurs de connexion

Le code ci-dessous a résolu le problème

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls Or SecurityProtocolType.Ssl3

Cela fait des jours que j'ai le même problème avec une intégration qui "fonctionnait auparavant".

Par pure dépression, j'ai juste essayé

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Ssl3;

Cela a résolu le problème pour moi ... même si l'intégration n'utilise strictement que SSLv3.

Je suis venu à la réalisation que quelque chose ne fonctionnait pas depuis que Fiddler avait rapporté qu'il y avait un "chiffrement de négociation TLS vide" ou quelque chose du genre.

Espérons que cela fonctionne!

Dans mon cas, le site auquel je me connecte a été mis à niveau vers TLS 1.2. En conséquence, j'ai dû installer .net 4.5.2 sur mon serveur Web pour le prendre en charge.

Accédez à votre web.config / App.config pour vérifier le runtime .net que vous utilisez

  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
  </startup>

Voici la solution:

1. .NET 4.6 et supérieur. Vous n'avez pas besoin de faire de travail supplémentaire pour prendre en charge TLS 1.2, il est pris en charge par défaut.

2. .NET 4.5. TLS 1.2 est pris en charge, mais ce n'est pas un protocole par défaut. Vous devez vous inscrire pour l'utiliser. Le code suivant définira TLS 1.2 par défaut, assurez-vous de l'exécuter avant de vous connecter à une ressource sécurisée:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

3. .NET 4.0. TLS 1.2 n'est pas pris en charge, mais si .NET 4.5 (ou supérieur) est installé sur le système, vous pouvez toujours opter pour TLS 1.2 même si votre framework d'application ne le prend pas en charge. Le seul problème est que SecurityProtocolType dans .NET 4.0 n'a pas d'entrée pour TLS1.2, nous devrions donc utiliser une représentation numérique de cette valeur d'énumération:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

4. .NET 3.5 ou inférieur. TLS 1.2 n'est pas pris en charge (*) et il n'y a pas de solution de contournement. Mettez à niveau votre application vers une version plus récente du framework.

J'ai trouvé que c'est un signe que le serveur sur lequel vous déployez du code a un ancien framework .NET installé qui ne prend pas en charge TLS 1.1 ou TLS 1.2. Étapes à suivre:

1. Installation du dernier Runtime .NET sur vos serveurs de production (IIS et SQL)
2. Installation du dernier pack développeur .NET sur vos machines de développement.
3. Modifiez les paramètres «Framework cible» de vos projets Visual Studio vers le dernier framework .NET.

Vous pouvez obtenir le dernier pack de développement .NET et Runtime à partir de cette URL: http://getdotnet.azurewebsites.net/target-dotnet-platforms.html

Nous avons rencontré ce problème en raison duquel un site Web qui accédait à notre API obtenait le message "La connexion sous-jacente a été fermée: une erreur inattendue s'est produite lors d'un envoi." message.

Leur code était un mélange de .NET 3.x et 2.2, ce qui, d'après ce que je comprends, signifie qu'ils utilisent TLS 1.0.

La réponse ci-dessous peut vous aider à diagnostiquer le problème en activant TLS 1.0, SSL 2 et SSL3, mais pour être très clair, vous ne voulez pas faire cela à long terme car ces trois protocoles sont considérés comme non sécurisés et ne devraient plus l'être utilisé :

Pour que notre IIS réponde à leurs appels d'API, nous avons dû ajouter des paramètres de registre sur le serveur IIS pour activer explicitement les versions de TLS - REMARQUE: vous devez redémarrer le serveur Windows (pas seulement le service IIS) après avoir effectué ces modifications:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

Si cela ne le fait pas, vous pouvez également essayer d'ajouter l'entrée pour SSL 2.0:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

Pour être clair, ce n'est pas une bonne solution , et la bonne solution consiste à amener l'appelant à utiliser TLS 1.2, mais ce qui précède peut aider à diagnostiquer que c'est le problème.

Vous pouvez accélérer l'ajout de ces entrées de registre avec ce script PowerShell:

$ProtocolList       = @("SSL 2.0","SSL 3.0","TLS 1.0", "TLS 1.1", "TLS 1.2")
$ProtocolSubKeyList = @("Client", "Server")
$DisabledByDefault = "DisabledByDefault"
$Enabled = "Enabled"
$registryPath = "HKLM:\\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\"

foreach($Protocol in $ProtocolList)
{
    Write-Host " In 1st For loop"
        foreach($key in $ProtocolSubKeyList)
        {         
            $currentRegPath = $registryPath + $Protocol + "\" + $key
            Write-Host " Current Registry Path $currentRegPath"
            if(!(Test-Path $currentRegPath))
            {
                Write-Host "creating the registry"
                    New-Item -Path $currentRegPath -Force | out-Null             
            }
            Write-Host "Adding protocol"
                New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "0" -PropertyType DWORD -Force | Out-Null
                New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "1" -PropertyType DWORD -Force | Out-Null    
    }
}
 
Exit 0

Il s'agit d'une version modifiée du script de la page d'aide Microsoft pour Configurer TLS pour VMM . Cet article de basics.net est la page qui m'a initialement donné l'idée d'examiner ces paramètres.

Il suffit d'ajouter:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Si cela aide quelqu'un, le nôtre était un problème de certificat manquant. L'environnement est Windows Server 2016 Standard avec .Net 4.6.

Il existe un URI https de service WCF auto-hébergé, pour lequel Service.Open () s'exécuterait sans erreur. Un autre thread continuerait d'accéder à https: // OurIp: 443 / OurService? Wsdl pour s'assurer que le service était disponible. L'accès au WSDL échouait avec:

La connexion sous-jacente a été fermée: une erreur inattendue s'est produite lors d'un envoi.

L'utilisation de ServicePointManager.SecurityProtocol avec les paramètres applicables ne fonctionnait pas. Jouer avec les rôles et les fonctionnalités du serveur n'a pas non plus aidé. Puis est intervenu Jaise George , le SE, résolvant le problème en quelques minutes. Jaise a installé un certificat auto-signé dans l'IIS, ce qui a résolu le problème. Voici ce qu'il a fait pour résoudre le problème:

(1) Ouvrez le gestionnaire IIS (inetmgr) (2) Cliquez sur le nœud du serveur dans le panneau de gauche, et double-cliquez sur "Certificats de serveur". (3) Cliquez sur "Créer un certificat auto-signé" dans le panneau de droite et tapez tout ce que vous voulez pour le nom convivial. (4) Cliquez sur «Site Web par défaut» dans le panneau de gauche, cliquez sur «Liaisons» dans le panneau de droite, cliquez sur «Ajouter», sélectionnez «https», sélectionnez le certificat que vous venez de créer et cliquez sur «OK» (5) Accéder l'URL https, elle doit être accessible.

Il vous suffit de changer la version de votre application comme 4.0 en 4.6 et de publier ce code.

Ajoutez également ci-dessous les lignes de code:

httpRequest.ProtocolVersion = HttpVersion.Version10; 
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

L'utilisation d'un proxy de débogage HTTP peut provoquer ce problème, tel que Fiddler.

Je chargeais un certificat PFX à partir d'un fichier local (authentification sur Apple.com) et cela a échoué car Fiddler n'a pas pu transmettre ce certificat.

Essayez de désactiver Fiddler pour vérifier et si c'est la solution, vous devez probablement installer le certificat sur votre machine ou d'une manière que Fiddler puisse l'utiliser.

Le code ci-dessous a résolu mon problème:

request.ProtocolVersion = HttpVersion.Version10; // THIS DOES THE TRICK
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;