La richiesta è stata interrotta: impossibile creare il canale sicuro SSL / TLS


432

Impossibile connettersi a un server HTTPS utilizzando a WebRequestcausa 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 aggirare questo problema, utilizziamo il seguente codice che abbiamo preso da un altro post 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 non riesce con l'errore sopra riportato. Qualcuno ha idea di cosa dovrei fare?


Dovrei dire che un collega e io abbiamo eseguito dei test alcune settimane fa e funzionava bene con qualcosa di simile a quello che ho scritto sopra. L'unica "grande differenza" che abbiamo riscontrato è che sto usando Windows 7 e lui stava usando Windows XP. Questo cambia qualcosa?



51
È il 2018 e questa domanda è stata vista 308.056 volte, ma non esiste ancora una soluzione adeguata !! Ottengo questo problema in modo casuale e nessuna delle correzioni menzionate qui o in altri thread ha risolto il mio problema.
Nigel Fds

3
@NigelFds L'errore The request was aborted: Could not create SSL/TLS secure channelè molto generico. Sostanzialmente dice "l'inizializzazione della connessione SSL / TLS / HTTPS non è riuscita per uno dei tanti motivi possibili". Quindi, se lo ricevi regolarmente in una situazione specifica, l'opzione migliore è quella di porre una domanda specifica fornendo dettagli specifici su quella situazione. E controllando il Visualizzatore eventi per ulteriori informazioni. E / o abilitare alcuni debug sul lato client .NET per ottenere maggiori dettagli (il cert del server non è attendibile? C'è una mancata corrispondenza della cifra? Mancata corrispondenza della versione del protocollo SSL / TLS? Ecc.).
MarnixKlooster ReinstateMonica

4
@MarnixKlooster Ho già controllato tutto questo, non può essere un problema con il certificato come se dovessi riprovarlo, funziona. E dubito che sarei in grado di porre questa domanda su SO senza che qualcuno venga e lo contrassegni come duplicato o qualcosa del genere.
Nigel Fds

1
Sto combattendo questo problema forse per la quarta volta. La stessa base di codice che sto eseguendo funziona benissimo in produzione e anche nell'ambiente di sviluppo di alcuni dei miei colleghi sviluppatori. L'ultima volta, mi è stato chiesto di aggiungere un valore del registro Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1. E ha funzionato per un po '. Ho iniziato a lavorare in un progetto diverso per un po 'e ora sono tornato a questo progetto e la richiesta fallisce di nuovo, anche con questa correzione della chiave di registro. Molto noioso.
Miguel,

Risposte:


598

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

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

// using System.Net;
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; se riscontri questo problema durante la configurazione di PayPal, tieni presente che non supporteranno SSL3 a partire dal 3 dicembre 2018. Dovrai utilizzare TLS. Ecco la pagina di Paypal al riguardo.


5
Scendendo a SecurityProtocolType.Tls12 in realtà risolto questo problema per me. Vedi la mia risposta qui sotto.
Bryan Legend,

24
SSLv3 ha 18 anni e ora è suscettibile all'exploit POODLE - poiché @LoneCoder consiglia SecurityProtocolType.Tls12 è il sostituto adatto per SecurityProtocolType.Ssl3
gary

4
SecurityProtocolType.Tls potrebbe effettivamente essere un'alternativa migliore fino a quando non viene trovato un exploit (non tutti i siti supportano Tls12 al momento della scrittura)
gary

3
PayPal ha fissato una data del 30 giugno 2017 per disabilitare SSL3 e implementare TLS1.2. È già applicato nel loro ambiente sandbox paypal-knowledge.com/infocenter/…
Robin French

11
Vedi anche questo . Non è necessario impostarlo esclusivamente su un singolo tipo, è possibile semplicemente aggiungere anche. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae,

153

La soluzione a questo, in .NET 4.5 è

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Se non si dispone di .NET 4.5, utilizzare

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

10
Grazie! Ho bisogno di usare .net 4.0 e non sapevo come risolverlo. Questo sembra funzionare qui. :)
Fabiano,

Non funziona su Windows Server 2008R2 (e forse anche nel 2012)
Misam,

@billpg, leggi questo per una risposta più esatta
Vikrant

Per i tipi VB (poiché questa risposta viene visualizzata in Google), il codice equivalente èServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers

@Andrej Z sta lavorando su .net framework 4. Grazie.
az fav

107

Assicurarsi che le impostazioni di ServicePointManager vengano eseguite prima della creazione di HttpWebRequest, 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;

4
Qual è la differenza tra Works e Fails che hai menzionato sopra?
Chandy Kunhu,

5
Eccezionale. La mia richiesta ha funzionato solo dopo il secondo tentativo, che non aveva senso e poi ho visto il tuo post, spostato il protocollo di sicurezza prima della richiesta e voilà, risolto. Grazie @ hogarth45
deanwilliammills il

2
Esattamente! quando ho inserito ServicePointManager appena prima che la richiesta fosse creata, ha funzionato per me, grazie amico, mi hai salvato la giornata.

1
Perfetto ... questo è meraviglioso
Maryam Bagheri il

1
Nel nostro caso, la richiesta non è riuscita per la prima volta e ha funzionato in seguito. Questo è stato esattamente per il motivo indicato in questa risposta!
Mohammad Dehghan,

34

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

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

Sotto il passaggio 2 in ulteriori informazioni

EDIT: nelle versioni più recenti di IIS, questa funzione è integrata nello strumento di gestione dei certificati e vi si può accedere facendo clic con il tasto destro del mouse sul certificato e utilizzando l'opzione per la gestione delle chiavi private. Maggiori dettagli qui: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791


Ho provato a eseguire winhttpcertcfg.exe ... nota che sono su Windows 7. Può cambiare qualcosa?
Simon Dugré,

Non sono sicuro che sia correlato, ma questo post mi ha dato l'idea di eseguire VS come amministratore quando si effettua questa chiamata da VS e ciò ha risolto il problema per me.
PFranchise,

2
In Windows 7 e versioni successive, il certificato deve essere nell'archivio per il computer locale anziché per l'utente corrente per "Gestire le chiavi private"
Lukos

1
Sì, questo era il mio problema. utilizzare mmc.exe, aggiungere lo snap-in certificati (per me ho quindi scelto "computer locale"). Certificato del tasto destro del mouse, tutte le attività, gestire le chiavi private. Aggiungi "tutti" (per gli sviluppatori locali questo è il più semplice - prod ovviamente ha bisogno del tuo pool / utente esplicito di app del sito Web IIS)
Ian Yates

@Ian Yates, questa soluzione ha funzionato solo per me (y)
Usman Younas

31

L'errore è generico e ci sono molti motivi per cui la negoziazione SSL / TLS potrebbe non riuscire. Il più comune è un certificato server non valido o scaduto e te ne sei preso cura fornendo il tuo hook di convalida del certificato server, ma non è necessariamente l'unico motivo. Il server potrebbe richiedere un'autenticazione reciproca, potrebbe essere configurato con una serie di cifre non supportate dal client, potrebbe avere un tempo troppo grande per il successo dell'handshake e molte altre ragioni.

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

Vedi anche Come abilitare la registrazione degli eventi di Schannel .


Dove è il percorso per la Schannel event loggingin di Windows 7-8-10 ?
PreguntonCojoneroCabrón

risolvere i problemi TLS / SSL a livello di codice in C #?
Kiquenet,

27

Ho avuto questo problema cercando di colpire https://ct.mob0.com/Styles/Fun.png , che è un'immagine distribuita da CloudFlare sulla sua CDN che supporta roba folle come SPDY e strani certificati di reindirizzamento SSL.

Invece di specificare Ssl3 come nella risposta di Simons sono stato in grado di risolverlo scendendo a Tls12 in questo modo:

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

Grazie Lone ... è pazzesco come sembra che ci siano molte diverse possibilità di problemi a seconda della situazione ... E, come posso vedere, non esiste una vera documentazione di ciò. Bene, grazie di sottolineare per qualcuno che potrebbe avere lo stesso problema.
Simon Dugré,

Questo ha funzionato per me. Ho riscontrato l'errore quando sono passato dalla LAN dell'ufficio alla mia rete domestica. Stesso codice, stesso laptop!
Amal

Ricevi l'errore sempre (in tutte le richieste) o talvolta ?
PreguntonCojoneroCabrón

24

Dopo molte lunghe ore con lo stesso problema, ho scoperto che l'account ASP.NET in cui era in esecuzione il servizio client non aveva accesso al certificato. Ho risolto andando nel Pool di applicazioni IIS su cui viene eseguita l'app Web, andando in Impostazioni avanzate e modificando l'identità LocalSystemdall'account NetworkService.

Una soluzione migliore è far funzionare il certificato con l' NetworkServiceaccount predefinito , ma questo funziona per un rapido test funzionale.


3
Questa risposta dovrebbe avere più voti positivi. Dopo una settimana di ricerche, questa è l'unica soluzione che ha funzionato per me. Grazie!!
user224567893

Questo ha funzionato per me. perfetto grazie.
Emy Stats

18

L'approccio con impostazione

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Sembra andare bene, perché Tls1.2 è l'ultima versione del protocollo sicuro. Ma ho deciso di guardare più in profondità e rispondere se abbiamo davvero bisogno di codificarlo.

Specifiche: Windows Server 2012R2 x64.

Da Internet si dice che .NetFramework 4.6+ deve usare Tls1.2 per impostazione predefinita. Ma quando ho aggiornato il mio progetto a 4.6 non è successo nulla. Ho trovato alcune informazioni che dicono che devo fare manualmente alcune modifiche per abilitare Tls1.2 per impostazione predefinita

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

Ma l'aggiornamento di Windows proposto non funziona per la versione R2

Ma ciò che mi ha aiutato è l'aggiunta di 2 valori al registro. Puoi usare il prossimo script PS in modo che vengano aggiunti automaticamente

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

Questo è quello che stavo cercando. Ma non posso ancora rispondere alla domanda sul perché NetFramework 4.6+ non imposta questo ... Valore del protocollo automaticamente?


17

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;

8
Non consiglierei il protocollo SSL3 aggiunto.
Peter de Bruijn,

SSL3 ha un grave problema di sicurezza chiamato 'Poodle'.
Peter de Bruijn,

@PeterdeBruijn Tls and Tls11sono obsoletes ?
Kiquenet,

1
@Kiquenet - sì. A partire da giugno 2018 il PCI (Payment Card Industries) non consentirà protocolli inferiori a TLS1.2. (Questo era originariamente previsto per il 06/2017 ma è stato rinviato di un anno)
GlennG

Esistono cinque protocolli nella famiglia SSL / TLS: SSL v2, SSL v3, TLS v1.0, TLS v1.1 e TLS v1.2 : github.com/ssllabs/research/wiki/… L' SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes unica opzione valida sarà ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
Kiquenet,

14

Un'altra possibilità è l'importazione impropria del certificato sulla scatola. Assicurarsi di selezionare la casella di controllo cerchiata. Inizialmente non l'ho fatto, quindi il codice stava scadendo o generando la stessa eccezione della chiave privata non poteva essere individuata.

finestra di dialogo per l'importazione dei certificati


Un client continuava a dover reinstallare il certificato per utilizzare un programma client. Più e più volte avrebbero dovuto reinstallare il certificato prima di utilizzare il programma. Spero che questa risposta risolva questo problema.
Pangamma,

11

L'eccezione "La richiesta è stata interrotta: impossibile creare il canale protetto SSL / TLS" può verificarsi se il server restituisce una risposta HTTP 401 non autorizzata alla richiesta HTTP.

È possibile determinare se ciò sta accadendo attivando la registrazione System.Net a livello di traccia per l'applicazione client, come descritto in questa risposta .

Una volta effettuata la configurazione della registrazione, eseguire l'applicazione e riprodurre l'errore, quindi cercare nell'output di registrazione 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 cookie specifico che il server si aspettava, portando il server a rispondere alla richiesta con l'errore 401, che a sua volta ha portato all'eccezione "Impossibile creare il canale sicuro SSL / TLS".


1
Il mio programmatore di attività viene eseguito ogni giorno (non nel fine settimana). Ottengo lo stesso errore, ma a volte ( 2 errors in 2 months). Quando ricevo l'errore, dopo qualche minuto riprovo manualmente e tutto è OK.
Kiquenet,

10

Un'altra possibile causa The request was aborted: Could not create SSL/TLS secure channeldell'errore è una mancata corrispondenza tra i valori cipher_suites configurati del PC client e i valori che il server è configurato come disposto 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 "Client Hello" di sincronizzazione / sincronizzazione SSL iniziale, il server rileva che nessuno dei valori forniti è accettabile e può restituire un "Avviso "risposta invece di procedere al passaggio" Server Hello "dell'handshake SSL.

Per esaminare questa possibilità, è possibile 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 #) e non si riesce.

Se sei in grado di stabilire una connessione HTTPS corretta da un altro ambiente (ad es. La macchina 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), esegui un'altra traccia di Message Analyzer in quell'ambiente per catturare ciò che accade quando la negoziazione SSL ha esito positivo.

Si spera che vedrai qualche differenza tra i due messaggi di Hello Client che ti permetteranno di individuare esattamente ciò che la negoziazione SSL non riuscita 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 PC client, nonostante il nome "IIS").

Le seguenti due chiavi di registro di Windows regolano i valori cipher_suites che il PC utilizzerà:

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

Ecco un resoconto completo di come ho studiato e risolto un'istanza di questa varietà del Could not create SSL/TLS secure channelproblema: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html


1
Nel mio caso, questa risposta è utile. Inoltre, poiché sospettavo che il mio PC client avesse perso alcune suite di crittografia, ho preso una scorciatoia e ho installato questo Windows Update direttamente per tentare la fortuna ( support.microsoft.com/en-hk/help/3161639 , è necessario riavviare Windows) prima di avviare davvero il Ricerca di Message Analyzer, e ho scoperto che sono stato fortunato e ho risolto il mio problema, salvandomi una ricerca.
sken130,

1
Si noti che quando si verifica un collegamento HTTPS in browser come Firefox, anche se si ottiene una cifra diversa da quella fornita da un determinato Windows Update, vale comunque la pena provare Windows Update, poiché l'installazione di nuove cifre influirà sulla negoziazione della cifra tra il PC client e il server, aumentando così la speranza di trovare una corrispondenza.
sken130,

Al punto rispondi per il mio problema. Due cose che mi hanno aiutato a trovare le modifiche da apportare. 1. Suite di crittografia supportate dal server Web: ssllabs.com/ssltest 2. Suite di crittografia supportate da diverse versioni di Windows: docs.microsoft.com/en-us/windows/win32/secauthn/…
Paul B.

10

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Questo è davvero brutto. Non solo sta insegnando a .NET di utilizzare un protocollo non sicuro, ma questo ha un impatto su ogni nuova richiesta WebClient (e simili) fatta successivamente all'interno del tuo dominio. (Notare che le richieste Web in entrata non sono interessate dall'app ASP.NET, ma le nuove richieste WebClient, come quelle per parlare con un servizio Web esterno, lo sono).

Nel mio caso, in realtà non era necessario, quindi potevo semplicemente cancellare la dichiarazione e tutte le altre mie richieste web hanno ripreso a funzionare bene. Sulla base della mia lettura altrove, ho imparato alcune cose:

  • Questa è un'impostazione globale nel tuo dominio e, se hai attività simultanee, non puoi impostarlo in modo affidabile su un valore, fare la tua azione e quindi ripristinarlo. Un'altra azione può aver luogo durante quella piccola finestra ed essere influenzata.
  • L'impostazione corretta è lasciare l'impostazione predefinita. Ciò consente a .NET di continuare a utilizzare qualunque sia il valore predefinito più sicuro con il passare del tempo e l'aggiornamento dei framework. Impostarlo su TLS12 (che è il più sicuro al momento della stesura di questo documento) funzionerà ora, ma in 5 anni potrebbe iniziare a causare problemi misteriosi.
  • Se hai davvero bisogno di impostare un valore, dovresti considerare 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 in un pool di app occupato causerà solo problemi. Questa risposta: https://stackoverflow.com/a/26754917/7656 fornisce una possibile soluzione tramite un proxy personalizzato. (Nota che non l'ho implementato personalmente.)

2
Contrariamente alla tua regola generale, aggiungo che c'è un'eccezione quando DEVI impostarlo su TLS 1.2, piuttosto che lasciare l'esecuzione predefinita. Se si utilizza un framework precedente a .NET 4.6 e si disabilitano protocolli non sicuri sul server (SSL o TLS 1.0 / 1.1), non è possibile inviare richieste se non si impone il programma in TLS 1.2.
Paul

10

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

<httpRuntime targetFramework="4.5.2" />

e non:

<httpRuntime targetFramework="4.6.1" />

Ho avuto lo stesso problema e ho aggiunto una risposta più dettagliata di seguito, che approfondisce i dettagli di questo problema.
JLRishe,

9

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

Se si imposta il valore di WebRequest.Timeouta 0, questa è l'eccezione generata. Di seguito è riportato il codice che avevo ... (Tranne che invece di un hard-coded 0per il valore di timeout, avevo un parametro che era stato 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 ...

2
Wow! Grazie per averlo menzionato. Non potevo crederci in primo luogo e prima ho provato tonnellate di cose diverse. Quindi, infine, imposta il timeout su 10sec e l'eccezione scompare! Questa è la soluzione per me (y)
derFunk

9

La risposta più votata sarà probabilmente sufficiente per la maggior parte delle persone. Tuttavia, in alcune circostanze, è possibile continuare a ricevere un errore "Impossibile creare il canale sicuro SSL / TLS" anche dopo aver forzato TLS 1.2. In tal caso, potresti consultare questo utile articoloper ulteriori passaggi per la risoluzione dei problemi. Riassumendo: indipendentemente dal problema della versione TLS / SSL, il client e il server devono concordare una "suite di crittografia". Durante la fase di "stretta di mano" della connessione SSL, il client elencherà le sue suite di crittografia supportate affinché il server possa verificare con il proprio elenco. Ma su alcune macchine Windows, alcune suite di cifratura comuni potrebbero essere state disabilitate (apparentemente a causa di tentativi ben intenzionati di limitare la superficie di attacco), riducendo la possibilità che client e server concordino una suite di cifratura. Se non riescono a concordare, nel Visualizzatore eventi potrebbe essere visualizzato "codice di avviso irreversibile 40" e "Impossibile creare il canale protetto SSL / TLS" nel programma .NET.

Il suddetto articolo spiega come elencare tutte le suite di crittografia potenzialmente supportate da una macchina e abilitare suite di crittografia aggiuntive attraverso il registro di Windows. Per verificare quali suite di crittografia sono abilitate sul client, provare a visitare questa pagina di diagnostica in MSIE. (L'uso della traccia System.Net può dare risultati più definitivi.) Per verificare quali suite di crittografia sono supportate dal server, provare questo strumento online (supponendo che il server sia accessibile da Internet). Va da sé che le modifiche al Registro di sistema devono essere eseguite con cautela , soprattutto quando è coinvolta la rete. (La macchina è una macchina virtuale ospitata in remoto? Se si dovesse interrompere la rete, la macchina virtuale sarebbe accessibile a tutti?)

Nel caso della mia azienda, abbiamo abilitato diverse suite "ECDHE_ECDSA" aggiuntive tramite la modifica del Registro di sistema, per risolvere un problema immediato e proteggerci da problemi futuri. Ma se non puoi (o non vuoi) modificare il Registro, vengono in mente numerose soluzioni alternative (non necessariamente belle). Ad esempio: il tuo programma .NET potrebbe delegare il suo traffico SSL a un programma Python separato (che potrebbe funzionare da solo, per lo stesso motivo per cui le richieste di Chrome potrebbero avere esito positivo quando le richieste MSIE falliscono su un computer interessato).


9

Una delle maggiori cause di questo problema è la versione attiva di .NET Framework. La versione runtime di .NET framework influisce sui protocolli di sicurezza abilitati per impostazione predefinita.

Non sembra esserci alcuna documentazione autorevole su come funzioni specificamente in diverse versioni, ma sembra che i valori predefiniti siano determinati più o meno come segue:

  • .NET Framework 4.5 e precedenti - SSL 3.0, TLS 1.0
  • .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
  • .NET Framework 4.7+ - Impostazioni predefinite di sistema (SO)

(Per le versioni precedenti, il chilometraggio può variare in base alla runtime .NET installata nel sistema. Ad esempio, potrebbe verificarsi una situazione in cui si utilizza un framework molto vecchio e TLS 1.0 non è supportato o 4.6. xe TLS 1.3 non sono supportati)

La documentazione di Microsoft consiglia vivamente di utilizzare 4.7+ e le impostazioni predefinite del sistema:

Ti consigliamo di:

  • Target .NET Framework 4.7 o versioni successive sulle tue app. Target .NET Framework 4.7.1 o versioni successive nelle app WCF.
  • Non specificare la versione TLS. Configura il tuo codice per consentire al sistema operativo di decidere sulla versione TLS.
  • Esegui un controllo approfondito del codice per verificare che non specifichi una versione TLS o SSL.

Per i siti ASP.NET , controlla la versione di .NET framework nel tuo <httpRuntime>elemento, poiché ciò determina quale runtime è effettivamente utilizzato dal tuo sito:

<httpRuntime targetFramework="4.5" />

Meglio:

<httpRuntime targetFramework="4.7" />

8

Questo funziona per me nel client web MVC

    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;
        }
    }

2
Sostituire ServerCertificateValidationCallback introdurrebbe un nuovo buco di sicurezza?

7

Nel caso in cui il client sia un computer Windows, un possibile motivo potrebbe essere che il protocollo tls o ssl richiesto dal servizio non è attivato.

Questo può essere impostato in:

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

Scorri le impostazioni verso il basso fino a "Sicurezza" e scegli tra

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

inserisci qui la descrizione dell'immagine


qualche problema nel barrarli tutti?
Nigel Fds

nessun problema, per quanto ne so ... tranne che ssl non è più raccomandato ... non sono considerati abbastanza sicuri.
cnom

come farlo programmaticamente in PowerShell?
Kiquenet,

Questo è qualcosa che riguarda le versioni precedenti di Windows, fai qualche ricerca, scopri quali opzioni di sicurezza sono attualmente in uso. Da oggi vedi questo link: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod

7

Nel mio caso, l'account del servizio che esegue l'applicazione non disponeva dell'autorizzazione per accedere alla chiave privata. Una volta che ho dato questa autorizzazione, l'errore è scomparso

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

7

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


Purtroppo non per me!
benedict_w,

Questo è l'unico che mi ha aiutato nel mio caso! Grazie!!!
alexander ostrikov,

6

Ho lottato con questo problema tutto il giorno.

Quando ho creato un nuovo progetto con .NET 4.5, finalmente sono riuscito a farlo funzionare.

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

Strano nessun altro messaggio di errore ma "La richiesta è stata interrotta: impossibile creare il canale sicuro SSL / TLS." è venuto per questo errore


5
Il motivo per cui ha funzionato potrebbe essere stato perché diverse versioni .NET supportano diverse versioni del protocollo SSL / TLS. Ulteriori informazioni: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider,

4

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

Nel nostro caso, dovevamo utilizzare un fornitore di software in modo da non avere accesso alla modifica del codice .NET. Apparentemente .NET 4 non utilizzerà TLS v 1.2 a meno che non ci sia una modifica.

La correzione per noi era l'aggiunta della chiave SchUseStrongCrypto al registro. È possibile copiare / incollare il codice seguente in un file di testo con l'estensione .reg ed eseguirlo. È servito da "patch" al 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

3
Qui PS per una rapida modifica: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

2
Qui PS per una rapida modifica2: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

4

Prova questo:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Ho aggiunto questa riga. A volte fallisce e ottengo lo stesso erroreSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman,

4

Questo risolto per me, aggiungere il servizio di rete alle autorizzazioni. Fare clic con il tasto destro sul certificato> Tutte le attività> Gestisci chiavi private ...> Aggiungi ...> Aggiungi "Servizio di rete".


3

Il problema per me era che stavo provando a distribuire 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 dare ad ASP.NET l'accesso a una chiave privata in un certificato nell'archivio certificati?


Sì, idem. Per risolvere il problema, ho fatto la risposta di Nick Gotch: ho cambiato l'identità del pool di app in LocalSystem. Questo mi ha risolto.
Giuda Gabriele Himango,

1
Grazie per questo
Denis Pitcher l'

3

Stavo riscontrando lo stesso problema e ho riscontrato che 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 due feed richiedevano la correzione:

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

3

Questa domanda può avere molte risposte poiché si tratta di un messaggio di errore generico. Abbiamo riscontrato questo problema su alcuni dei nostri server, ma non sulle nostre macchine di sviluppo. Dopo aver rimosso la maggior parte dei nostri capelli, abbiamo scoperto che si trattava di un bug di Microsoft.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Fondamentalmente, MS presume che tu voglia una crittografia più debole, ma il sistema operativo è patchato per consentire solo TLS 1.2, quindi ricevi il temuto "La richiesta è stata interrotta: Impossibile creare il canale sicuro SSL / TLS".

Esistono tre correzioni.

1) Patch il sistema operativo con l'aggiornamento corretto: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Aggiungi un'impostazione al tuo file app.config / web.config.

3) Aggiungi un'impostazione del registro che è già stata menzionata in un'altra risposta.

Tutti questi sono menzionati nell'articolo della knowledge base che ho pubblicato.


Inoltre, assicurati di impostare ServicePointManager.SecurityProtocol solo una volta nella tua app. Abbiamo scoperto una seconda chiamata nella nostra app (che è piuttosto complessa con gli assembly opzionali caricati in fase di esecuzione) che la stava impostando su SSL3, che quindi ha generato lo stesso messaggio di errore.
Michael Silver,

3

Un'altra possibilità è che il codice in esecuzione non abbia le premesse richieste.

Nel mio caso, ho riscontrato questo errore durante l'utilizzo del debugger di Visual Studio per testare una chiamata a un servizio Web. Visual Studio non era in esecuzione come amministratore, il che ha causato questa eccezione.


2

Questo stava succedendo per me su un solo sito e risulta che aveva solo la cifra RC4 disponibile. In uno sforzo precedente per rafforzare il server, avevo disabilitato il codice RC4, una volta riattivato il problema era stato risolto.


1
Non utilizzare i collegamenti sulla risposta, poiché potrebbero non funzionare in futuro, sottolinea gli aspetti più rilevanti al riguardo all'interno della tua risposta
Rodrigo López,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.