La richiesta è stata interrotta: imansible creare il canale protetto SSL / TLS

Non siamo in grado di connettersi a un server HTTPS utilizzando WebRequest causa di questo messaggio di errore:

The request was aborted: Could not create SSL/TLS secure channel.

Sappiamo che il server non ha un certificato HTTPS valido con il percorso utilizzato, ma per evitare questo problema, utilizziamo il seguente codice che abbiamo preso da un altro post di StackOverflow:

 private void Somewhere() { ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate); } private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) { return true; } 

Il problema è che il server non convalida mai il certificato e fallisce con l’errore sopra riportato. Qualcuno ha qualche idea di cosa dovrei fare?


Devo dire che un collega ed io abbiamo eseguito alcuni test alcune settimane fa e funzionava bene con qualcosa di simile a quello che ho scritto sopra. L’unica “grande differenza” che abbiamo trovato è che sto usando Windows 7 e stava usando Windows XP. Questo cambia qualcosa?

Alla fine ho trovato la risposta (non ho notato la mia fonte ma era da una ricerca);

Mentre il codice funziona in Windows XP, in Windows 7, è necessario aggiungerlo all’inizio:

 ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; // Use SecurityProtocolType.Ssl3 if needed for compatibility reasons 

E ora, funziona perfettamente.


ADDENDUM

Come menzionato da Robin French; PayPal non supporta più SSL3 quindi dovrai utilizzare TLS1.2. Pagina Info Paypal

La soluzione a questo, in. NET 4.5 è

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; 

Se non si dispone di .NET 4.5, quindi utilizzare

 ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; 

Il problema che stai avendo è che l’utente aspNet non ha accesso al certificato. Devi dare accesso usando winhttpcertcfg.exe

Un esempio su come impostare questo è a: http://support.microsoft.com/kb/901183

Sotto il passaggio 2 in ulteriori informazioni

MODIFICA: nelle versioni più recenti di IIS, questa funzione è incorporata nello strumento Gestore certificati e vi si può accedere facendo clic con il pulsante destro del mouse sul certificato e utilizzando l’opzione per la gestione delle chiavi private. Maggiori dettagli qui: https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

L’errore è generico e ci sono molte ragioni per cui la negoziazione SSL / TLS può fallire. Il più comune è un certificato del server non valido o scaduto, e tu ti sei preso cura di ciò fornendo il tuo hook di convalida del certificato del server, ma non è necessariamente l’unica ragione. Il server può richiedere l’autenticazione reciproca, può essere configurato con una serie di crittografie non supportate dal client, può avere una deriva del tempo troppo grande per il successo dell’handshake e molti altri motivi.

La soluzione migliore è utilizzare il set di strumenti per la risoluzione dei problemi di SChannel. SChannel è il provider SSPI responsabile per SSL e TLS e il tuo cliente lo utilizzerà per l’handshake. Dai un’occhiata agli strumenti e alle impostazioni di TLS / SSL .

Vedi anche Come abilitare la registrazione degli eventi Schannel .

Ho avuto questo problema cercando di colpire https://ct.mob0.com/Styles/Fun.png , che è un’immagine distribuita da CloudFlare sul suo CDN che supporta roba pazzesca come SPDY e redirect i certificati SSL.

Invece di specificare Ssl3 come nella risposta di Simons, sono riuscito a risolverlo andando a Tls12 in questo modo:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png"); 

Qualcosa che la risposta originale non aveva. Ho aggiunto altro codice per renderlo a prova di proiettile.

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

Un’altra possibilità è l’importazione non corretta del certificato sulla scatola. Assicurati di selezionare la casella di controllo circondata. Inizialmente non l’ho fatto, quindi il codice è scaduto o ha generato la stessa eccezione in cui non è stato ansible individuare la chiave privata.

finestra di dialogo di importazione del certificato

Dopo molte lunghe ore con questo stesso problema, ho scoperto che l’account ASP.NET in cui il servizio client era in esecuzione non aveva accesso al certificato. L’ho risolto accedendo al Pool di applicazioni IIS in cui viene eseguita l’app Web, passando in Impostazioni avanzate e cambiando l’identity framework con l’account LocalSystem da NetworkService .

Una soluzione migliore consiste nel far funzionare il certificato con l’account NetworkService predefinito, ma questo funziona per test funzionali rapidi.

Questo funziona per me in 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; } } 

Come puoi dire ci sono molte ragioni per cui questo potrebbe accadere. Ho pensato di aggiungere la causa che ho incontrato …

Se si imposta il valore di WebRequest.Timeout su 0 , si tratta dell’eccezione generata. Di seguito è riportato il codice che avevo … (Tranne invece di uno 0 codificato per il valore di timeout, avevo un parametro che era inavvertitamente impostato su 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 ... 

“La richiesta è stata interrotta: imansible creare il canale protetto SSL / TLS” si può verificare un’eccezione se il server restituisce una risposta non autorizzata HTTP 401 alla richiesta HTTP.

È ansible determinare se ciò accade triggersndo la registrazione System.Net a livello di traccia per l’applicazione client, come descritto in questa risposta .

Una volta che la configurazione di registrazione è a posto, eseguire l’applicazione e riprodurre l’errore, quindi cercare l’output di registrazione per una riga come questa:

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

Nella mia situazione, non riuscivo a impostare un particolare cookie che il server si aspettava, portando al server che rispondeva alla richiesta con l’errore 401, che a sua volta portava all’eccezione “Imansible creare SSL / TLS secure channel”.

Assicurati che le impostazioni di ServicePointManager siano fatte prima che HttpWebRequest sia fatto, altrimenti non funzionerà.

Lavori:

  ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") 

Non riesce:

  HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; 

Ho lottato con questo problema tutto il giorno.

Quando ho creato un nuovo progetto con .NET 4.5 ho finalmente funzionato.

Ma se ho eseguito il downgrade a 4.0 ho avuto di nuovo lo stesso problema, ed è stato irreversibile per quel progetto (anche quando ho provato ad aggiornare nuovamente a 4.5).

Strano nessun altro messaggio di errore ma “La richiesta è stata interrotta: imansible creare il canale sicuro SSL / TLS.” si avvicinò per questo errore

Un’altra ansible causa della The request was aborted: Could not create SSL/TLS secure channel errore del The request was aborted: Could not create SSL/TLS secure channel è una discrepanza tra i valori di cipher_suites configurati del PC client ei valori che il server è configurato come disponibile e in grado di accettare . In questo caso, quando il client invia l’elenco di valori cipher_suites che è in grado di accettare nel messaggio di handshaking / negoziazione SSL “Client Hello” iniziale, il server vede che nessuno dei valori forniti è accettabile e potrebbe restituire un “avviso” “risposta invece di procedere al passaggio” Server Hello “dell’handshake SSL.

Per esaminare questa possibilità, è ansible scaricare Microsoft Message Analyzer e utilizzarlo per eseguire una traccia sulla negoziazione SSL che si verifica quando si tenta di stabilire una connessione HTTPS al server (nell’app C #).

Se sei in grado di effettuare una connessione HTTPS di successo da un altro ambiente (ad esempio il computer Windows XP che hai menzionato – o possibilmente colpendo l’URL HTTPS in un browser non Microsoft che non utilizza le impostazioni della suite di crittografia del sistema operativo, come Chrome o Firefox), eseguire un’altra traccia di Message Analyzer in quell’ambiente per acquisire ciò che accade quando la negoziazione SSL ha esito positivo.

Si spera che vedrete alcune differenze tra i due messaggi Client Hello che vi permetteranno di individuare esattamente cosa la negoziazione SSL fallita sta causando il fallimento. Quindi dovresti essere in grado di apportare modifiche alla configurazione di Windows che gli consentiranno di avere successo. IISCrypto è un ottimo strumento da utilizzare per questo (anche per i PC client, nonostante il nome “IIS”).

Le seguenti due chiavi del Registro di sistema di Windows regolano i valori cipher_suites che verranno utilizzati dal PC:

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

Ecco una descrizione completa di come ho studiato e risolto un’istanza di questa varietà del problema relativo al Could not create SSL/TLS secure channel riuscito: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in -windows.html

La radice di questa eccezione nel mio caso era che ad un certo punto del codice veniva chiamato il seguente:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 

Questo è veramente brutto. Non solo istruisce .NET a utilizzare un protocollo non sicuro, ma questo influisce su ogni nuova richiesta WebClient (e simile) effettuata successivamente all’interno dell’appodominio. (Si noti che le richieste Web in ingresso non sono interessate dall’app ASP.NET, ma le nuove richieste WebClient, come quelle relative a un servizio Web esterno, sono).

Nel mio caso, non era effettivamente necessario, quindi ho potuto semplicemente cancellare l’istruzione e tutte le altre richieste Web hanno iniziato a funzionare correttamente. Basandomi sulla mia lettura altrove, ho imparato alcune cose:

  • Questa è un’impostazione globale nel tuo appdomain e, se hai un’attività concorrente, non puoi impostarla in modo affidabile su un valore, eseguire l’azione e quindi ripristinarla. Un’altra azione potrebbe aver luogo durante quella piccola finestra e subire un impatto.
  • L’impostazione corretta è lasciare il valore predefinito. Ciò consente a .NET di continuare a utilizzare qualsiasi valore predefinito più sicuro con il passare del tempo e di aggiornare i framework. Impostandolo su TLS12 (che è il più sicuro al momento in cui scrivo) funzionerà ora ma in 5 anni potrebbe iniziare a causare problemi misteriosi.
  • Se hai davvero bisogno di impostare un valore, dovresti prendere in considerazione l’idea di farlo in un’applicazione o appdomain specializzata separata e trovare un modo per parlare tra esso e il tuo pool principale. Poiché si tratta di un singolo valore globale, provare a gestirlo all’interno di un pool di app impegnato causerà solo problemi. Questa risposta: https://stackoverflow.com/a/26754917/7656 fornisce una soluzione ansible tramite un proxy personalizzato. (Nota che non l’ho implementato personalmente.)

Nel caso in cui il client sia una macchina Windows, un ansible motivo potrebbe essere che il protocollo tls o ssl richiesto dal servizio non è triggersto.

Questo può essere impostato in:

Pannello di controllo -> Rete e Internet -> Opzioni Internet -> Avanzate

Scorri le impostazioni fino a “Sicurezza” e scegli tra

  • Usa SSL 2.0
  • Utilizzare SSL 3.0
  • Utilizza TLS 1.0
  • Utilizza TLS 1.1
  • Utilizzare TLS 1.2

inserisci la descrizione dell'immagine qui

Ho avuto questo problema perché il mio web.config aveva:

  

e non:

  

Nel mio caso, l’account di servizio che esegue l’applicazione non ha il permesso di accedere alla chiave privata. Una volta dato questo permesso, l’errore è andato via

  1. mmc
  2. certificati
  3. Espandi al personale
  4. seleziona cert
  5. tasto destro
  6. Tutte le attività
  7. Gestisci chiavi private
  8. Inserisci

Se si sta eseguendo il codice da Visual Studio, provare a eseguire Visual Studio come amministratore. Risolto il problema per me.

Stavo avendo lo stesso problema e ho trovato questa risposta ha funzionato correttamente per me. La chiave è 3072. Questo collegamento fornisce i dettagli sulla correzione ‘3072’.

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

Nel mio caso sono stati necessari due feed per la correzione:

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

System.Net.WebException: la richiesta è stata interrotta: imansible creare il canale sicuro SSL / TLS.

Nel nostro caso, noi utilizziamo un fornitore di software per cui non abbiamo avuto accesso alla modifica del codice .NET. Apparentemente .NET 4 non utilizzerà TLS v 1.2 a meno che non vi sia una modifica.

La soluzione per noi era l’aggiunta della chiave SchUseStrongCrypto al registro. È ansible copiare / incollare il codice seguente in un file di testo con l’estensione .reg ed eseguirlo. È servito da “patch” per il problema.

 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 

Puoi provare a installare un certificato demo (alcuni fornitori di SSL li offrono gratuitamente per un mese) per essere sicuro che il problema sia correlato alla validità del certificato o meno.

Finché questo è un collegamento relativamente “live” ho pensato di aggiungere una nuova opzione. Questa possibilità è che il servizio non supporta più SSL 3.0 a causa del problema con l’attacco del barboncino. Controlla l’affermazione di Google su questo. Ho riscontrato questo problema con diversi servizi Web contemporaneamente e ho capito che doveva succedere qualcosa. Sono passato a TLS 1.2 e tutto funziona di nuovo.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Il problema per me era che stavo cercando di implementare su IIS come servizio web, ho installato il certificato sul server, ma l’utente che esegue IIS non aveva le autorizzazioni corrette sul certificato.

Come concedere l’accesso ASP.NET a una chiave privata in un certificato nell’archivio certificati?

Questo stava accadendo per me su un solo sito, e si è scoperto che aveva solo il codice RC4 disponibile. In uno sforzo precedente per rafforzare il server, avevo disabilitato il codice RC4, una volta riabilitato, il problema è stato risolto.

Oltre alle risposte di cui sopra, assicurati di aver importato il CER CER, e NON il file PFX nel tuo negozio di macchine locale. Un errore comune quando si hanno entrambi i file.

Nel mio caso ho avuto questo problema quando un servizio di Windows ha cercato di connettersi a un servizio web. Guardando negli eventi di Windows finalmente ho trovato un codice di errore.

ID evento 36888 (Schannel):

 The following fatal alert was generated: 40. The internal error state is 808. 

Finalmente era correlato a un hotfix di Windows. Nel mio caso: KB3172605 e KB3177186

La soluzione proposta nel forum vmware era aggiungere una voce di registro in Windows. Dopo aver aggiunto il seguente registro, tutto funziona correttamente.

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ KeyExchangeAlgorithms \ Diffie-Hellman]

“ClientMinKeyBitLength” = dword: 00000200

Apparentemente è correlato con un valore mancante nell’handshake https sul lato client.

Elenca il tuo Windows HotFix:

 wmic qfe list 

Thread della soluzione:

https://communities.vmware.com/message/2604912#2604912

Spero sia di aiuto.

L’impostazione predefinita .NET ServicePointManager.SecurityProtocol utilizza SSLv3 e TLS. Se si accede a un server Apache, esiste una variabile di configurazione denominata SSLProtocol che per impostazione predefinita è TLSv1.2. È ansible impostare ServicePointManager.SecurityProtocol per utilizzare il protocollo appropriato supportato dal proprio server Web o modificare la configurazione di Apache per consentire tutti i protocolli come questo SSLProtocol .

Risolto questo per me, aggiungere il servizio di rete alle autorizzazioni. Certificato con clic destro> Tutte le attività> Gestione chiavi private> Aggiungi> Servizio di rete

Mi sono imbattuto nello stesso problema di recente. Il mio ambiente è in esecuzione su .NET 4.6.1 con VB.NET. È così che l’ho risolto:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate) 

e la funzione util.ValidateServerCertificate è:

 Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean Return True End Function