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

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?

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.

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;

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;

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

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 .

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");

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.

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?

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 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.

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".

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

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.)

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

<httpRuntime targetFramework="4.5.2" />

e non:

<httpRuntime targetFramework="4.6.1" />

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 ...

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).

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" />

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

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

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

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

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

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

Prova questo:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

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".

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?

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

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.

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.

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.