Domanda

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

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

Sappiamo che il server non dispone di un certificato HTTPS valido il percorso utilizzato, ma per bypassare questo problema, usiamo 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 di server non convalida il certificato e non riesce con l'errore precedente. Qualcuno ha qualche idea di che cosa devo fare?


Vorrei ricordare che un collega e ho eseguito i test un paio di settimane fa e che stava lavorando bene con qualcosa di simile a quello che ho scritto sopra. L'unica "grande differenza" che abbiamo trovato è che sto usando Windows 7 e che stava usando Windows XP. Fa che il cambiamento di qualcosa?

È stato utile?

Soluzione

Finalmente 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 aggiungere questo all'inizio:

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

E ora, funziona perfettamente.


APPENDICE

Come accennato da Robin francese; se hai trovato questo problema durante la configurazione di PayPal, si ricorda che saranno non supporta SSL3 a partire dal 3 Dicembre 2018. Sarà necessario utilizzare TLS. Ecco Paypal su di esso.

Altri suggerimenti

La soluzione a questo, in .NET 4.5 è

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Se non si dispone di .NET 4.5 quindi usare

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Assicurarsi che le impostazioni ServicePointManager sono fatte prima che il HttpWebRequest viene creato, altrimenti non funzionerà.

Opere:

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

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Fallisce:

        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 avendo è che l'utente ASPNET non ha accesso al certificato. Devi dare l'accesso utilizzando il WinHttpCertCfg.exe

Un esempio su come impostare questa funzione e ': http://support.microsoft.com/kb/901183

Nel passaggio 2 in ulteriori informazioni

EDIT: Più in recenti versioni di IIS, questa funzionalità è costruito per lo strumento di gestione dei certificati - e sono accessibili facendo clic destro sul certificato e con 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 non ci sono molte ragioni per cui la negoziazione SSL / TLS potrebbe non riuscire. Il più comune è un certificato server non valido o scaduto, e si prese cura di che, fornendo il proprio gancio convalida dei certificati server, ma non è necessariamente l'unica ragione. Il server può richiedere l'autenticazione reciproca, può essere configurato con un suite di cifrari non supportati dal vostro cliente, può avere una deriva di tempo troppo grande per la stretta di mano per avere successo e molte altre ragioni.

La soluzione migliore è quella di utilizzare lo SChannel strumenti di troubleshooting set. SChannel è il fornitore SSPI responsabile per SSL e TLS e il vostro cliente lo userà per la stretta di mano. Date un'occhiata a TLS / SSL Strumenti e impostazioni .

Come attivare la registrazione degli eventi Schannel .

Ho avuto questo problema cercando di colpire https://ct.mob0.com/Styles/Fun.png, che è un'immagine distribuito da CloudFlare su di essa la CDN che supporti roba folle come SPDY e certs reindirizzamento SSL strani.

Invece di specificare SSL3 come in Simons rispondo sono stato in grado di risolvere il problema andando giù a Tls12 in questo modo:

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

Dopo molte ore con questo stesso problema ho scoperto che l'account di ASP.NET il servizio client è stato eseguito con non hanno avuto accesso al certificato. Ho riparato andando nel pool di applicazioni IIS che viene eseguito il web app sotto, andando in Impostazioni avanzate, e cambiando l'identità sul conto LocalSystem da NetworkService.

Una soluzione migliore è quello di ottenere il certificato di lavorare con l'account predefinito NetworkService ma questo funziona per il test funzionale rapido.

Qualcosa la risposta originale non aveva. Ho aggiunto un po 'di 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à è certificato improprio importazione sulla scatola. Assicurarsi di selezionare la casella di controllo circondato. Inizialmente non l'ho fatto, quindi il codice era o temporizzazione o gettando stessa eccezione come chiave privata non è stato possibile individuare.

finestra di dialogo importazione certificato

L ' "La richiesta è stata interrotta: Impossibile creare SSL / TLS sicuro canale" può verificarsi un'eccezione se il server restituisce un HTTP 401 non autorizzato risposta alla richiesta HTTP

.

È possibile determinare se questo sta accadendo per l'attivazione di registrazione System.Net-livello di traccia per l'applicazione client, come descritto in questa risposta .

Una volta che la configurazione della registrazione è a posto, eseguire l'applicazione e riprodurre l'errore, poi guardare nell'output di registrazione per una linea come questa:

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

Nella mia situazione, mi stava venendo a mancare di impostare un determinato cookie che il server si aspettava, che porta al server di rispondere alla richiesta con l'errore 401, che a sua volta ha portato alla "Impossibile creare SSL / TLS canale sicuro" fa eccezione.

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Questa è davvero male. Non solo è istruendo .NET per utilizzare un protocollo non sicuro, ma questo influisce ogni nuovo WebClient (e simili) richiesta fatta in seguito all'interno del tuo dominio di applicazione. (Si noti che le richieste Web in entrata non sono influenzati in ASP.NET app, ma nuove richieste WebClient, come parlare con un servizio di web esterno, sono).

Nel mio caso, non è stato effettivamente necessario, quindi ho potuto solo eliminare la dichiarazione e tutti i miei altri le richieste web iniziato bene a lavorare di nuovo. Sulla base della mia lettura altrove, ho imparato un paio di cose:

  • Questa è un'impostazione globale nel dominio di applicazione, e se si dispone di attività simultanee, non è possibile in modo affidabile impostarla su un valore, fare la tua azione, e quindi impostare indietro. Un'altra azione può avvenire durante quella piccola finestra ed essere influenzato.
  • L'impostazione corretta è quella di lasciare IT predefinito. Questo permette .NET per continuare a utilizzare tutto ciò che è il valore più sicuro di default col passare del tempo e si aggiorna quadri. Impostandolo a TLS12 (che è il più sicuro al momento della stesura) funzionerà Ora , ma in 5 anni può iniziare causando problemi misteriosi.
  • Se avete veramente bisogno di impostare un valore, si dovrebbe prendere in considerazione di farlo in un'applicazione specializzata separata o dominio di applicazione e di trovare un modo per parlare tra esso e la vostra piscina principale. Perché è un singolo valore globale, cercando di gestire entro un pool di app occupato porterà solo guai. Questa risposta: https://stackoverflow.com/a/26754917/7656 fornisce una possibile soluzione per mezzo di un proxy personalizzato . (Si noti che non ho implementato personalmente.)

Questo sta lavorando 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 si può dire ci sono un sacco di ragioni per cui questo potrebbe accadere. Ho pensato di aggiungere la causa che ho incontrato ...

Se si imposta il valore di WebRequest.Timeout a 0, questa è l'eccezione che viene generata. Di seguito è riportato il codice che ho avuto ... (tranne che invece di un 0 hard-coded per il valore di timeout, ho avuto un parametro che è stato inavvertitamente impostata 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 ...

Un'altra possibile causa dell'errore The request was aborted: Could not create SSL/TLS secure channel è un mancata corrispondenza tra i valori cipher_suites configurate il vostro cliente del PC, ei valori che il server è configurato come essere disposti e in grado di accettare . In questo caso, quando il client invia l'elenco dei valori cipher_suites che è in grado di accettare nella sua iniziale SSL handshake / negoziazione "Client Ciao" messaggio, il server vede che nessuno dei valori forniti sono accettabili, e può restituire un "Alert "risposta invece di procedere a 'passo Server Ciao' del handshake SSL.

Per studiare questa possibilità, è possibile scaricare Microsoft Message Analyzer , e utilizzarlo per eseguire una traccia sulla negoziazione SSL che si verifica quando si tenta e non riescono a stabilire una connessione HTTPS al server (in C # app).

Se si è in grado di stabilire una connessione HTTPS con successo da un altro ambiente (ad esempio, la macchina di Windows XP che lei ha menzionato - o, eventualmente, premendo il HTTPS URL in un browser non Microsoft che non utilizza le impostazioni pacchetto di crittografia del sistema operativo , come ad esempio Chrome o Firefox), eseguire un altro traccia Message Analyzer in quell'ambiente di catturare ciò che accade quando la negoziazione SSL riesce.

Si spera, si vedrà un po 'di differenza tra i due messaggi client Ciao che vi permetterà di individuare esattamente ciò che la negoziazione SSL in mancanza sta causando il fallimento. Poi si dovrebbe essere in grado di apportare modifiche alla configurazione di Windows che permetterà la sua riuscita. IISCrypto è un ottimo strumento da utilizzare per questo (anche per PC client, a dispetto del nome "IIS" ).

I seguenti due chiavi di registro di Windows governano i valori cipher_suites che il PC utilizza:

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

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

Ho lottato con questo problema per tutto il giorno.

Quando ho creato un nuovo progetto con .NET 4.5 finalmente ho potuto farlo funzionare.

Ma se declassato a 4,0 Ho avuto lo stesso problema di nuovo, ed era irreversibile per quel progetto (anche quando ho provato a eseguire l'aggiornamento a 4.5 di nuovo).

Strano nessun altro messaggio di errore, ma "La richiesta è stata interrotta:. Impossibile creare SSL / TLS canale sicuro" si avvicinò per questo errore

Nel caso in cui il cliente è una macchina 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

Scorrere le impostazioni fino a "Sicurezza" e scegliere tra

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

 entrare descrizione dell

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

<httpRuntime targetFramework="4.5.2" />

e non

<httpRuntime targetFramework="4.6.1" />

Nel mio caso, l'account di servizio che esegue l'applicazione non ha avuto il permesso di accedere alla chiave privata. Una volta che ho dato questa autorizzazione, l'errore è andato via

  1. mmc
  2. certificati
  3. Espandi di personale
  4. selezionare cert
  5. tasto destro del mouse
  6. Tutte le attività
  7. Gestisci chiavi private
  8. Aggiungi

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

ho avuto questo stesso problema e ha trovato questa risposta funzionava bene per me. La chiave è 3072. Questo link fornisce i dettagli sulla '3072' fix.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

Nel mio caso due alimentazioni richiesto 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: Impossibile creare   SSL / TLS canale sicuro.

Nel nostro caso, abbiamo in cui si utilizza un fornitore di software, quindi non abbiamo avuto accesso a modificare il codice .NET. A quanto pare .NET 4 non utilizzerà TLS v 1.2 a meno che non vi sia un cambiamento.

La correzione di noi stava aggiungendo la chiave SchUseStrongCrypto al Registro di sistema. È possibile copiare / incollare il sottostante codice in un file di testo con estensione reg ed eseguirlo. E 'servito come il nostro "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;

Il top-votato risposta sarà probabilmente sufficiente per la maggior parte delle persone. Tuttavia, in alcune circostanze, si potrebbe continuare a ricevere un "TLS Impossibile creare SSL / canale protetto" errore anche dopo aver costretto TLS 1.2. Se è così, si consiglia di consultare questa utile articolo per i passaggi di risoluzione dei problemi. Per riassumere: indipendente dalla versione TLS / SSL problema, il client e il server devono essere d'accordo su un "pacchetto di crittografia." Durante la fase di "stretta di mano" della connessione SSL, il client elencherà i suoi Cipher-suite supportate per il server per controllare contro una propria lista. Ma su alcune macchine Windows, alcuni Cipher-suite incontrate possono sono state disattivate (apparentemente a causa di tentativi ben intenzionati a superficie di attacco limite), diminuendo la possibilità che il client server e un accordo su un pacchetto di crittografia. Se non possono essere d'accordo, allora si può vedere "il codice di allarme fatale 40" nel caso il visore e "Impossibile creare SSL / TLS canale sicuro" nel programma NET.

Il suddetto articolo spiega come elencare tutti i pacchetti di crittografia potenzialmente supportati di una macchina e consentire ulteriori suite di cifratura attraverso il Registro di Windows. Per aiutare check che i pacchetti di crittografia sono abilitati sul client, prova a visitare questa diagnostica pagina in MSIE . (Using System.Net tracciamento può dare risultati più definitivi.) Per controllare quali suite di cifratura supportati dal server, prova a questo strumento online (supponendo che il server è accessibile da Internet). Va da sé che modifiche del Registro di sistema devono essere fatte con cautela , specialmente dove il networking è coinvolto. (La macchina è una macchina virtuale a distanza ospitato? Se si dovesse rompere rete, sarebbe la VM essere accessibile a tutti?)

Nel caso della mia azienda, abbiamo attivato diverse suite aggiuntivi "ECDHE_ECDSA" via di modifica del Registro di sistema, per risolvere un problema immediato e la guardia contro i problemi futuri. Ma se non si può (o non vuole) modificare il Registro di sistema, quindi numerose soluzioni alternative (non necessariamente abbastanza) vengono in mente. Per esempio:. Il programma di .NET potrebbe delegare il suo traffico SSL per un programma Python separata (che può esso stesso lavorare, per lo stesso motivo che le richieste Chrome possono riuscire là dove le richieste di MSIE falliscono su una macchina colpita)

Il problema per me era che stavo cercando di distribuire su IIS come un servizio web, ho installato il certificato sul server, ma l'utente che esegue IIS non dispone delle autorizzazioni corrette sul certificato.

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

Nel mio caso ho avuto questo problema quando un servizio di Windows ha tentato di collegato ad un servizio web. Guardando agli eventi di Windows finalmente ho trovato un codice di errore.

  

ID evento 36888 (Schannel) è sollevata:

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

Infine è stato correlato con una correzione di Windows. Nel mio caso: KB3172605 e KB3177186

La soluzione proposta nel forum vmware è aggiungere una voce di Registro di sistema in Windows. Dopo aver aggiunto la seguente chiave di registro tutto funziona bene.

  

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

"ClientMinKeyBitLength" = dword: 00000200

A quanto pare è in relazione con un valore mancante nella https stretta di mano nel lato client.

Inserisci il tuo di Windows HotFix:

wmic qfe list

Soluzione Discussione:

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

La speranza è aiuta.

Nessuna delle risposte lavorato per me.

Questo è ciò che ha funzionato:

Invece di inizializzazione mia X509Certifiacte2 in questo modo:

   var certificate = new X509Certificate2(bytes, pass);

L'ho fatto in questo modo:

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

Avviso il X509KeyStorageFlags.Exportable !!

non ho cambiato il resto del codice (il WebRequest stesso):

// 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 realtà io non sono nemmeno sicuro che le prime due righe sono necessari ...

Questa domanda può avere molte risposte in quanto si tratta di un messaggio di errore generico. Ci siamo imbattuti in questo problema su alcuni dei nostri server, ma non le nostre macchine di sviluppo. Dopo aver tirato fuori la maggior parte dei nostri capelli, abbiamo scoperto che c'era un bug di Microsoft.

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

In sostanza, MS presuppone che si desidera crittografia più debole, ma il sistema operativo è patchato per consentire solo TLS 1.2, in modo da ricevere il temuto "La richiesta è stata interrotta:. Impossibile creare SSL / TLS canale sicuro"

Ci sono tre correzioni.

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

2) Aggiungere un ambiente al file app.config / web.config.

3) Aggiungere un'impostazione di registro che è stato già detto in un'altra risposta.

Tutti questi sono menzionati in questo articolo della knowledge base che ho inviato.

Si può provare a installare un certificato demo (alcuni provider SSL offre loro gratuitamente per un mese) per essere sicuri che se il problema è legato alla validità cert o meno.

Fino a quando questo è un collegamento relativamente "live" Ho pensato di aggiungere una nuova opzione. Tale possibilità è che il servizio non è più sta sostenendo SSL 3.0 a causa del problema con l'attacco barboncino. Controlla la dichiarazione di Google su questo. Ho riscontrato questo problema con diversi servizi web in una sola volta e realizzato qualcosa doveva essere in corso. Sono passato a TLS 1.2 e tutto funziona di nuovo.

http: //googleonlinesecurity.blogspot. com / 2014/10 / presente-barboncino-bites-sfruttamento-ssl-30.html

Questo stava accadendo per me su un solo sito, e si scopre che aveva solo la RC4 cifra a disposizione. In uno sforzo prima di indurire il server, avevo disabilitato la cifratura RC4, una volta che ho riattivato questo il problema è stato risolto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top