Het verzoek is afgebroken: kon geen SSL / TLS beveiligd kanaal maken

Antwoord 8, autoriteit 4%

Na vele lange uren met hetzelfde probleem ontdekte ik dat het ASP.NET-account waarop de clientservice draaide, geen toegang had tot het certificaat. Ik heb het opgelost door naar de IIS-toepassingsgroep te gaan waaronder de web-app draait, naar Geavanceerde instellingen te gaan en de identiteit te wijzigen in het LocalSystem-account van NetworkService.

Een betere oplossing is om het certificaat te laten werken met het standaard NetworkService-account, maar dit werkt voor snelle functionele tests.

Antwoord 9, autoriteit 4%

De aanpak met instelling

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Het lijkt in orde, want Tls1.2 is de nieuwste versie van het beveiligde protocol. Maar ik besloot dieper te kijken en te antwoorden: moeten we het echt hardcoderen.

Specs: Windows Server 2012R2 x64.

Van internet wordt verteld dat .NetFramework 4.6+ standaard Tls1.2 moet gebruiken. Maar toen ik mijn project bijwerkte naar 4.6 gebeurde er niets.
Ik heb informatie gevonden die aangeeft dat ik handmatig enkele wijzigingen moet aanbrengen om Tls1.2 standaard in te schakelen

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1- 2-as-default-secure-protocols-in-wi

Maar voorgestelde Windows-update werkt niet voor R2-versie

Maar wat me heeft geholpen is het toevoegen van 2 waarden aan het register. Je kunt het volgende PS-script gebruiken, zodat ze automatisch worden toegevoegd

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Dat is ongeveer wat ik zocht. Maar ik kan nog steeds geen antwoord geven op de vraag waarom NetFramework 4.6+ deze …Protocol-waarde niet automatisch instelt?

Antwoord 10, autoriteit 2%

Iets dat het oorspronkelijke antwoord niet had. Ik heb wat meer code toegevoegd om het bullet proof te maken.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Antwoord 11, autoriteit 2%

“Het verzoek is afgebroken: kan SSL/TLS-beveiligd kanaal niet maken”-uitzondering kan optreden als de server een HTTP 401 Unauthorized-reactie op het HTTP-verzoek retourneert.

U kunt bepalen of dit gebeurt door System.Net-logboekregistratie op traceerniveau in te schakelen voor uw clienttoepassing, zoals beschreven in dit antwoord .

Zodra die logboekconfiguratie aanwezig is, start u de toepassing en reproduceert u de fout, en kijkt u vervolgens in de logboekuitvoer naar een regel als deze:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

In mijn situatie slaagde ik er niet in een bepaalde cookie in te stellen die de server verwachtte, waardoor de server op het verzoek reageerde met de 401-fout, wat op zijn beurt leidde tot de melding “Kan geen SSL/TLS-beveiligd kanaal maken” uitzondering.

Antwoord 12, autoriteit 2%

Een andere mogelijkheid is het onjuist importeren van het certificaat op de doos. Zorg ervoor dat u het omcirkelde selectievakje selecteert. Aanvankelijk deed ik het niet, dus de code had een time-out of gaf dezelfde uitzondering omdat de privésleutel niet kon worden gevonden.

Antwoord 13, autoriteit 2%

Een andere mogelijke oorzaak van de The request was aborted: Could not create SSL/TLS secure channel-fout niet maken, is een mismatch tussen de geconfigureerde cipher_suites-waarden van uw client-pc en de waarden van de server geconfigureerd als bereid en in staat om te accepteren. In dit geval, wanneer uw client de lijst met cipher_suites-waarden verzendt die hij kan accepteren in zijn eerste SSL-handshake/onderhandeling “Client Hello”-bericht, ziet de server dat geen van de opgegeven waarden acceptabel is en kan hij een “Alert ” antwoord in plaats van door te gaan naar de stap “Server Hallo” van de SSL-handshake.

Om deze mogelijkheid te onderzoeken, kunt u Microsoft Message Analyzeren gebruik het om een tracering uit te voeren op de SSL-onderhandeling die plaatsvindt wanneer u probeert en er niet in slaagt een HTTPS-verbinding met de server tot stand te brengen (in uw C#-app).

Als u een succesvolle HTTPS-verbinding kunt maken vanuit een andere omgeving (bijv. de Windows XP-machine die u noemde — of mogelijk door op de HTTPS-URL te klikken in een niet-Microsoft-browser die geen gebruikmaakt van de coderingssuite-instellingen van het besturingssysteem , zoals Chrome of Firefox), voer een andere Message Analyzer-tracering in die omgeving uit om vast te leggen wat er gebeurt als de SSL-onderhandeling slaagt.

Hopelijk zult u enig verschil zien tussen de twee Client Hello-berichten, zodat u precies kunt vaststellen wat er aan de hand is met de mislukte SSL-onderhandeling waardoor deze mislukt. Dan zou u in staat moeten zijn om configuratiewijzigingen in Windows aan te brengen waardoor het kan slagen. IISCryptois hiervoor een geweldig hulpmiddel (zelfs voor client-pc’s, ondanks de naam “IIS” ).

De volgende twee Windows-registersleutels bepalen de cipher_suites-waarden die uw pc zal gebruiken:

• HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
• HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Hier is een volledige beschrijving van hoe ik een exemplaar van deze variant van het probleem Could not create SSL/TLS secure channelheb onderzocht en opgelost: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in- windows.html

Antwoord 14, autoriteit 2%

Deze werkt voor mij in de MVC-webclient

public string DownloadSite(string RefinedLink)
{
    try
    {
        Uri address = new Uri(RefinedLink);
        ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
        System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
        using (WebClient webClient = new WebClient())
        {
            var stream = webClient.OpenRead(address);
            using (StreamReader sr = new StreamReader(stream))
            {
                var page = sr.ReadToEnd();
                return page;
            }
        }
    }
    catch (Exception e)
    {
        log.Error("DownloadSite - error Lin = " + RefinedLink, e);
        return null;
    }
}

Antwoord 15, autoriteit 2%

Ik had dit probleem omdat mijn web.config het volgende had:

<httpRuntime targetFramework="4.5.2" />

en niet:

<httpRuntime targetFramework="4.6.1" />

Antwoord 16, autoriteit 2%

De Top-gestemd antwoord zal waarschijnlijk genoeg zijn voor de meeste mensen. In sommige omstandigheden zou u echter doorgaan met het krijgen van een “kan geen SSL / TLS Secure Channel” -fout maken, zelfs nadat u TLS 1.2 hebt gedwongen. Als dat het geval is, kunt u dit nuttige artikel bekijken voor aanvullende stappen voor probleemoplossing. Om samen te vatten: onafhankelijk van het probleem van de TLS / SSL-versie, moeten de client en de server overeenstemming bereiken over een “coderingsuite”. Tijdens de fase “Handshake” van de SSL-verbinding vermeldt de client de ondersteunde cipher-suites voor de server om te controleren op zijn eigen lijst. Maar op sommige Windows-machines zijn bepaalde gemeenschappelijke cipher-suites mogelijk uitgeschakeld (schijnbaar te wijten aan goedbedoelde pogingen om de aanvalsoppervlak te beperken), waardoor de mogelijkheid van de Klant & AMP wordt verminderd; Server akkoord gaat met een cipher suite. Als ze het niet eens kunnen zijn, ziet u “Fatale Alert Code 40” in de gebeurtenisviewer en “Kon SSL / TLS beveiligd kanaal niet maken” in uw .NET-programma.

In het bovengenoemde artikel wordt uitgelegd hoe u alle mogelijk ondersteunde coderingssuites van een computer kunt weergeven en aanvullende coderingssuites kunt inschakelen via het Windows-register. Ga naar deze diagnostische paginain MSIE om te helpen controleren welke coderingssuites op de client zijn ingeschakeld. (Het gebruik van System.Net-tracering kan meer definitieve resultaten opleveren.) Om te controleren welke coderingssuites door de server worden ondersteund, probeert u dit online tool(ervan uitgaande dat de server internettoegankelijk is). Het spreekt voor zich dat Registerbewerkingen voorzichtig moeten gebeuren, vooral als er sprake is van netwerken. (Is uw machine een op afstand gehoste VM? Als u het netwerk zou verbreken, zou de VM dan überhaupt toegankelijk zijn?)

In het geval van mijn bedrijf hebben we verschillende extra “ECDHE_ECDSA”-suites ingeschakeld via Registerbewerking, om een onmiddellijk probleem op te lossen en toekomstige problemen te voorkomen. Maar als u het register niet kunt (of wilt) bewerken, komen er tal van tijdelijke oplossingen (niet per se mooi) in u op. Bijvoorbeeld: uw .NET-programma zou zijn SSL-verkeer kunnen delegeren aan een apart Python-programma (dat zelf kan werken, om dezelfde reden dat Chrome-verzoeken kunnen slagen wanneer MSIE-verzoeken mislukken op een getroffen computer).

Antwoord 17

De wortel van deze uitzondering in mijn geval was dat op een bepaald punt in de code het volgende werd aangeroepen:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Dit is echt erg. Het geeft .NET niet alleen de instructie om een onveilig protocol te gebruiken, maar dit heeft ook invloed op elk nieuw WebClient (en vergelijkbaar) verzoek dat daarna binnen uw appdomein wordt gedaan. (Houd er rekening mee dat inkomende webverzoeken niet worden beïnvloed in uw ASP.NET-app, maar nieuwe WebClient-verzoeken, zoals om met een externe webservice te praten, wel).

In mijn geval was het niet echt nodig, dus ik kon het statement gewoon verwijderen en al mijn andere webverzoeken begonnen weer goed te werken. Op basis van wat ik elders las, heb ik een paar dingen geleerd:

• Dit is een algemene instelling in uw appdomein, en als u gelijktijdige activiteit heeft, kunt u deze niet op betrouwbare wijze op één waarde instellen, uw actie uitvoeren en deze vervolgens weer terugzetten. Een andere actie kan plaatsvinden tijdens dat kleine venster en worden beïnvloed.
• De juiste instelling is om deze standaard te laten. Hierdoor kan .NET de meest veilige standaardwaarde blijven gebruiken naarmate de tijd verstrijkt en je frameworks upgradet. Het instellen op TLS12 (wat op dit moment het veiligst is) werkt numaar kan over 5 jaar mysterieuze problemen veroorzaken.
• Als u echt een waarde moet instellen, kunt u overwegen dit in een aparte gespecialiseerde toepassing of appdomein te doen en een manier te vinden om met uw hoofdpool te praten. Omdat het een enkele globale waarde is, zal het proberen om het te beheren binnen een drukke app-pool alleen maar tot problemen leiden. Dit antwoord: https://stackoverflow.com/a/26754917/7656biedt een mogelijke oplossing door middel van een aangepaste proxy . (Opmerking: ik heb het niet persoonlijk geïmplementeerd.)

Antwoord 18

Zoals je kunt zien, zijn er tal van redenen waarom dit kan gebeuren. Ik dacht dat ik de oorzaak zou toevoegen die ik tegenkwam …

Als u de waarde van WebRequest.Timeoutinstelt op 0, is dit de uitzondering die wordt gegenereerd. Hieronder staat de code die ik had… (Behalve in plaats van een hardgecodeerde 0voor de time-outwaarde, had ik een parameter die per ongeluk was ingesteld op 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Antwoord 19

In mijn geval had het serviceaccount waarop de toepassing werd uitgevoerd geen toestemming voor toegang tot de privésleutel. Nadat ik deze toestemming had gegeven, verdween de fout

1. mmc
2. certificaten
3. Uitbreiden naar persoonlijk
4. selecteer certificaat
5. klik met de rechtermuisknop
6. Alle taken
7. Privésleutels beheren
8. Toevoegen

Antwoord 20

Dit heeft me geholpen:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Antwoord 21

Ik heb de hele dag met dit probleem geworsteld.

Toen ik een nieuw project met .NET 4.5 maakte, kreeg ik het eindelijk werkend.

Maar als ik downgraded naar 4.0 kreeg ik hetzelfde probleem weer, en het was onomkeerbaar voor dat project (zelfs toen ik opnieuw probeerde te upgraden naar 4.5).

Vreemd geen andere foutmelding dan “Het verzoek is afgebroken: kan geen beveiligd SSL/TLS-kanaal maken.”kwam naar voren voor deze fout

Antwoord 22

In het geval dat de client een Windows-machine is, kan een mogelijke reden zijn dat het tls- of ssl-protocol dat door de service wordt vereist, niet is geactiveerd.

Dit kan worden ingesteld in:

Configuratiescherm -> Netwerk en internet -> Internetopties -> Geavanceerd

Scroll instellingen omlaag naar “Beveiliging” en kies tussen

• Gebruik SSL 2.0
• Gebruik SSL 3.0
• Gebruik TLS 1.0
• Gebruik TLS 1.1
• Gebruik TLS 1.2

Antwoord 23

Als u uw code uitvoert vanuit Visual Studio, probeer dan Visual Studio als beheerder uit te voeren. Het probleem voor mij opgelost.

Antwoord 24

Ik had hetzelfde probleem en ontdekte dat dit antwoordgoed werkte voor mij. De sleutel is 3072. Deze linkgeeft de details over de ‘3072’-fix.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

In mijn geval vereisten twee feeds de oplossing:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

Antwoord 25

System.Net.WebException: het verzoek is afgebroken: kan niet worden aangemaakt
SSL/TLS beveiligd kanaal.

In ons geval gebruikten we een softwareleverancier, dus we hadden geen toegang om de .NET-code te wijzigen. Blijkbaar zal .NET 4 geen gebruik maken van TLS v 1.2 tenzij er een wijziging is.

De oplossing voor ons was het toevoegen van de SchUseStrongCrypto-sleutel aan het register. U kunt de onderstaande code kopiëren/plakken in een tekstbestand met de extensie .reg en uitvoeren. Het diende als onze “patch” voor het probleem.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Antwoord 26

Geen van de antwoorden werkte voor mij.

Dit is wat werkte:

In plaats van mijn X509Certifiacte2als volgt te initialiseren:

  var certificate = new X509Certificate2(bytes, pass);

Ik deed het als volgt:

  var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Let op deX509KeyStorageFlags.Exportable!!

Ik heb de rest van de code niet gewijzigd (de WebRequestzelf):

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

In feite weet ik niet eens zeker of de eerste twee regels nodig zijn…

Antwoord 27

Dit is voor mij opgelost, voeg netwerkservice toe aan machtigingen.
Klik met de rechtermuisknop op het certificaat > Alle taken > Privésleutels beheren… > Toevoegen… > Voeg “Netwerkservice” toe.

Antwoord 28

Een andere mogelijkheid is dat de code die wordt uitgevoerd niet de vereiste rechten heeft.

In mijn geval kreeg ik deze fout bij het gebruik van Visual Studio debugger om een aanroep van een webservice te testen. Visual Studio werd niet uitgevoerd als beheerder, wat deze uitzondering veroorzaakte.

Antwoord 29

Geen van deze antwoorden werkt niet voor mij, de Google Chrome en de postbode werken en geven de server een hand, maar dat wil zeggen en .net werkt niet. in Google Chrome op het tabblad Beveiliging > verbinding laten zien dat gecodeerd en geverifieerd met behulp van ECDHE_RSA met P-256 en AES_256_GCMcoderingssuite om de server te overhandigen.

ik installeer IIS Cryptoen in de lijst met versleutelde suites op Windows Server 2012 R2 ican’ t zoek ECDHE_RSA met P-256 en AES_256_GCMcoderingssuite. dan werk ik Windows bij naar de laatste versie, maar het probleem lost niet op. eindelijk na zoekopdrachten begreep ik dat Windows Server 2012 R2 GSM niet correct ondersteunt en mijn server update naar Windows Server 2016 en mijn probleem is opgelost.

Antwoord 30

Het probleem voor mij was dat ik IIS probeerde te implementeren als een webservice. Ik installeerde het certificaat op de server, maar de gebruiker die IIS uitvoert, had niet de juiste machtigingen voor het certificaat.

Hoe geef ik ASP.NET toegang tot een privésleutel in een certificaat in het certificaatarchief?