Probleem: ik krijg deze uitzondering “De onderliggende verbinding was gesloten: er is een onverwachte fout opgetreden op een verzenden” in mijn logs en het is onze OEM-integratie met ons e-mailmarketingsysteem op willekeurige tijden variërend van [1 uur – 4 uur]

Mijn website wordt gehost op een Windows Server 2008 R2 met IIS 7.5.7600. Deze website heeft een groot aantal OEM-componenten en uitgebreid dashboard. Alles werkt prima met alle andere elementen van de website behalve met een van onze e-mailmarketingcomponent die we gebruiken als een IFRAME-oplossing in ons dashboard. De manier waarop het werkt is, stuur ik een httpwebrequestobject met alle inloggegevens en ik krijg een URL-achterkant die ik in een iframe inzet en het werkt. Maar het werkt slechts al geruime tijd [1 uur – 4 uur] en dan krijg ik de onderstaande uitzondering “De onderliggende verbinding is gesloten: er is een onverwachte fout opgetreden bij een verzenden” en zelfs als het systeem de URL probeert te krijgen mislukt met dezelfde uitzondering. De enige manier om het opnieuw te laten werken, is het recyclen van de toepassingspool of alles wordt bewerkt in Web.Config. Ik ben echt alle optie uitgeput waar ik aan kon bedenken.

optie geprobeerd

Expliciet toegevoegd, keep-alive = false

keep-alive = true

Verhoogde de time-out: <httpRuntime maxRequestLength="2097151" executionTimeout="9999999" enable="true" requestValidationMode="2.0" />

Ik heb deze pagina geüpload naar een niet-SSL-website om te controleren of het SSL-certificaat op onze productieserver de verbinding maakt om wat te laten vallen hoe.

Elke richting naar resolutie wordt zeer op prijs gesteld.

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`

Antwoord 1, autoriteit 100%

Voor mij was het tls12:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Antwoord 2, autoriteit 34%

Als je vastzit aan .Net 4.0 en de doelsite TLS 1.2 gebruikt, heb je in plaats daarvan de volgende regel nodig.
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

bron: TLS 1.2- en .NET-ondersteuning: hoe te vermijden Verbindingsfouten

Antwoord 3, autoriteit 12%

De onderstaande code heeft het probleem opgelost

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls Or SecurityProtocolType.Ssl3

Antwoord 4, autoriteit 11%

Ga naar uw web.config/App.config om te controleren welke .net-runtime u gebruikt

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

Hier is de oplossing:

1. .NET 4.6 en hoger. U hoeft geen extra werk te doen om TLS 1.2 te ondersteunen, het wordt standaard ondersteund.

2. .NET 4.5. TLS 1.2 wordt ondersteund, maar het is geen standaardprotocol. U moet zich aanmelden om het te gebruiken. De volgende code maakt TLS 1.2 standaard, zorg ervoor dat u deze uitvoert voordat u verbinding maakt met een beveiligde bron:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

3. .NET 4.0. TLS 1.2 wordt niet ondersteund, maar als u .NET 4.5 (of hoger) op het systeem hebt geïnstalleerd, kunt u zich nog steeds aanmelden voor TLS 1.2, zelfs als uw applicatieframework dit niet ondersteunt. Het enige probleem is dat SecurityProtocolType in .NET 4.0 geen vermelding heeft voor TLS1.2, dus we zouden een numerieke weergave van deze opsommingswaarde moeten gebruiken:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

4. .NET 3.5 of lager. TLS 1.2 wordt niet ondersteund (*) en er is geen tijdelijke oplossing. Upgrade uw applicatie naar een recentere versie van het framework.

Antwoord 5, autoriteit 7%

In mijn geval is de site waarmee ik verbinding maak geüpgraded naar TLS 1.2. Als gevolg hiervan moest ik .net 4.5.2 op mijn webserver installeren om het te ondersteunen.

Antwoord 6, autoriteit 7%

Ik heb al dagen hetzelfde probleem met een integratie die ook gewoon “vroeger werkte”.

Uit pure depressie heb ik het net geprobeerd

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

Dit loste het voor mij op..ook al maakt de integratie strikt alleen gebruik van SSLv3.

Ik kwam tot het besef dat er iets niet klopt sinds Fiddler meldde dat er een “lege TLS-onderhandelingscode” of iets dergelijks is.

Hopelijk werkt het!

Antwoord 7, autoriteit 3%

Ik heb ontdekt dat dit een teken is dat op de server waarop u code implementeert een oud .NET-framework is geïnstalleerd dat geen ondersteuning biedt voor TLS 1.1 of TLS 1.2. Stappen om op te lossen:

1. De nieuwste .NET Runtimeinstalleren op uw productieservers (IIS & SQL)
2. Het nieuwste .NET Developer Packinstalleren op uw ontwikkelmachines.
3. Wijzig de instellingen van het “Doelraamwerk” in uw Visual Studio-projecten naar het nieuwste .NET-raamwerk.

U kunt het nieuwste .NET Developer Pack en Runtime verkrijgen via deze URL: http:/ /getdotnet.azurewebsites.net/target-dotnet-platforms.html

Antwoord 8, autoriteit 3%

Voeg toe:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Antwoord 9, autoriteit 2%

We hadden dit probleem waarbij een website die toegang had tot onze API, de melding ‘De onderliggende verbinding was gesloten: er is een onverwachte fout opgetreden bij het verzenden’ kreeg. bericht.

Hun code was een mix van .NET 3.x en 2.2, wat, voor zover ik het begrijp, betekent dat ze TLS 1.0 gebruiken.

Het onderstaande antwoord kan u helpen het probleem te diagnosticeren door TLS 1.0, SSL 2 en SSL3 in te schakelen, maar om heel duidelijk te zijn: u wilt dat niet op de lange termijn doen, aangezien alle drie deze protocollen worden beschouwd als onveilig en mag niet meer worden gebruikt:

Om onze IIS te laten reageren op hun API-aanroepen, moesten we registerinstellingen toevoegen aan de IIS-server om versies van TLS expliciet in te schakelen – OPMERKING: u moet de Windows-server (niet alleen de IIS-service) opnieuw opstarten nadat u deze wijzigingen hebt aangebracht :

[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

Als dat niet het geval is, kunt u ook experimenteren met het toevoegen van de vermelding voor 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

Voor alle duidelijkheid: dit is geen goede oplossing, en de juiste oplossing is om de beller TLS 1.2 te laten gebruiken, maar het bovenstaande kan helpen bij de diagnose dat dit het probleem is.

Je kunt die reg-items sneller toevoegen met dit powershell-script:

$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

Dat is een aangepaste versie van het script van de Microsoft-helppagina voor TLS instellen voor VMM. Deze basics.net-artikelwas de pagina die me oorspronkelijk op het idee bracht om naar deze instellingen te kijken.

Antwoord 10

Als het iemand helpt, was er bij ons een probleem met een ontbrekend certificaat. Omgeving is Windows Server 2016 Standard met .Net 4.6.

Er is een zelf gehoste WCF-service https URI, waarvoor Service.Open() zonder fouten zou worden uitgevoerd. Een andere thread zou toegang blijven krijgen tot https://OurIp:443/OurService?wsdlom ervoor te zorgen dat de service beschikbaar. Toegang tot de WSDL mislukte met:

De onderliggende verbinding is gesloten: er is een onverwachte fout opgetreden bij het verzenden.

Het gebruik van ServicePointManager.SecurityProtocolmet toepasselijke instellingen werkte niet. Spelen met serverrollen en features hielp ook niet. Toen stapte Jaise George, de SE, het probleem in een paar minuten op. Jaiseinstalleerde een zelfondertekend certificaat in de IIS, waardoor het probleem werd opgelost. Dit is wat hij deed om het probleem aan te pakken:

(1) IIS-manager openen (inetmgr)
(2) Klik op het serverknooppunt in het linkerdeelvenster en dubbelklik op “Servercertificaten”.
(3) Klik op “Zelfondertekend certificaat maken” in het rechterpaneel en typ alles wat u maar wilt voor de beschrijvende naam.
(4) Klik op “Standaardwebsite” in het linkerdeelvenster, klik op “Bindingen” in het rechterdeelvenster, klik op “Toevoegen”, selecteer “https”, selecteer het certificaat dat u zojuist hebt gemaakt en klik op “OK”
(5) Ga naar de https-URL, deze moet toegankelijk zijn.

Antwoord 11

Je verandert gewoon je applicatieversie zoals 4.0 in 4.6 en publiceert die code.

Voeg ook onderstaande coderegels toe:

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

Antwoord 12

Het gebruik van een HTTP-foutopsporingsproxy kan dit veroorzaken, zoals Fiddler.

Ik was een PFX-certificaat aan het laden vanuit een lokaal bestand (authenticatie naar Apple.com) en het is mislukt omdat Fiddler dit certificaat niet kon doorgeven.

Probeer Fiddler uit te schakelen om te controleren en als dat de oplossing is, moet u het certificaat waarschijnlijk op uw computer installeren of op een andere manier dat Fiddler het kan gebruiken.

Antwoord 13

Ik heb de oplossing gevonden door web.config bij te werken met onderstaande code.

Mijn .Net-framework was ingesteld op 4.0 en na de update van het TLS-protocol op organisatieniveau kreeg ik plotseling met dit probleem te maken. Dus ik verwees naar het bovenstaande antwoord van “Guo Huang” en werkte het targetFramework bij en het werkte.

<system.web>
        <compilation debug="true" targetFramework="4.7.2" />
        <httpRuntime targetFramework="4.7.2"  maxRequestLength="102400" executionTimeout="3600"/>
</system.web>

Antwoord 14

De onderstaande code heeft mijn probleem opgelost:

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